Earlier quoted context omitted.
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." [1] http://www.dartlang.org/articles/optional-type…
Wait what? "Adding types will not prevent your program from compiling" So even if you type-annotate everything, you will never get compile-type type errors? That makes the whole thing seem completely pointless.
Dart Is Not the Language You Think It Is
131–140 of 143 posts
Re: Dart Is Not the Language You Think It Is
#132Who 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…
"It adds optional static typing, and as far as I can tell, nothing else."
And as far as I can tell you don't have a clue of what you're talking about.
Re: Dart Is Not the Language You Think It Is
#133Earlier quoted context omitted.
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…
> 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 monomor…
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.
Re: Dart Is Not the Language You Think It Is
#134Earlier quoted context omitted.
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.
I think watching what Google itself does with Dart vs Closure is going to be an interesting tell.
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.
Re: Dart Is Not the Language You Think It Is
#135Re: Dart Is Not the Language You Think It Is
#136Earlier quoted context omitted.
I think watching what Google itself does with Dart vs Closure is going to be an interesting tell.
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, Flight…
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.
Re: Dart Is Not the Language You Think It Is
#137Earlier quoted context omitted.
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, Flight…
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 interesti…
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.
Re: Dart Is Not the Language You Think It Is
#138I 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?
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.
Re: Dart Is Not the Language You Think It Is
#139Who 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…
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 addr…
Re: Dart Is Not the Language You Think It Is
#140Who 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…
To answer you first question: Anyone fits in "the audience for Dart", If you're ready to use CoffeeScript, why wouldn't you give Dart a try? "It adds optional static typing, and as far as I can tell, nothing else." And as far as I can tell you don't have a clue of what you're talking about.
I received a lot of thoughtful, intelligent responses to my post, including many that disagreed. Unfortunately, yours was not one of them.