Nice TWiki > Dev > BigPictureWhatIsItGoodFor (r1.4) 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 porgramming 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

Topic BigPictureWhatIsItGoodFor . { Edit | Attach | Ref-By | Printable | Diffs | r1.11 | > | r1.10 | > | r1.9 | More }
Revision r1.4 - 06 Oct 2003 - 15:14 GMT - ArjanB
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.