Live data from Hacker News

Dart Is Not the Language You Think It Is

programming.oreilly.com

41–50 of 143 posts

Re: Dart Is Not the Language You Think It Is

#41
post #14
post #12

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.

Walled garden?? 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 i…

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?

http://code.google.com/p/dart/source/list

http://code.google.com/p/closure-compiler/source/list

http://code.google.com/p/closure-library/source/list

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.

Re: Dart Is Not the Language You Think It Is

#42
post #33

Dart is exactly the language that I think it is. It is too bad that it doesn't run on many browsers but that isn't going to change. What is the point of using Dart other than to join Google's garden of ugly walls?

Dart runs on IE >= 9, Firefox, Safari and Chrome. Why is that "too bad"?

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.

Re: Dart Is Not the Language You Think It Is

#43
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?

Re: Dart Is Not the Language You Think It Is

#45
post #42

Earlier quoted context omitted.

Dart runs on IE >= 9, Firefox, Safari and Chrome. Why is that "too bad"?

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.

Why does that matter?

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.

Re: Dart Is Not the Language You Think It Is

#46
post #11
post #5

Untyped languages are okay. Typed languages are also okay. Typed languages with inference are okay. Optionally typed is extremely strange.

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 met…

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.

Re: Dart Is Not the Language You Think It Is

#47
post #24

Earlier quoted context omitted.

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…

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 yo…

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.

Re: Dart Is Not the Language You Think It Is

#48

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 wa…

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.

Re: Dart Is Not the Language You Think It Is

#49
post #42

Earlier quoted context omitted.

Dart runs on IE >= 9, Firefox, Safari and Chrome. Why is that "too bad"?

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.

Pure Dart code isn't realistically intended to be run on user-facing websites for now. At the moment, Dartium is primarily intended for developers.

Re: Dart Is Not the Language You Think It Is

#50

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 wa…

The primary audience, is web developers.

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).
Post reply on HN