Here, the issue is that they add something which has superficial resemblance to this work but then, because the "type" stuff doesn't actually work right, keeps the core language 100% dynamic. Among many other things, this means they "completely gave up on the advantages that typing could have brought to the runtime."
That's not an indictment of languages that mix static typing and flexible, tagged-at-runtime dynamic typing, and in my opinion it would be a real pity if Dart, which is doing something altogether different, discredits the idea of hybrid or gradual type systems prematurely.
]]>and then
"Via some type decoration mechanism, one could have mixed weak and strong typing..."
You mock the use of design patterns then you recommend one - "decoration mechanism"
Which is it - they're useful or they're not ??
]]>the primary use of dart is to bring sanity to scripting web applications, specifically those of moderate to large size and in this it achieves its aims from what I can see. Would I choose it for a desktop application, no, there are a plethora of languages better suited to this. For use in the browser though its a good choice in my opinion. Certainly better than plugins such as Java Applets or Flash etc.
the main stopping point with creating sensible we applications is JavaScript's stupidities. Which are caused of course by its lack of proper OOP support and at an enterprise level its purely prototype approach. Both of which are properly addressed by DART.
Now I take your point about the mixing of static and dynamic types. Personally I prefer (most of the time) to develop with proper static classes, they implement the idea that it is one of the compilers job's to catch static errors such type mistakes, not detailed testing which is for the most part insufficient to catch them all.
however there are many cases where dynamic typing can be easier or more flexible I admit. I'm just not sure that the advantages mitigate the severe risks they bring in a large project. However yes a hybrid approach is even more dangerous I think.
Concurrency and Security: again we come back to tool for purpose. Whatever DART does has to be implementable in pure Javascript. Better Solutions exist but not in a form that can be easily supported within the confines of a browser.
Dart provides proper classes and interfaces etc by their proper definition. This is needed for sanity. It compiles to efficient (runtime wise) code that runs natively within all HTML5 compliant browsers regardless of platform, because it compiles to industry standard JS.
Is it a long term language for the future, probably not yet in its current form, but neither was Java when it first came out. Like all program languages, so long as Google continue to develop it, which is of course an important consideration for choosing it, it will evolve.
I think you are being overly harsh at this point.
Also may I point out that
1) mix ins and interfaces are completely separate concepts at a conceptual level. An interface is the black box, the point of interaction. The interface should never be related to the code that implements it directly.
2) Design Patterns are a lot more than you are implying. They are a very good idea, regardless of language weakness/strength. They are not patches over this. A Design Pattern facilitates understanding of your code to others, especially when as is the case 90% of the time the coder insufficiently, or ambiguously comments the code and the reader doesn't have a fully detailed design document. Standardisation yes limits creativity but most of the time this is a good thing. Standard ways of doing things also allow for 4th generation tools to be better used which is also a good thing.
]]>First I think that a title like "The language of the Future" is the author being pretentious. Dart doesn't want to be the "ultimate" language, just it want's to solve a specific problem better than the current standard.
With Dart you can code in a MUCH better (saner) language than JavaScript, getting all most of the trusty design patterns we are used to plus some extra ones like the .. cascading operator, and still run in a web browser and server. No more scary hacks to the prototype, you can finally know the TYPE of an object, arrays are finally nice to iterate over, you have lambda expressions, named constructors, abstract classes, interfaces, mixins, an editor that autocompletes and does type inference to help you, it automatically gives you the correct vendor prefixes for JS and CSS (what a relief!).
]]>