Who is the audience for Dart? Clearly it is first and foremost Google, whose programmers spend their days writing Java and C++ in an IDE like Eclipse. But web developers, who are the primary producers of JavaScript, will happily stick with Node.js, CoffeeScript, or plain JavaScript.
For that audience, they are given a language with optional static typing (most don't want it) and an Eclipse-based editor (most don't want it).
By way of contrast, consider Go. Go is (in my opinion) an extremely successful successor to C, in terms of its design. It fixes a handful of problems with C (strings, and I would argue pointer arithmetic), and modernizes and streamlines it. The interface system is fantastic. In terms of its design, I have nothing but good things to say about Go.
Dart does not seem to improve on JavaScript in a compelling way. It adds optional static typing, and as far as I can tell, nothing else.
Is it any surprise that Dart has failed to take off?
You don't need to write Dart in the Dart Editor if you don't want the IDE experience. I happily write Dart in Sublime, and Dart has command-line tools that I can use to validate the code that I write.
But web developers, who are the primary producers of JavaScript, will happily stick with Node.js, CoffeeScript, or plain JavaScript.
If web developers are happy with the tools they have, then that's just fine. The Dart team isn't trying to replace JavaScript, but instead provide another option for web development. What I think the Dart team is finding is that there are a lot of people that are having trouble with putting together all the pieces just to build a web app. This is especially true if you are new to the web platform, and you're familiar with the development from other places. Dart provides a very consistent platform that you can build web applications with, and you don't need to worry about jumping through all the hoops that normal web development requires.
By way of contrast, consider Go. Go is (in my opinion) an extremely successful successor to C, in terms of its design. It fixes a handful of problems with C (strings, and I would argue pointer arithmetic), and modernizes and streamlines it. The interface system is fantastic. In terms of its design, I have nothing but good things to say about Go.
In a way, this is how I see Dart too (though Dart is a much newer platform, not yet out of beta). Dart aims to fix a handful of problems with JavaScript (like better scoping semantics, a built-in module system, better toolability and static analysis tools, etc.), and then also takes the existing browser APIs and modernizes and streamlines them (for example, all of the core browser APIs use a consistent Future-based API for asynchronous values, which cleans up a lot of messy code that you'd ordinarily see in JavaScript web application code).
Is it any surprise that Dart has failed to take off?
It's not at 1.0 yet. I still think there is plenty of room for improvement, and plenty of time for adoption.
I asked the Dart team if they thought I should use Dart today. They recommended only using it on projects where I had the flexibility to wait a couple months for missing functionality to be written if it turns out my app needs something that isn't in the standard library yet.
There's definitely room for both polish and adoption.
>>You don't need to write Dart in the Dart Editor if you don't want the IDE experience. I happily write Dart in Sublime, and Dart has command-line tools that I can use to validate the code that I write.
This is the same line argument made with regards to Java too.
But the fact of the matter is, these language bring in so complexity with their whole ecosystem. Working without an IDE isn't even worth that torture.
I've written Java in plaintext editors before, and that is truly terrible. Dart is nowhere near that verbose. Dart's imports feel pretty lightweight (rather Python-esque) and the fact that the language has top-level functions and variables means that you're not always trying to juggle a bunch of classes and objects and interfaces when you don't need to. In fact, Dart's style guide explicitly recommends that you don't put things in wrapper objects just because you can. http://www.dartlang.org/articles/style-guide/
I really don't think that Dart brings in any more complexity than you'd have in a JavaScript application. I actually think it's a lot easier to hold a Dart application in your head because all the APIs have a consistent interface. With JavaScript, you often have a bunch of different libraries and you have to remember how each of them behaves.
Dart imports are a bit less verbose as you do an entire library instead of a class like java does. As well, globally scoped functions let you code without all the OOP if you don't want it.
How do you use your JavaScript libraries today? Do you have evrything memorized?
Dart is an ambitious attempt at simplyfing web development, reducing complexity and improving productivity which:
- Provides a familiar language with clean semantics and low ceremony
- Provides the fastest dev iteration times (there's no compile step,
just edit + run in Dart VM/Dartium)
- Provides ~10x faster start-up times with snapshots (Dart VM)
- Provides faster run-time performance, that's predictable and can take
advantage of real integers and SIMD instructions (VM Only)
- Provides a unified object model so all classes from all libraries can interoperate
- Providing a rich, well-defined, consistent API, real collections, removing JS WATs,
smoothing over browser quirks
- Provides a unified and composable IO model: Futures and Streams (repeating events)
- Provides a new powerful way to develop client apps with Web UI (Dart WebComponents)
offering unprecedented levels of encapsulation and reusability
- Provides optimal dev and deployment options, you never have to worry about choosing
the smallest libs as tree-shaking ensures only code used is compiled and minified
- Providing "full-stack" dev environment, e.g. same language on client and server
There are many initiatives ongoing to improve web development IMO Dart is the most radical and has the most potential to provide a productive web development environment in the visible future. I hope it extends further than that and is offered as a language choice on Android (which will make me switch to Android dev).
That's not much. ES6, TypeScript, DOMFutures, FunctionFuture, asm.js, WebComponents, jQuery, r.js, node.js bring most of these features to JS. Not as slick and with some legacy warts, but it's good enough to make Dart merely an incremental improvement rather than a revolution.
It's very disappointing that the first serious attempt to replace JS after almost 20 years is merely just another Java-syntax-like JIT-compiled single-threaded dynamically-typed garbage-collected language with global, shared mutable state. It's fundamentally the same language merely with some pet peeves removed and a bit of sugar on top. It's a waste of opportunity.
AS3, C#, Java, and JavaScript developers. That's why they went with C-like syntax. It's familiar to most people.
>But web developers, who are the primary producers of JavaScript, will happily stick with Node.js, CoffeeScript, or plain JavaScript.
I'm writing JavaScript for a few years now. I'm really tired of it. It scales very poorly and there is zero tooling. For example, JSLint is mostly about formatting and conventions, because it got very little information to work with.
Also, if you want to take care of dependencies in JavaScript, you'll need boilerplate code (several flavors exist). If you want to document your code, you'll need lengthy doc comments (several flavors exist).
Finally, with JavaScript you're always discouraged to write extensive libraries, because everything you don't use is dead weight.
With Dart, you don't have any of those problems. It scales, there is proper tooling, you can use `import` and put stuff into packages, basic documentation is already done by adding some type annotations, and unused code is also removed.
Additionally, it's a lot easier to learn than JavaScript, because the language is less quirky.
>Dart does not seem to improve on JavaScript in a compelling way. It adds optional static typing, and as far as I can tell, nothing else.
Yes, but I think it's a more wide-spread issue.
Comparing languages of the European school with languages of the Anglo-Saxon school, it seems like the wide-spread anti-intellectualism in the US has a large impact on language design quality.
I remember that Dijkstra had some pretty good article about it.
When I started seriously working with JavaScript, I decided to try to conform to community standards by using JSLint. I was shocked by how terrible JSLint was. It offered corrections for very straightforward constructs such as:
var count = 0;
for (var i = 0; i < arr.length; i++) {
if (some_func(i)) {
count++;
}
}
I have no idea why JSLint would tell me that I should move the definition of "i" to the top of the function (am I supposed to pretend I'm writing ANSI C for obsolete compilers?) and its insistence that "++" is evil in both uses above is equally ridiculous.
I love static analysis, I like tools that automatically format source code (indent, go fmt, emacs), but JSLint is just annoying.
JSLint recommends declaring vars at the top of the function because vars have function-scope regardless of where they appear in the function ("variable hoisting").
The ++ thing is due to the fact that JavaScript uses + for concatenation and I've run into real life issues with this, in that if someone writes something like
var foo = "The id number is: " + ++this.id + ".";
a Minifier may make that like
var foo="The id number is: "+++this.id+".";
which is a syntax error. Now of course you should be using a minifier that wouldn't be so stupid but it happened in our staging environment because some former employee used a very basic, yet aggressive minifier in the build process from Staging to Live.
JSLint gives you an option to turn it off though, plusplus:false. Same with the variable hoisting warning others have explained.
The real issue is that, as a programming language, JavaScript is poorly designed and quite broken. Its implementors and community have been quite unwilling to fix these issues, even after a decade and a half. As a result of this, it is still riddled with oddities in even extremely simple constructs.
Even when one understands the reasoning behind why a tool like JSLint suggests what it does, this doesn't change the fact that dietrichepp's observations are correct. JavaScript's scoping and variable hoisting are unnecessarily broken, leading to convoluted coding practices that wouldn't really be necessary if JavaScript itself wasn't so broken.
>[JavaScript's] implementors and community have been quite unwilling to fix these issues [...]
You can't really fix things. It would break the web. You can only add stuff on top.
>JavaScript's scoping and variable hoisting are unnecessarily broken [...]
It will get a bit better with ES6's `let` keyword. Annoyingly, that keyword was introduced with Firefox 2.0 (October 24, 2006) but you still can't use it.
I know there is a stream of Java / C# / C++ programmers that desire a Java-esque, improved GWT experience and loathe Javascript. But I see Dart more as a refined/upgraded Javascript -- some additional language/toolset features like Objective-C or C++ do for C.
Advantages of Dart over Node.js or CoffeeScript or plain Javascript?
1. "Batteries included" -- instead of reliance upon assortment of modules, OO system built in, better DOM utilities than jQuery (query returns a first class object), functional like Javascript sans the function keyword).
2. So nice that you can split a project across a whole bunch of code files, yet it will condense and minify into one efficient javascript file. Yes, there are tools with all the various Javascript frameworks to accomplish this, but then you're reliant upon of hierarchical library dependencies that sometimes can be brittle.
3. Can run server side just as Node.js with a powerful VM, without the need (though certainly possible and optional) to install a plethora of other libraries.
I think it hasn't taken off because up until recent months, the language and library has not been stable enough for production development -- libraries have changed a lot and most of the code in all of the Dart books published to date will not run at all now (though the Dart SDK comes with a tool that can help migrating code).
There are still some sore spots I hope get addressed -- primarily, on server side, need for built-in DB libraries and on client side, JSONP/CORS that is as easy as jQuery makes it. At least in my XP.
Do you think the Gmail or G+ team spends all their days writing backend code? Google has some of the largest and most sophisticated web apps ever developed, e.g. the newly minted Google Maps.
All of this is courtesy of the Closure Compiler, which uses optional static typing.
No more than what Google does with GWT. There is no top-down dictate in Google to use a given language or framework, it is up to the various teams to decide what they want to use. Some teams uses Python (most famous of course is YouTube), some use Go, some C++, and some Java. Some groups deploy to Borg, some to AppEngine. On the frontend, some use Closure (Gmail, G+, Docs, Maps), some use GWT (AdWords, Wallet, Flights/Hotels, etc), some use AngularJS, and now, presumably, some will use Dart. In fact, some apps use a hybrid.
Sometimes people chose to use a language for a new project because of existing labor pool, that is, who they can find to work on the project and what their preferences are. Sometimes it's because they want to use an existing codebase. Sometimes, people chose a new language because they are in an experimental mood and want to try something new.
If Larry Page were to say "all future apps have to be written in Dart", it would be damaging to company morale and culture, not because there's something wrong with Dart, but because people chafe being forced to make technical or personal decisions like that.
Google can no more force you to use Dart than they can force you to use CoffeeScript or GWT, I think people need to chill out and stop aggressing against anything that threatens Javascript hegemony. I mean, sheesh, people are even rebelling against some of the changes in ES6 which fix some of the most egregious problems that drive people to create transpiled languages.
Thanks for explaining the process. I like Google's evolutionary approach, but it sounds chaotic to someone like me from a Microsoft background. The top down command hierarchical structures appear to be losing all over to the networked evolutionary approaches, so I have no complaints. But I wonder, does that mean someone inside Google could use TypeScript? This might be a blind spot.
Also, I meant it will be interesting if no team chooses to use Dart on the client, but it gains interest on the server. Presumably teams go with what makes sense and that will be interesting to watch.
> I think people need to chill out and stop aggressing against anything that threatens Javascript hegemony
They have over the last 6 months as more and more people are realizing that pure JavaScript is not entirely suitable for large scale applications that are becoming more common. As someone said, the efforts to make it so are 'heroic,' but obviously the hard way to do things, like choosing to write a large application in assembly language. Having done that once, I would never do it again, and would take someone who said this was best less seriously.
Believe it or not, there's some internal projects done in LISP and Haskell. Obviously there are limits to what you can do. If you work on some new big customer facing project, it's a lot harder to get a big team of people to agree to use Haskell, but if you are working on a 20% project, it's a lot easier to just use whatever you want.
With Google production servers, there's only a few "approved" languages. I can't just go deploy a Rails app in one of Google's datacenters, for good reason, especially when you consider security.
With app-engine or compute-engine there's slightly more freedom.
I worked in Dart for a few months and loved it, but recently had to look for something else for older browser support. I started writing code in TypeScript a few days ago and, face palm, why didn't anyone think of this sooner? Visual Studio with TypeScript and jQuery type definitions gives me most of what I need from Dart (80/20 rule). It's really fun to code with. JavaScript with types feels like a sunny day. I've been complaining a little about Dart js-interop (size and speed) and now feel my instincts were right; if Google doesn't fix js-interop, then I'm struggling right now trying to understand why I should use Dart, unless Google is more clear about a different use case for Dart on the client (Android.) If all the JavaScript 'Ninjas' discover TypeScript and have the same reaction I just did, then Dart is going to struggle on the client because it doesn't operate well in the current JavaScript eco-system like TypeScript does. Someone high up in the company and outside the Dart team needs to make a strong statement about where the Dart VM is going before the window closes.
Audience? I know plenty of programmers who hate JavaScript for not having classic object model. I make my living as PHP programmer and hate JavaScript too for exactly that reason. I did only jquery with plugins and inline code mostly with effects and ajax load coding.
I tried DART and did multiplayer online game http://shipsonline.org/ as my first "hello world" without any external code. Epic win for myself. It has more than static typing, please try write simple app and you will see. Eventualy it became stable and then became mainstream popular i hope.
Dart isn't done. Most people aren't going to use it for real projects until it's at least 1.0. Furthermore, Dart really won't shine until its vm is built into Chrome.
Gotta disagree with your panning of static typing. Dart is targeting large web applications- apps written over the course of months and supported for potentially years, by a team which changes over the course of the project.
The thing isn't static typing- it's static analysis. The ability to specify contracts in your code and have something validate your code. This is the same thing TypeScript and Closure try to address, but Dart is trying to tackle the issue at its core, with performance to boot.
For better or worse JavaScript is the lingua franca of the web, so if you want to go home early instead of tracking down compiler errors of the translation tool, the best way is just to use JavaScript.
Dart will never take off if the other vendors don't offer VM support on their browsers. Almost every language has JavaScript transpilers and as a Chrome only solution it won't work.
Not necessarily. Dart provides 2 options:
- A strong tool supported language that translate to Javascript. So you developed large applications far easier with Dart VM in the browser, then just compile to Javascript for deployment. Debugging will happen in Dart mostly.
- A multi platform Runtime (Chrome) for high performance demanding applications. Application runs on browser it is far better than writing Windows - Mac - Linux specific application to me. And more appealing than Java. Also Chrome with Dart VM will work in Android. Another plus.
Funny I am developing since 1986 too. One of the reasons of the chaos is JavaScript. Yet like it or not after mid 2000's many complicated apps are targeted to web only (Gmail etc). Now with the advance of new APIs Browser started to behave like an operating system - or runtime environment allowing rich-high performance application development. But JavaScript is still as ugly as before and I see Dart as a perfect high performance alternative that happens play well with JavaScript. I would gladly develop an application that run on Chrome rather than runs on Windows or Linux only.
The Dart VM reads and executes source code, which means there is no compile step between edit and run. As with other popular scripting languages, it’s very quick to iterate with Dart. The Dart VM runs on the command line and servers, and can be embedded into browsers. Just point the VM at Dart source code and you’re up and running!"
By that definition Dartmouth BASIC is a "source code VM" aka an interpreter. Why call it something it isn't?
I think Dart is interesting in its own way, and generally a useful exercise for thinking about how you might write an interpreted language that can run in untrusted contexts, but beyond that I don't "get" the problem it is trying to solve.
The problem it's trying to solve is that Google's JavaScript optimizing team is hitting the limits of what they can do to speed the language up given the constraints imposed by JS.
They want a replacement language that's more optimization-friendly so that they can continue pushing for faster Web clients.
Given this creator goal, and most programmers' goals of "use a language that better suits my needs," it's not terribly surprising that Dart hasn't seen the kind of community interest that CoffeeScript has.
That's not the only problem Dart is trying to solve. Productivity and the ability to build good tools for the language are huge factors in Dart's design.
That's why it has libraries, type annotations, a declarative top-level structure, and some of the reason for closed objects. Good tools for Dart are _much_ easier to write than tools for a very dynamic language.
CoffeeScript, TypeScript, GWT and every other language transpiling to JS gets hit with the compilation cost to first compile to JS (possibly waiting to emit source maps as well), after that point the browser can load and execute the compiled JavaScript.
When developing and running in the DartVM, Dart code can run natively inside the Dartium browser without needing to compile to JS first. Also Dart is declaratively structured and optimized for fast start-up times (e.g. opts for lazy loading) which means they can start JIT'ing and executing from the main(){} entry point (which is also the point where snapshots are saved at).
The DartVM uses a method JIT which compiles the source code directly to machine code. An interpreter has a main loop which runs instructions one at a time.
Wikipedia is a good place to start if you'd like to understand the difference.
I think you should probably read the links you post. They are close to claim exactly the contrary of what you say. As the Wikipedia article rightfully points, the difference is far less obvious than you make it seem.
The definition of an interpreter is generally broader than a main loop running instructions one at a time. For example, everyone seem to agree that Python is an interpreted language while python interpreter transforms the source code into an IR before passing that to its main loop. Truth is the line between what is a VM, an interpreter and a compiler is rather fuzzy.
The implementation of a process virtual machine clearly is an interpreter of a bitcode. Now, it's not entirely absurde to consider the couple JIT and VM taken together as an interpreter. Actually, this is clearly encompassed by the third point of the definition of an interpreter provided by Wikipedia : "explicitly execute stored precompiled code[1] made by a compiler which is part of the interpreter system".
To come back to the article discussion, I agree with the previous poster than the expression "source code VM" is kind of meaningless. Actually, the paragraph following is even plain wrong. The Dart VM executes bitcode not source file and Dart is JITed.
In the same way, I find it quite surprising that forty years after Hindley paper, people still confuse type annotated and statically typed but well, c'est la vie.
Have a read about V8 and the DartVM's architecture. V8, and the DartVM have a different architecture than IE's Chakra and Firefox's monkeys. They use a method JIT which initially generates very simple native machine code directly from the AST. The machine code includes instructions to identify hot code, which is re-compiled again from the AST. The optimizing compiler converts the source into an SSA form, and IR, but this is not byte/bitcode. This is what Bak et al are referring to when they call this architecture a "source code vm".
Lars Bak on channel 9:
Bytecodes are a silly thing in my mind.
They can be used for different things interpretation. But interpreters are really slow.
But they can also be used as a wire format, for instance in .net or java where that's what you ship over the wire.
In javascript the wire format is sourcecode, and for each function you have, inside the running javascript program, you have to cook up the source code again. So that is the primary representation.
So we just decided why not generate native code right away because the CPU is pretty fast.
Just like V8, the Dart VM doesn't have an interpreter. The code is directly compiled to (fairly crude) machine code. Later, the hot parts are replaced with better machine code.
Dart's optional typing is effectively a dynamic language that allows you to decorate your source with optional Type info that effectively just acts like documentation for other developers and automated tooling.
It's far more readable and concise having it embedded in the language rather than buried and disjointed in the comments. Not to mention it also allows for superior tooling support.
I've personally been extremely productive with Dart (most productive I've ever been with any language). It's effectively a more consistent JavaScript with less ceremony with the benefit of optional typing which has caught errors on a number of occasions, giving instant feedback and identifying errors before I've even run the code.
Do you just use Dart on the client side, or also do server side using Dart? I have been using Clojurescript and Clojure for client and server coding, but I might be interested in trying another "one language" stack.
Many of the libraries I've helped write are server-only, you can see a list of them at: https://github.com/Dartist
Although Dart on the server is still in its early stages so you might not find all the libraries you need, e.g. I ended up writing my own Redis Client (https://github.com/dartist/redis_client) since there were fewer mature options. All the server APIs are there for you to build a node-like server, it's just the web frameworks and view engines are currently lacking so you might find yourself having to write more frameworks/libraries than you would otherwise on node (which is a lot more mature atm).
I'm hoping after the Dart team finish the work on integrating the Dart VM into Chrome that they'll focus on the server-side of the "full stack" and provide support for App Engine, incidentally star this issue if you would like to see support for this sooner: https://code.google.com/p/googleappengine/issues/detail?id=6...
I can definitely understand the sentiment if you haven't tried it. I knew optional typing existed in AS3 (which I use for prototyping certain ideas) for a long time before finally taking the plunge and using it here and there. It lets you blast through experimental code and remain nimble until such time as you want/need to add typing. Also a nice way to avoid long chains of method overloads, including overloading methods that only differ by return type, which is impossible to do in some (many?) languages.
See, this is where the philosophy of languages like Dart and Java differs significantly from Haskell and friends. In the former, it makes sense to write code first and then try to get it to typecheck afterwards. In Haskell, this does not really happen: the types are at the very core of your code.
When I write a Haskell program, I start with the types and the code grows from there. The types are really the foundation for everything else. It doesn't really make sense to view the code without also thinking about types: after all, Haskell code is centered around functions, and functions are defined by their domain and codomain.
Among other things, this means that the types actually help me to prototype. Iterating on different types and seeing how that changes the sort of functions I can write is a very powerful technique. This is going to become even more apparent in the near future with features like type holes. The basic idea there is that you can leave parts of your code blank, and the compiler will tell you which type goes there! The type system can actually help you write the code.
Honestly, I think the difference between types in Java and Haskell is at least as large as the difference between types in Java and dynamically typed languages.
Yea, as always, depends on what you're doing. I agree 100% with your points for when I'm writing mission-critical code from the start. But when I'm busting out UI at 2:00AM, it's all fast and loose. A lot of code I write is somewhere in the middle.
No, you didn't quite see my point. In Haskell, types aren't only about correctness--they're also about expressiveness. They help you program beyond correctness--they even help if you're just hacking around. Moreover, they're sufficiently central to practical code (even, at the risk of repeating myself too much, hacky code) that it wouldn't really make sense to write untyped Haskell and try to stick types on afterwards.
Basically, in Haskell, the types go well beyond correctness. I hope this clarifies what I mean.
I think it's rather natural. Look at Haskell. Static typing with type inference was recently extended to allow "holes" in the type system. It lets you run broken programs, and let's be honest, my programs are broken (in some sense) most of the time. C++ lets you use the "auto" keyword in many places. Maybe the only thing strange here is that Dart has more of the "dynamic by default" mentality, but that's not strange either if you look at languages like Common Lisp, which have optional type annotations.
Here's optional type annotations in Haskell, which uses type inference by default but lets you override types with annotations. Note that f and g have different types, but the same body.
-- Haskell
f = return 5
g :: IO Int
g = return 5
Here it is in Lisp, which uses dynamic typing by default but lets you specify types with annotations.
; Dynamic +3 function
(defun add3 (x) (+ x 3))
; Static +3 function for integers
(defun add3 (x)
(declare (type integer x))
(+ x 3))
Optionally specifying types which are otherwise inferred is not the same as optional typing. Haskell expressions always have a type. Often the compiler is smart enough to figure out what it is without you explicitly telling it, but it still has a type. Haskell typed holes still doesn't allow you to escape from the type system, it's more a way of saying "Here I am in the middle of an expression and I'm lost, could you tell me what fits here in your opinion Mr. Compiler?" It still has a type, it is not a way that you can just feed the compiler type-gibberish and move on.
In Dart, the types appear to be little more than advisory documentation.
I don't know Lisp; what happens to your add3 if you pass a thing that can't be added to 3? Does it crash at some sort of 'type checking phase' (whenever that may be) or only when it finally discovers it can't do the addition, essentially ignoring the type declaration? (Or both and neither, depending on what exact Lisp and macro set you're using, which is my guess.)
> Often the compiler is smart enough to figure out what it is without you explicitly telling it, but it still has a type.
I may be wrong, but I suspect you don't know how Haskell type inference works. (1) This is just semantics, but the compiler is not "smart" and does not "figure out" types. It uses a straightforward type unification algorithm (should feel natural to anyone who's programmed in Prolog) with a monomorphism restriction. (2) The type annotations you add may be different than the types that the compiler would deduce in their absence, and these annotations may in fact be necessary in order for the program to be correct.
Your question about Lisp has already been answered, but I will expand. The type checking can be done at runtime, at compile time, or at some combination of both—it is not always possible to deduce the type of function arguments at compile time in a language like Lisp. Obviously, (+ 1 "ABC") is an error, but not all situations are so obvious. The same is true in Python, Ruby, JavaScript, Objective C, Java, Haskell, and any other language which supports dynamic typing.
Yes, it is. That entire paragraph was... less than useful.
"Yes, Haskell supports dynamic typing."
Yes, it does, but not with any of the features you've discussed. It supports it with Data.Dynamic. Type holes are still as I described; they are not a way to escape the type system or make it compile something that does not have some sort of concrete type, they are a way of asking the compiler what type it thinks goes somewhere. Here, the first hit for "ghc type holes": http://www.haskell.org/haskellwiki/GHC/TypeHoles
"This is the purpose of a hole: it has similar semantics to undefined, in that evaluating it is an error (you can replace all holes with undefined, and vice versa, and nothing has changed: you may even say undefined is just a really crappy, useless hole!) But it's special in that when GHC encounters a hole during compilation it will tell you what type needs to be there in place of the hole, for the type-checker to be OK with the definition."
This is not dynamic typing. It may superficially look like it if you just gloss over the definition, but if you really understand it that's not what it is. There is still some sort of concrete answer (concrete to the type system, for which constraints aren't that big a deal).
I return fire: I suspect you don't understand how Haskell type inference works, since you're making false claims about these features.
Common Lisp implementations have some latitude in what they do here, but the most popular one, SBCL, will fail at compile-time if sb-ext:derive-function-types is true (an SBCL-specific extension). Otherwise it will trigger a runtime error if compiled under high SAFETY, and a memory fault under low SAFETY.
It's like the kind of JSDoc annotations you need for the Closure Compiler.
The difference is that it's baked into the language, which enables a very terse syntax and, since it's standardized, it can be used by all of your tools.
You only need those annotations at the API boundaries (arguments and return values) to get most of the tooling benefits like call-tips, auto-complete, direct & inferred static checks, runtime checks, generated documentation, and things like that.
This video (at 26:13) gives a pretty good example of why these might be useful: "Dart: Google's evil plan to make it easier for you to build web apps" http://www.youtube.com/watch?v=9RCuW6K1afs
No, in Dart it's not like that at all - almost the opposite. Type annotations have absolutely no effect at runtime. As the Dart documentation[1] says, "Adding types will not prevent your program from compiling and running—even if your annotations are incomplete or plain wrong.
Your program will have exactly the same semantics no matter what type annotations you add."
Dart can run in production mode where type annotations have no effect, or in checked checked mode where they will trigger a runtime error (i.e. behave like an assert). So you're both right ;)
There are two execution modes for Dart: checked mode and production mode. Check mode inserts type checks for assignments and parameters. This, together with the static analysis that the Editor/analyzer does, generally works as well as full static typing, in my experience.
If you accept the modern notion of types as proofs, dynamic languages are correctly described as untyped since they prove nothing about the code they run.
Unfortunately the term "type" is also used to refer to the tags dynamic languages put on data to prevent illegal operations. Confusion inevitably results.
Here is what I think about Dart: it is huge and is another programming planet that you can't reuse what you already have (like thousands of libraries in NPM).
And the most important part; it looks boring. the articles about it look also are very boring.
Here is what I think about Dart: it is huge and is another programming planet that you can't reuse what you already have (like thousands of libraries in NPM).
Dart has a js-interop library for the times that you want to reuse some code written in JavaScript. This video gives a good introduction to it: http://www.youtube.com/watch?v=QFuCFUd2Zsw
And the most important part; it looks boring.
That's was a big design goal when they created the language. It's designed so that, for the most part, it looks and behaves like other languages that you're used to. You can pick it up in an hour or so and be productive right away. The Dart team didn't want to create some esoteric language with all sorts of crazy features, they set out to create a real language that people would feel comfortable using.
There's no wall; the spec is public, and the implementation is open source. Any other browser could add direct Dart support tomorrow if they wanted to.
The JavaScript output runs on all of those browsers, but only Chrome (or actually the special "Dartium" version of Chrome) has a VM to run Dart code directly.
Dart brings improvements to the language and tools that are worthwhile regardless of the VM being available in the user's client. dart2js is the primary method of deploying Dart code, and there's nothing bad about that.
Most of them's tool support does not even compare to Dart. Dart code can run directly in Browser for the starters, multiple strong IDEs, sane debugging and modularity support.
He said "for development". The nice thing about the VM in Dartium is that you don't need to compile as part of your development workflow until you need to QA and deploy, just edit and refresh. You don't need the VM in consumer browsers to get that benefit.
Chrome has more market share than it did when Dart first was announced. That makes the decisions they make more influential.
If they can design a new language that's worth switching to and embed the VM in their browser, the other vendors will be more likely to implement it than when it was the little-browser-that-could. It's not a slam dunk (part of the reason Blink splintered off from WebKit was the pain of supporting two VMs), but the weather is changing quickly for Dart's chances to be a first-class language.
The language looks great. The challenge I think is always building enough of a community to create a rich enough stack that people can build real-world applications on. Scala did a fine job there, and a lot of that had to do with some companies taking some ownership of the platform (TypeSafe in that case), which may be good and/or bad. I wander what others think of this.
Your little typo "wander" instead of wonder kind of demonstrates the point of Dart. It's a language that seems to provide more of a safety net for developers. We all make trivial mistakes, probably daily. It's nice to have a little more support in a language to help us along.
Throw in the extra performance (2x?) over Javascript and I'm ready to at least give it a try.
The Dart VM is 2X faster than V8 on a few benchmarks already. Check out https://www.dartlang.org/performance We've still got a bunch of work to do, but the initial results are encouraging.
For those interested, a great place I've found in keeping up with Dart announcements and to get in touch with the Dart community is on Dart's G+ Google Group:
I really like the feature set and feel of Dart. My only concern is lack of browser support.
As of May 2013, Microsoft Internet Explorer, Mozilla Firefox, Opera Software's Opera browser, and Apple Safari have no plan to embed a separate Dart VM [1].
What would it take to get these vendors to add support?
Because Dart compiles to JavaScript (which can even perform better than handwritten JavaScript to perform the same actions[1]), it runs everywhere. You don't need the Dart VM built into a browser for your Dart application to work; it already works today.
What would it take to get these vendors to add support?
I think that likely they would want to see more applications written in Dart. If a big company (like Facebook, for example) wrote a large application in Dart, other browser vendors would see both that big name developers are using Dart for their applications and they'd see the performance boost that browsers with the Dart VM built in take advantage of[2]. This would make it more compelling for them to include a Dart VM in their browser.
That shouldn't stop anyone. Dart works fine in every modern browser (and IE9), because you can compile it to JavaScript.
Generating minified Dart code is one line and compiling to minified JS is also just one line. If you do one in your build script, you can also do the other. It's a no-brainer, really.
I like what I see in the article, but... I'm kinda put off by the seemingly high barrier of entry. All the tools they show off are great once you've started, but I don't want to install all that just to try a slightly more advanced "hello world" sample.
It's really too bad there isn't an equivalent of play.golang.org for Dart. I would've given it a try right now if the barrier of entry were lower, and perhaps I'd be pleasantly surprised enough to keep using it.
Also, is it possible to generate and execute Dart code within Dart (the way it is in dynamic languages like JS) without recompiling?
Anyhow, the barrier is actually pretty low. The editor zip is about 140MB in size and contains everything you need: the SDK, the editor, and Dartium (Chromium + Dart VM).
I've read post after post about Dart. It looks really neat. I want to try it sometime.
Now can Google use it to do something big and important? Please? We want to see that it works for you. Invest in it by building products with it and show us we should do the same.
So, I've thought for a long time ... if I could take a clean sheet of paper and write [a new language] that retains all the goodness of [JavaScript] ... I would not have come up with anything like Dart. - Douglas Crockford
One thing I'm not too crazy about is that, AFAICT, it seems that you need a Google account in order to upload packages to its cpan-alike, http://pub.dartlang.org/ .
Can the Dart package management tool fetch/install packages which are not hosted at pub.dartlang.org? Can it install packages straight from a github repo?
I don't know Dart but I m intrigued by this "Dart is purely object oriented". Seems that people don't like some fundamental characteristics of javascript: the functional part and the prototyped based OO style. Is it still possible to use this in Dart or it is like the author said, purely OO?
Supporting first-class functions only makes a language "functional" in the smallest sense.
Functional programming goes far beyond that. It encourages things such as immutability, referential transparency, powerful pattern matching, the heavy use of recursion, and robust type systems.
JavaScript either does not support such techniques and concepts, or it makes them difficult to use. Thus it is improper to consider JavaScript a "functional" programming language.
The same goes for JavaScript's so-called support for OO. Prototype-based OO is one of the least-useful approaches to begin with, for real-world software development, and JavaScript even manages to implement it quite badly compared to other languages offering prototype-based OO. JavaScript's complete lack of class-based OO (although, we may see this change with future revisions of the language) further suggests that it's wrong to call it an "object-oriented" language.
I'm not sure we can even make this comparison. JavaScript is, at best, an imperative language that has tried, rather poorly, to partially incorporate concepts from more advanced programming language paradigms. It's hard to imagine Dart, or any other language, supporting more advanced concepts any worse than JavaScript already has.
Languages such as Java and C# have a distinction between objects and primitives such as int and bool. In Dart all types are objects - even null! This is why Dart is pureOO.
Dart has some of the classic higher order functions in it's core library - i.e. map, reduce etc. But it's not a functional language like Haskell.
How about a virtual machine facility that outputs what the types of variables are at runtime, combined with tools that can collate data from many runs and apply consistent types back to the original source code?
That's dangerous, because you have no way of knowing if you have 100% coverage without doing static analysis, and if you double check everything with static analysis, you might as well only do the static analysis in the first place. (Static analysis won't always give you an answer, but it won't ever give you a wrong answer.)
I am reminded of the folks who optimized .kkrieger, which is a 95 kB first-person shooter. See "Metaprogramming for Madmen":
Some highlights: during the test run, the player never pressed the up arrow key in the menu, so that functionality was removed by their tools. Enemies at the beginning never hit the player, so the code which handles damage was compiled out. And the system used a certain brand of graphics card, so code necessary for other graphics cards was compiled out.
The lesson is: don't let tools change code semantics based only on black-box testing.
> That's dangerous, because you have no way of knowing if you have 100% coverage without doing static analysis
You are right from a theoretical standpoint, but I'm not so sure this fits with how web applications are known to run and the patterns development usually follows.
Developers who shove an object of one type in an instance or temporary variable one time, and a different one another time are usually doing something bad, even in dynamic environments -- unless there is a specific interface involved. Just because "duck typing" is fast, doesn't mean that it has to be loose.
The point, actually, is to discover where types are being misused as much as to discover what the types are.
> The lesson is: don't let tools change code semantics based only on black-box testing.
I'm also advocating this. However, it seems like you're mainly familiar with dealing with types in statically typed environments. In dynamic environments, the developers still need to know the types. Often, there are hard and fast rules only enforced by convention. This is indeed a source of errors, but by and large, programmers are very good at managing this. In other words, very often, the programmers will know. I see environments like Dart as a way to eliminate such conventions, but still enable very fast prototyping in the beginning. (Ultimately, static types are better for maintenance.)
Members of the team and community have talk about such a tool, also tools that remove type annotations to prove that they don't effect performance, or remove them from local variables to match the style guide.
Wow, I wonder why I got down-voted for stating something that was simply true. I guess it's bad the people discussed the possibilities of these tools? Interesting...
Well Dart is fun. It is fun in its own niche. It is like Java for the web. Can have types. The IDE is a central point of development. Easy to get started for those who are perhaps average in their skill. Is designed to be familiar (curly brackets and simple syntax).
It is not fun in the sense that Haskell, Erlang or LISP are fun. Oh look monadic isomorphic catamorphims with actor based concurrent meta-interpreters kind of stuff. So both fun but in different ways.
Let's see how the shout example is fun in more detail. It shows the usage of a library. This is not a require.js hack, but a nicely built in facility. Also don't have to put everything in a class like in Java. The example also shows the usage of an anonymous function syntax. Those are fun and good for short callbacks. Not fun is in academically interesting but fun for practical use. It took Java decades to acquire those.
To me Dart looks like another brick in Google's walled garden. Weakening support for XMPP, Webkit, RSS, and JavaScript. Investment in so-called open technologies like NaCL and DART that are controlled by Google and optimized for Google's platform. Too bad.
It's the most open language I know, fully OSS'ed with an extended license to include any implicit patents (removing Patent FUD), developed out in the open and accepting 3rd party contributions and inviting feedback to influence language design.
Lars Bak also mentioned at Google I/O that they're in the process of trying to get it standardized, not sure what's left to do to make it any more "open" and inviting.
Let's not pretend that Google's open source products in any way follow an open development process. Do you notice anything in common about the recent committers?
Their development is very much insular. That's not to say it's a poor idea to depend on these products, but they don't compare to projects like Python with formal processes for revisions (PEP) or at least some discussion.
It would be nice if Google maintained mirrors on Github and accepted pull requests and such, but I don't see that ever happening.
If code reviews are happening in the open and there's a process to bring new contributors on board, that's a great start. This early in the game, you can't expect random members of the open source community to start contributing more than a dedicated team at Google.
> It would be nice if Google maintained mirrors on Github and accepted pull requests and such, but I don't see that ever happening.
I really don't understand why people insist that "open" must mean a project is open to every and all random contributions from people outside the project. The source code is there for you to use as you please. If you want your ideas committed to the mainstream you have to persuade the people in charge.
I have to wonder what agenda drives people to claim that this is not "in any way" an open development process.
Actually, I wish Dart were a little less open and had more of a directed focus. Some one like a Linus needs to step in once in awhile and say "you're wasting your time talking about that feature because it's never going to happen."
How about putting it in the care of an independent foundation like the Python Software Foundation? Until Dart is wrested from corporate control Python will still be the more open language.
How would that make it better? Are software foundations some magical thing that makes all software that comes out of them better? Is this hatred toward large companies?
Direction coming from a company that has a goal for the language can be a good thing. Java was an amazing language for a number of years until Sun decided to let it languish.
Dart is under a very open license that anyone can take any part of the language and use it for their own. The website, spec, vm, analyzer, compiler, and editor are all under open and free licenses. If people get fed up with Google's handling of Dart, they can fork it.
The original claim was that there was no language as open as Dart. I vehemently disagree. Plenty of languages are as open as Dart, and there are several, including Python that are more open. I believe you are underestimating the importance of a language having its own foundation that exists for the sole purpose of ensuring that a language remains vibrant and free. Do you think the PSF would ever make a contributor sign a document before contributing as Google requires for Dart? Also, do you think it's better for a corporation to own the trademark for a programming language's name, or an independent, community run organization? Google owns DART's trademark.
I think Java is a great example of why corporate programming languages are a bad thing. Do you remember the first wave of Java adoption? Do you remember how it was adopted in all sorts of places it had no business being because Sun rammed it down everyone's throats through their sales force? The core of Java and the engineering behind the VM are thanks to Gosling, not Sun.
I'm not criticizing Sun here, either. That's just how it was done back then. Sun was positively benevolent compared to the likes of Cincom.
Dart compiles to JavaScript, much like CoffeeScript, Microsoft's TypeScript, Haxe and many others, and they still make the fastest JavaScript VM on the planet.
Yes and no, An important caveat that Dart as JavaScript runs in it's own isolate and communicates with existing JavaScript libs through ports. This js-interop code is nearly 500k unminified. And you won't be able to minify all your JS (dartJs + other js) into one lib, because dart js doesn't play well with standard tools. One can certainly interop with js libs, but it's not pretty. Dart is not near 1.0 yet, so there is still time for improvement, but this doesn't seem to be a priority. Dart is great, don't get me wrong, and I've been working with it for several months, but I think this point should be made in fairness. You're really going to want to go all in with Dart and leave your custom js libs behind or convert them to Dart. If you have the luxury of working with just Dart code, then you'll be in for a pleasant surprise at how productive you can be and how fast the Dart VM is.
Yes, I think so too. The question about the need for an isolate has been asked by a Google's own Dart evangelist, so it's on their minds at least. Notice there wasn't much of a response. It's not a hot issue, but I think it will be.
TypeScript is good that you can transition gradually. I've been using it for the past week and it almost feels like working with Dart with the advantage that's it's just JavaScript. TypeScript interfaces to hundreds of JavaScript libs and jQuery plugins have already been written.
I imagine I'll settle on Dart for some things and TypeScript for others and maybe eventually get them working together.
On the opposite side , with a little bit of "header" writing ( or none but you lose type safety ) , Haxe support direct use of javascript libraries , that's what makes Haxe better than dart in my opinion, and you can reuse all the code that is not tied to the DOM is C++,Neko,Java and Flash apps (and android + iphone + ... with the NME framework ).
But Dart optional type system is still interesting.
For that audience, they are given a language with optional static typing (most don't want it) and an Eclipse-based editor (most don't want it).
By way of contrast, consider Go. Go is (in my opinion) an extremely successful successor to C, in terms of its design. It fixes a handful of problems with C (strings, and I would argue pointer arithmetic), and modernizes and streamlines it. The interface system is fantastic. In terms of its design, I have nothing but good things to say about Go.
Dart does not seem to improve on JavaScript in a compelling way. It adds optional static typing, and as far as I can tell, nothing else.
Is it any surprise that Dart has failed to take off?