Nice TWiki > Dev > BigPictureWhatIsItGoodFor TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Dev . { Changes | Index | Search | Go }
Maybe a year from now, one of the most obvious special things about Nice will turn up in releases of Java and C# ( More on Generics in the CLR ).

Reading this bold statement from the Brew project "We are currently developing Brew as a successor language to Java" made me wonder "What's the vision for Nice?".

In the same way that people seem to understand that Jython is good for glueing a program together out of Java components, what would it be that they should understand Nice is good for?

Is Nice capable of stepping up with a solution to this: The Impedance Imperative Tuples + Objects + Infosets = Too Much Stuff!

Whatever the Vision thang turns out to be, my guess is that it will give a purpose that makes decisions on language features more straightforward.

-- IsaacGouy - 18 Sep 2003

The way I see it now, Nice is a generalist programming language. So it would be more a "successor language to Java" than a niche, specialized language. There are many improvements in Nice besides genericity. I think they mostly fit under the slogan "safety, modularity, expressivity". Is this satisfactory? Is there a clearer or more striking way to put it?

-- DanielBonniot - 30 Sep 2003

"safety, modularity, expressivity"
OK can that slogan be used to drive implementation decisions?

Let's take Safety:
- instead of nicec having a -strict option, shouldn't it be strict by default?
The -strict option affects only the calling of java methods and it's not default now because of the burden to first time users. If most of the java api is given the correct nice types then -strict will probably the default.
- is there a way to 'fix' Java's silent integer overflow / modular arithmetic?
Very difficult to do without virtual machine support
- one or two folk were interested in Option Types until they saw cast(null), to them it seemed like an escape hatch that would inevitably be misused.
In a few cases cast(null) is needed. We will try to reduce them. And maybe should cast(null) not be mentioned in the manual

- I wish an abstract interface could be used to type fields (just a simple-minded programmer)

- type inference for polymorphic method vars (maybe one day)
- labelled tuples?
Will they be immutable? What can you do with them that can't be done with classes or normal tuples?
- literal XML?
Can you elaborate?
OK maybe I just want to try Erik Meijer's research language ;-)
But I know why - database + program + web.

"safety, modularity, expressivity" as a slogan it's a bit too abstract, these are all good things but rather difficult to judge without doing a deal of programming. "What problem does this solve" is much easier for simple-minded programmers to understand ;-)

-- IsaacGouy? - 03 Oct 2003

Comments added in italic. -- ArjanB - 06 Oct 2003

Just found out that C# has a compiler option and keyword support for checked arithmetic -- IsaacGouy - 06 Oct 2003

- literal XML? Can you elaborate?
The motivation is laid out here:
-- IsaacGouy - 16 Oct 2003

I think from a big-picture standpoint, Nice is looking to be a better (easier and more reliable) way of generating .jar files than Java. But it's more of an incremental improvement than a paradigm shift.

Good IDE support (including refactoring) will be critical to get any traction at all. Back when I used Emacs, I tried out new languages all the time and didn't really give anything up by doing so. But now that I use IntelliJ?, switching to a better language doesn't look like a win if it also means using a more primitive IDE. And I expect the percentage of vi and emacs programmers will decline.

So, maybe the way to go is to design the language while working on the Eclipse plugin at the same time. Not that it should be Eclipse-specific, but language features should be designed taking the programmer's total user interface in mind.

-- BrianSlesinsky - 30 Dec 2003

Although developing an IDE/plugin at the same time could be ideal, it's not practical at the moment. A good plugin would take even more work than the compiler itself so with only 2 working on the compiler regularly it's not an option. The difficult choice between the IDEs and the limited experience of us with advanced IDEs are ohter reasons not to develop it at the same time.

How do you think that the language could be influced by a plugin?

Nice makes much more programming styles possible than Java so that we don't know anything yet about good refactorings and pratical idioms. I think we need to know more about the usage of Nice before a plugin can be useful.

-- ArjanB - 31 Dec 2003

It's true that there are still several important core language features to work on, so I cannot focus on IDEs yet. On the other hand, I agree that good IDE support will be crucial to make the language accepted and easier to develop with. We already have a core EclipsePlugin, and it would be great if one or several people interested stepped in to add more advanced features like refactoring. I'm very willing to help by providing the appropriate API in the compiler, so that the work can be focused on providing the features to the IDE user. Concerning the choice of an IDE, I think Eclipse is a good one, given it's already important user base and it's open source status. Of course it's quite fine if somebody wants to work on integration with another IDE too.

-- DanielBonniot - 26 Jan 2004

Not much activity here. But I thought I should refresh this discussion:

Big Picture: I've looked at the "languages for the JVM" and "languages for the CLR" materials on the web. It's clear that there are two trends that Nice is a response to.

Trend 1: Java/C# isn't enough. It must be complemented with something easier to use, etc. Lots of languages are responses to this, but usually these are oriented toward "scripting", that is, it is assumed that if you need to write a real or fast program you'll flop back into Java or C#. Groovy is a good example of this. Jython similarly. There are a pile of these. Often they are aimed at convenience also. Typically they don't much care about type systems.

Trend 2: Java/C# are too hard to program in. We can improve on them by creating a more modern language with type inference, etc. These are fewer in number. The languages of note here are Scala, Boo, and Nice. These languages use type inference. THey go after the expressive-power problems of Java/C#. E.g., multiple return values, type-system restrictions, run-time null-pointer exceptions, etc. There are no compromises in performance in this area. THe programs written need to be just as fast as the corresponding program written in Java/C#.

The community of people with appreciation for Trend 2 is quite a bit smaller than trend 1. The two are blurred terribly because once you add type inference you can end up with programs that are just as clean and dense as in dynamically typed languages (I've verified this with translation of Python code to Nice. If you cuddle your "else", e.g., write lines like "} else {" to keep the braces from taking up whole lines, then you get the same number of lines in Nice as you do in Python. ) So long as we don't get diluted into a "scripting" solution this blurring is good. In fact I think a read-eval-print-loop interactive environment would be a great addition to Nice, allowing it to basically displace Python for my uses.

So the big-picture goal for Nice should be: 1) fix java expressive power issues. Easier to program in. Good for "real" programs, not just scripting. 2) eliminate the need for the dual-language solutions like Java + Jython for real programs and scripting. In short: fix java, displace python.

Other languages we should learn from: Scala and Boo are the two in the same category. I'm not sure what's to learn there. Of the scripting-side languages Groovy shares enough syntax that perhaps some of its features can be copied. It appears to have a community and some traction.

-- MikeBeckerle - 22 Dec 2004

Topic BigPictureWhatIsItGoodFor . { Edit | Attach | Ref-By | Printable | Diffs | r1.11 | > | r1.10 | > | r1.9 | More }
Revision r1.11 - 22 Dec 2004 - 16:33 GMT - MikeBeckerle
Parents: WebHome
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.