TWiki . Dev . BigPictureWhatIsItGoodFor

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

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

Expressivity:
- type inference for polymorphic method vars (maybe one day)
todo
- 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: http://www.research.microsoft.com/~emeijer/Papers/XML2003/xml2003.html
-- 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

----- Revision r1.9 - 31 Dec 2003 - 16:23 GMT - ArjanB
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.