For example value types would be excellent. Even better would be explicit regions, but I'm sure that's not going to happen.
Also, please fix this:
The type system is unsound, due to the covariance of generic types. This is a deliberate choice (and undoubtedly controversial). Experience has shown that sound type rules for generics fly in the face of programmer intuition. It is easy for tools to provide a sound type analysis if they choose, which may be useful for tasks like refactoring.
And add proper generics. If sound type rules fly in the face of programmer intuition, that means that the programmer's intuition is wrong. The proper response is to inform the programmer of his mistake at compile time, and not to silently ignore it and add dynamic type checks on every contravariant use of generics including array access! That is worse on both programmer productivity because the programmer expects that his program is type safe when he is using static types and on runtime speed because the dynamic checks slow down all programs needlessly. Dart already has dynamic typing; use that when you want it, not something that looks like static typing but really is dynamic typing.
Another thing that would be awesome is if you provide a compact binary format for code.
- no braces where avoidable, no semicolons where avoidable
- release early a free, open source reference development environment that really helps in developing with Dart. The biggest pain with Javascript, imho, is in the lack of development tools really thought out for it, and not just an adaptation of Java/C/whatever other editors
- if you develop said IDE as a web-IDE, even better (why not writte in dart itself?)
- give as many inobtrusive visual cues as possible to easily see tab alignment, syntax coloring, etc.
- integrate unit testing facilities in the IDEI've been thinking for years that if I ever were to develop a new language, I would start from developer usability first - I think there is much more to innovate there than in the core language features, nowadays. Developer usability is tightly coupled with the development tools the developer can use, not just with abstract language features. And especially for web development, you can't think only about top of class developers.
As I'm at it, I'll write here my dream feature of any language and IDE - not knowing if it is really feasible, but it doesn't look really impossible to me. Use case:
- You run your unit tests
- An assertion fails/there is an error
- A debugger brings you to where the problem is
- You can step back from where you are, make changes on the fly to your code and the tests, and step forward to the assertion/error again.
I guess that with a VM, and excluding some operations that depend from external status and which are destructive, this could be possible, and it could allow an incredible speedup in development...
- write a test for a method that isn't there yet
- run it, get a red bar, as expected
- run it in debug mode, and get a debugger
- write the method implementation in the debugger
- possibly write other methods that the new method calls, also in the debugger
- resume the program, get a green bar
Writing code in the debugger is great, because you've got all the runtime state right in front of you, and you can step through the code you're working on. I'd love, love, love to see this in Dart. [1] https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/#dart%2Fclient%2Ftesting%2Funittest
[2] https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/client/tests/client/view/ViewTests.dartBut from a new language standpoint, it's not worth dropping them. The ridiculous arguments that come out of it, the programmers who refuse to use the language because of it, they're things that can and should be avoided by using semicolons like most languages.
I'll never understand why programmers care so much about this, but hey, that's life.
If you semantically, and naturally, communicate "end of statement" with a line break to human readers, why should you have to say it again with a semicolon to the compiler? Programming languages should focus on being DRY.
Lines of code are clauses not sentences. This is also true of poetry.
A sentence is more akin to a stanza in poetry, and a function in code.
While I could entertain an argument for lines ending in commas and for functions to end with periods there is no reasonable argument for lines to end with periods (is there a language where a line is equal to a function?).
APL, and to some degree Perl, are examples of languages where to you might consider a period half-way through a line.
For those people who come from "ugly" languages like Java you could have a feature in the IDE which auto-inserted (and of course auto-removed) the braces/semicolons so that they felt at home too.
Seeing how Go, which "wasn't done yet" either, handled external feedback... I don't see why anyone would have hopes for dart.
- Requiring a redundant mechanism to mark blocks
- Possible introducing situations where code looks differently than how it executes
is all very mid-90s. python was the first to fix this, but yaml and coffescript do to. In particular, Dart will have to compete with mindshare from .coffee, so at least should be better than that.
I'm fine with the semicolons, but I'm not too keen on using underscore-starting identifiers to determine what is public and what is private.
> I'm not too keen on using underscore-starting identifiers to determine what is public and what is private.
That's also been discussed. It has more going for it than may be at first apparent, but it has detractors too.
I shouldn't need to write 'Point p = new Point(2, 3);'
var p = new Point(2,3); should be inferred as a Point
Python (and Haskell) solve that issue by not using semicolons unless required. The Dart code in the examples is full of semicolons, that makes it an "optional semicolons language" akin to javascript more than a "possible semicolons language" akin to Python or Ruby.
Well of course they do because semicolons are currently required, but that says nothing about its relationship to JavaScript's inane semicolon insertion semantics, and I'm pretty sure you're smart enough to know that. All Dart needs to do is:
1. Treat both newlines and semicolons as the same kind of token (call it whichever you like). 2. Pick an elision strategy. Go's or Python's work fine. 3. Remove all of the ";" from your source files.
No crazy JavaScript "rewind the parse and try again" insanity.