Discussions

News: Nice - A new OO language based on Java

Bookmark and Share Get thread feed

  1. Nice - A new OO language based on Java (29 messages)

    Nice is a new object-oriented programming language based on Java. It incorporates features from functional programming, and puts into practice state-of-the-art results from academic research. Among the advanced features: generic types, anonymous functions, multi-methods, tuples, optional parameters to methods, design by contract, detection of many errors during compilation (in particular, concerning casts and null references). This results in more expressivity, modularity, and type safety.

    Checkout the
    The Nice programming language. Nice is currently in version 0.9.10
    Reply to this

    Threaded Messages (29)

  2. Nice - New?[ Go to top ]

    Nice is a pretty neat language - it's good to see bits and pieces of statically-typed functional programming becoming more mainstream. Daniel Bonniot is pretty "nice" too, being fairly responsive to people with questions. One good thing I hear, is that they're evaluating putting together an "interpreter" so people can more easily come to grips with the language.

    Having said that, Nice is anything but new. IIRC, it's been around for nearly 5 years now.

    God bless,
    -Toby Reyelts
    Reply to this Reply to original

  3. Very Interesting[ Go to top ]

    This is very interesting. What percentage of null pointers can they prevent - that would be a great gain for productivity.
    Reply to this Reply to original

  4. Preventing NullPointerException[ Go to top ]

    This is very interesting. What percentage of null pointers can they prevent - that would be a great gain for productivity.

    100%! That is, the compiler will check that your code can never throw NullPointerException. This is possible because you can formally declare in types whether null is allowed or not (unlike Java were this is left for the javadoc at best, or unspecified at worst). And the compiler runs a powerful static analysis to detect what values might be null.

    Of course, there are situations where you know a value cannot be null, but the compiler cannot detect it. In that case, you can still make him happy by adding an assertion. For instance:

      Map<String,String> map = new HashMap();
      map["a"] = "1"; // this is the same as map.put("a", "1')
      ?String value = map["a"];
      // to use value here, you'd need to handle the null case too

    The compiler knows that when getting from a Map, the value might be null if that key has no associated value, so the returned type is ?String (String or null). In this particular case, you, the programmer, know that "a" has a value. You can tell it to the compiler, either with:

      assert value != null;

    or alternatively, you can do directly:

      String value = notNull(map["a"]);

    In both cases, you can now use value as a real String. Obviously, if your assertion is not true, it will fail at runtime. What you gained over Java is that:

      1) APIs formally declare where they accept null;
      2) In most cases, the compiler can make sure your code will never throw NullPointerException, or point you to a potential error;
      3) In the few cases where you know there is no potential error although the compiler cannot prove it, you have to write an explicit assertion. This encourages you to really think to make sure you are correct (or better, change your design to make the assertion unnecessary).
    Reply to this Reply to original

  5. Preventing NullPointerException[ Go to top ]

    This is very interesting. What percentage of null pointers can they prevent - that would be a great gain for productivity.
    100%!

    I don't get it. How does the deferred keyword prevent null pointers? If the code has run through the new, all NPE's are avoided, whether there is a "deferred" or not.

    --
    Cedric
    Reply to this Reply to original

  6. Preventing NullPointerException[ Go to top ]

    Deferred has nothing to do with Nice. Nice prevents null pointer exceptions in all cases, using static analysis of the code.
    Reply to this Reply to original

  7. Preventing NullPointerException[ Go to top ]

    I don't get it. How does the deferred keyword prevent null pointers? If the code has run through the new, all NPE's are avoided, whether there is a "deferred" or not.-- Cedric

    To further Daniel's comment, you should look up "option types" and "maybe types", which are standard functional fare.

    God bless,
    -Toby Reyelts
    Reply to this Reply to original

  8. Preventing NullPointerException[ Go to top ]

    What I don't like is that you still have to test for null:
       (name == null) ? 0 : name.length();

    Wouldn't it be 'nice' to allow classes to define their own null instance behaviour (a la serialVersionUid):

        class String {
            static final null = new String();
            
            // or override:
            static final null = new String () {
                public int length () {
                    return 0;
                }
            }
        
        }

    so that something like this:

        String name; // is actually String name = String.null;

    Regards,

    Ivan Bilenjkij
    Reply to this Reply to original

  9. Preventing NullPointerException[ Go to top ]

    You don't have to test for null all the time. For instance, if it makes sense to consider null to have length zero, you can define:

    int length(?String s)
    {
      if (s == null)
        return 0;
      else
        return s.length();
    }

    then you can use length even on possibly null values:

    ?String s = null;
    println(s.length); // prints 0
    Reply to this Reply to original

  10. Preventing NullPointerException[ Go to top ]

    Daniel,
    You just moved the 'if' part to another place. Also, the method you introduced is not an instance method so it explicitly declares 'this' reference in its arg list. And then it is used as an instance method - that is awkward.
    IMHO, allowing any class to define its own 'null' instance is more elegant solution to prevent NPE.
    Reply to this Reply to original

  11. Preventing NullPointerException[ Go to top ]

    Yes, declaring methods outside classes can seem strange at first, but read about multi-methods, and you will see how convenient and powerful they are.

    Also, allowing classes to declare a null instance is a less general solution. True, it can prevent NPE by giving a default behaviour to all methods, but what if there is no meaningful default behaviour? (what is the name of a null User?) Nice allows you to specify where null is allowed and where it is not. This can give you safety that class null instance cannot give.
    Reply to this Reply to original

  12. Nice - syntax highlighting, Intellisense, Debug ?[ Go to top ]

    Modern developers are so spoiled with syntax highlighting, Intellisense, Debug, and other IDE enhansements, that even such a *Nice* language will not get its well deserved attention, untill it provides all what we take for granted.
    Reply to this Reply to original

  13. Tool support[ Go to top ]

    Actually, there are lots of tools supporting Nice. There is an Eclipse plugin for Nice. There is also nicedoc for generating documentation. JSR 045 conformant debuggers can be used with Nice programs (JSwat, jdb, ...). There are plugins for Ant and Maven. Highlight support syntax highliting of Nice programs into many output formats.
    Reply to this Reply to original

  14. Tool support[ Go to top ]

    Daniel

    Congratulations. Nice is really groovy ;)

    Interesting, with all the hype about JVM scripts languages around, Nice is going to enforce compiler checkings. It´s nice to have these exceptions evicted by compiler. Less tests to write, isn´t ? (for TDD adicts)

    About multi methods, from the alt.lang.jr article:

    void laugh(String str){
      println("haha, I'm holding an instance of " str);
    }

    lets suppose I want to do this :

    int laughAndReturnIntensity(String joke){
      if (joke.equalsIgnoreCase("haha, I'm holding an instance of " str)) {
        println("haha, that´s funny !");
      } else {
        println("what ?");
      }
      return joke.length() ;
    }

    It is possible with Nice ? Can I refeer to joke instance ?

    And about tools, I can't leverage Eclipse features like code completion and refactoring with Nice plugin (at least right now), right ?
    Reply to this Reply to original

  15. Correction ?[ Go to top ]

    int laughAndReturnIntensity(String joke){
      if (joke.equalsIgnoreCase("haha, I'm holding an instance of " joke)) {
        println("haha, that´s funny !");
      } else {
        println("what ?");
      }
      return joke.getInstance().length() ;
    }
    Reply to this Reply to original

  16. finally, i realized[ Go to top ]

    int laughAndReturnIntensity(String joke){
      if (joke.equalsIgnoreCase("haha, I'm holding an instance of " joke)) {
        println("haha, that´s funny !");
      } else {
        println("what ?");
      }
      return joke.length() > 30 ? 0 : 1;
    }

    So if I can simulate AOP advise using Nice multi methods, why not:

    void save("*POJO"){
      // code to persist this object instance to a xml file
    }

    where "*POJO" would be the regular expression used to specify the classes I want to apply this advise, simulating an AOP pointcut ? Would be nice too ?
    Reply to this Reply to original

  17. finally, i realized[ Go to top ]

    Rodolfo, your last version is correct. No need to call something like "getInstance".

    It's possible to dispatch on string values:

    void save(String name) { ... }
    override void save("*POJO"){ ... }

    The second version will be called if the parameter is "*POJO" exactly, the string is not regarded as a regular expression.

    It would be possible to add a more general mechanism where you could specify if an implementation is applicable using a boolean condition (for instance, matching a regex). However, the problem is: which implementation would be selected when several conditions are true? If they are defined in several files/packages, there is no obvious ordering. It would be clearer if that feature was only available for implementations defined in the same file.
    Reply to this Reply to original

  18. Bah... try something wilder...[ Go to top ]

    ... like a post-structuralist, object oriented system :P

    Lua — Story of O
    http://alt.textdrive.com/lua/19/lua-story-of-o

    Even got Java bindings if you really, really want to:

    http://www.keplerproject.org/luajava/
    Reply to this Reply to original

  19. no need for visitor[ Go to top ]

    dynamic dispatch is the best part. I wish Java had it so I wouldn't need Visitor.

    I also wish Java had delegates.

    I also wish Java had a syntax like:

    List myList = deferred new ArrayList();

    the "deferred" keyword would delay instantiation of the ArrayList until the first time the code accessed myList. Has anyone heard of a feature like this in another language?


    -geoff
    Reply to this Reply to original

  20. no need for visitor[ Go to top ]

    I also wish Java had a syntax like:List myList = deferred new ArrayList();the "deferred" keyword would delay instantiation of the ArrayList until the first time the code accessed myList. Has anyone heard of a feature like this in another language?-geoff

    Visual Basic!
    :o)
    Reply to this Reply to original

  21. "deferred" is old[ Go to top ]

    The effect that you are asking for is called lazy evaluation. Eiffel has "once" methods which is very similar to this. Many strict functional languages (e.g. O'Caml) have "lazy" type constructors that allow for deferred evaluation. Haskell has lazy (technically, "non-strict") evaluation by default.
    Reply to this Reply to original

  22. well java should have it too![ Go to top ]

    The effect that you are asking for is called lazy evaluation. Eiffel has "once" methods which is very similar to this. Many strict functional languages (e.g. O'Caml) have "lazy" type constructors that allow for deferred evaluation. Haskell has lazy (technically, "non-strict") evaluation by default.

    Cool. Now if only Java had it! (oh, Cedric, this has nothing to do with preventing null ptr).

    Also, I want java to add read-only functionality:

    public read-only int x,y,z;
    private Something somethingl

    public read-only Something getSomething(){
      return something;
    }
    Reply to this Reply to original

  23. oh well[ Go to top ]

    I guess it would need to be read_only not read-only.
    Reply to this Reply to original

  24. read_only[ Go to top ]

    Couldn't help it: it's called const and can also qualify methods (C++).
    Reply to this Reply to original

  25. cool[ Go to top ]

    does it have the effect of making an Object returned from a method immutable?
    Reply to this Reply to original

  26. read_only[ Go to top ]

    Perhaps the old and good "final" modifier ?
    Reply to this Reply to original

  27. deferred[ Go to top ]

    You could obtain Deffered behaviour using a bit of AOP, and leveraging Spring and aspect werks
    Reply to this Reply to original

  28. multityped variables[ Go to top ]

    I'd like do declare variables / methods / fields / parameters / .. with multiple types (0..1 classes and 0..n interfaces, but at least one interface or class). This would disburden developers from unsafe castings. Example:

    Comparable, Serializable Observable whatever;
    // ...
    int c = whatever.compareTo(whatelse);
    int h = whatever.hashCode();
    Reply to this Reply to original

  29. looks great[ Go to top ]

    Hey, this has 3/4 of the stuff I've been wishing for while coding Java... !

    All these methods external to the instance (eg callable on a null parameter), collaboration methods external to multiple instances, all this is *exactly* relevant.

    Great stuff! Keep up the good work,


    Cheers,
    Thomas Whitmore
    www.powermapjdo.com
    Reply to this Reply to original

  30. looks great[ Go to top ]

    Thanks! Feel free to share about the remaining 1/4 to reach perfection! (either here or on Nice's mailing list)
    Reply to this Reply to original