Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dart Is Not the Language You Think It Is

programming.oreilly.com

Post reply on HN
Print view View original

1–10 of 143 posts

Re: Dart Is Not the Language You Think It Is

#2

Post by barabaraphil »

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.

Re: Dart Is Not the Language You Think It Is

#4

Post by melling »

barabaraphil wrote: post #2

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.

Re: Dart Is Not the Language You Think It Is

#6

Post by dietrichepp »

willlll wrote: post #5

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

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))

Re: Dart Is Not the Language You Think It Is

#8

Post by spankalee »

stcredzero wrote: post #3

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?

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.

Re: Dart Is Not the Language You Think It Is

#9

Post by ericssmith »

willlll wrote: post #5

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

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

Re: Dart Is Not the Language You Think It Is

#10

Post by dietrichepp »

stcredzero wrote: post #3

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":

http://fgiesen.wordpress.com/2012/04/08/metaprogramming-for-...

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.

Post reply on HN