Hacker Newsnew | comments | ask | jobs | submitlogin
More information on Google's new web language, Dash (markmail.org)
253 points by praxxis 951 days ago | comments


sriramk 951 days ago | link

As an ex-MSFT person, this doc sounds like a Microsoft doc more than something you would see from Google.

And I'm amazed at sentences like these - can you imagine MSFT saying this and getting away with it? "The goal of the Dash effort is ultimately to replace JavaScript as the lingua franca of web development"

and

"What will Google developers be using? We will strongly encourage Google developers start off targeting Chrome-only whenever possible as this gives us the best end user experience."

-----

deno 951 days ago | link

And also: ”Developers using Dash tooling will be able to use a cross-compiler to target Javascript for browsers that do not support Dash natively.”

Not very different to having native support for e.g. CoffeScript in browser X and supporting other browsers via JS.

Of course the main issue is that this is yet another language. Since all browsers are essentially becoming poor man’s virtual machines, why not drop the pretense and adapt some kind of bytecode instead. There’s JVM/CLR/LLVM/NaCL — just pick one already! Alas, politics (Oracle/Microsoft/Apple/Google).

Well anyway, Dash is a very positive news nevertheless. The biggest issue with current cross-compilers (GWT, Pyjamas, Haxe etc.) is that they lack good tools to develop and debug. Having support for those natively, there’s hardly any reason to target JS directly anymore. And once Chromium has the infrastructure to support more than one language, it’s possible that the abstractions will be general enough to add support for other languages as well.

“Our approach is to make an absolutely fantastic VM/Language and development environment and build great apps that fully leverage it in order to help other browsers see the wisdom in following. Once Dash has had a chance to prove its stability and feasibility, we are committed to making Dash an open standard with involvement from the broader web community.”

-----

leoc 950 days ago | link

Mainly browser-vendor politics - MS/Apple/Opera/Mozilla. A proper runtime would weaken their chokehold over the Web client. It's almost certainly not a coincidence that the one major browser vendor which does support a VM is the one which is mainly interested in the Web client as a platform for its applications. Of the other four, two have strong interests in holding back the Web as an alternative to OS-native applications, while the remaining two are more or less nothing without their position of power over Web standards.

-----

ootachi 950 days ago | link

I can't figure out what you're implying. Why would the two organizations that are "more or less nothing without their position of power over Web standards" be opposed to making the Web better able to compete with native apps? After all, if the Web loses to iOS and Android, then Opera and Mozilla become irrelevant.

The reason why Opera and Mozilla oppose bytecode standards is that they genuinely think they're a bad idea. I mean, we tried that once; it was called Java. It lost to JavaScript.

-----

georgemcbay 950 days ago | link

Java (in the browser) was a plugin that was mostly completely sandboxed from the real page DOM with its own entirely separate (and very poorly designed -- AWT was horrendous) attempt at a UI layer. That's the problem it had, not the fact that it was a byte-code based VM.

Make the byte-code VM a first class citizen and things are completely different.

-----

deno 950 days ago | link

Even having the option to load a single JVM instance and share it between different frames/pages/tabs would be a tremendous improvement over current situation. At the present, the best you could do is to fake it using inter-frame communication (and some heuristic to elect most-likely to live longest), which is only slightly less bad.

-----

wahnfrieden 951 days ago | link

NaCl is LLVM, bby the way. Portable NaCl is really cool though - it's an intermediary LLVM bytecode that's cross platform.

-----

sp332 950 days ago | link

The next version of NaCl, called PNaCl, will be LLVM. Right now it's all native code (x86, x64, or ARM).

-----

nxn 950 days ago | link

Just wondering, how do you know it's going to be the next version?

-----

sp332 950 days ago | link

It's already under development. Here's the (perhaps optimistic) roadmap: http://www.chromium.org/nativeclient/pnacl/release-roadmap

-----

jdonaldson 950 days ago | link

I'm not sure what you mean by Haxe debugging. That happens with whatever run time debugger you have for js, php, etc. As far as development goes, there's flashdevelop, an eclipse plugin, a few textmate bundles, a vim package, etc. http://haxe.org/com/ide

If you don't mind me asking, what part of debugging/development in haxe turned you off?

-----

deno 950 days ago | link

I’m not familiar with haXe all that well, just enough to include it in the list. However, in the end haXe is too, statically translated into Javascript. GWT has an excellent debugger as well, but there’s only so much you can do on that level of indirection.

-----

rwolf 949 days ago | link

"Just debug the machine-generated code instead" is not really an answer.

-----

azakai 950 days ago | link

Indeed. Especially worrying for me was this phrase which appeared a few times:

> Developers who can focus solely on Chrome can [..] Developers focusing on all browsers will have to [..]

This seems to imply that Chrome is the preferable target: If developers can focus soley on Chrome, they should. Or if they must target all browsers, which is less desirable in the viewpoint here, then there is some tier-two option.

Scary stuff for anyone who cares about the open web.

-----

deno 950 days ago | link

They mean that you can use Chromium as your primary target — your development stack — and their cross-compiler will take care of supporting legacy/incompatible targets. This is just like GWT does now and it seems the technology (apart from VM, grammar and debugger) will build on the existing codebase of GWT and the Closure compiler.

> What happened to JSPrime?

> The JSPrime effort was begun to unify and be a (single!) successor to GWT and Closure/JSCompiler, suitable for large-scale development inside and outside Google, including being amenable to IDE-like tools and static compiler optimizations. The JSPrime team is happily folding its efforts into Dash now that everyone agrees Dash will explicitly include the same goals.

-----

ryanisinallofus 950 days ago | link

Don't be ridiculous. The entire spec is to be open source. This is nothing like Internet Explorer. If Internet Explorer played this nice when it wanted to innovate (AJAX) from the beginning it would probably still be relevant. Is Mozilla the only corporation allowed to create new web features now?

This backwards compatible approach isn't exactly Google's idea and it's a good one. Having a backwards compatible, faster, and more sane web language is going to improve developing the open web. Why should anyone be scared?

-----

ootachi 950 days ago | link

This is exactly as open as Android. The language is developed entirely in secret, and code is dumped into a repository on the day of a big announcement. Google's preferred partners (in this case, Chrome) get to see the source before the public does.

Quibbling about whether this qualifies as "open" or not is arguing semantics, but I think recent history has shown that the Android model doesn't lead to the openness that its proponents had suggested it would.

-----

MatthewPhillips 950 days ago | link

I agree completely. The developing stuff in secret and play fast and loose with the definition of open source works fine with their own platform. The Web is everyone's platform. I find it a tad insulting to be blocked off of the process and then be told that the Elite Engineers of Google have solved this problem for us.

There doesn't have to be an exact parallel between this and ActiveX for this to be bad. Mozilla announced about a month ago that they would be developing a not-yet-cross-platform set of APIs called WebAPI. Except they invited any one to participate. I'm subscribed to their mailing list and actively participating. I can submit patches if I so choose. Dash sounds like an almost-finished product that the rest of the community has to either adopt or opt-out of.

-----

rafaelferreira 950 days ago | link

This point might be valid in general, but it can't apply to programming languages. There is no way to do language design in a committee (one might have a shot at enhancing an existing language, but it's difficult).

-----

ootachi 950 days ago | link

There's a difference between (a) doing some language design work in private and (b) doing an entire language spec, as well as all the implementation, in secret, then one day shipping it to users and telling everyone else "here's how it is, now standardize this".

I'd also argue that languages on the Web should be held to a different standard than general-purpose languages, since there are five primary players and the Web as a whole will be worse off if some of the browsers refuse to implement what other browsers are pushing.

-----

drgath 950 days ago | link

Just because it is open doesn't mean the other browsers will, or should, implement it. NaCl will never see the light of day in other browsers even though it is entirely open-source.

Until NaCl, Dash, and whatever other stuff they decide to shove into Chrome, makes it into a standards body and is recommended by WHATWG & W3C, it is an attack on the Open Web.

Don't put stuff in a browser that isn't web standards compliant, I thought we already learned that lesson?

-----

nxn 950 days ago | link

How did we learn that lesson when Microsoft did exactly what you're describing when they created XHR, and now almost every website uses it? It took 6 years for it to become standard, and I almost doubt it would have if it wasn't already in every browser by the time it did. My personal opinion is that this type of behavior boosts competition and helps innovation. If it's something clearly useful others will implement it or become obsolete. Waiting for a committee to standardize a feature before implementing it sounds like it would slow the web down to a halt. Mind you I already consider it to be painfully slow just looking at how many years it took to get 20-30 new functions into JS runtimes.

-----

MatthewPhillips 950 days ago | link

I think it's more practical for browser vendors to develop ideas (in the open, not like Dash) and use vendor prefixes (-o, -moz, etc.) and then bring those ideas to the standards bodies. We've seen this a lot recently, particularly with mobile. meta viewport tag was not brought to standards bodies first, Apple developed it and everyone else adopted it. To my knowledge it's still not part of WHATWG, although I'm sure it eventually will be.

-----

rictic 950 days ago | link

There are some examples that can convincingly target Chrome only, e.g. Chrome extensions

-----

true_religion 951 days ago | link

You can say whatever you want until you've squandered the public good will, and then the public will skeptically peruse even the most innocuous of words coming from your mouth.

People's skepticism of Microsoft is based on what they (MS) have done in the past.

-----

aaronbrethorst 950 days ago | link

Didn't you see Brad Abrams' name on that list? After all, the more things change...

And yeah, I agree: it felt exactly like reading an internal MS memo...but ballsier.

-----

larsberg 950 days ago | link

And Peter Hallam, original J#/C# compiler dev lead, IIRC.

It's like an ex-MSFT .NET party over there!

-----

aaronbrethorst 950 days ago | link

I did not know that. Hilarious :)

-----

mlinksva 950 days ago | link

"cyclone of innovation"? Sigh.

But it seems like an attempt to supersede JS with something significantly better before JS becomes further entrenched as the dominant language for nearly everything (slight exaggeration of what lots of people are saying) is worthwhile.

I wonder what Google's internal prediction markets (if they still have those) says about chances of success.

-----

zlapper 950 days ago | link

From the Executive Summary: "Push for Dash to become an open standard and be adopted by other browsers."

I think the "Don't be evil" factor is well represented on that sentence.

-----

bzbarsky 950 days ago | link

It's clear that adoption by other browsers is a prerequisite for really being able to use this, unless Chrome manages to corner the browser market.

It's clear that other browsers won't adopt something like this without an open standard.

So this is not "don't be evil" but simple pragmatics.

"Don't be evil" would involve doing something other than presenting a fait accompli to a standards body and asking for a rubberstamp.

-----

j-kidd 950 days ago | link

> Lars has promised to “sweet talk” the other browser vendors

Sweet talking is no evil!

-----

jroseattle 950 days ago | link

I can't believe any self-respecting dev would ever use the term "lingua franca".

-----

covariance 949 days ago | link

America fuck yeah! Literacy is for faggots!

-----

jroseattle 945 days ago | link

Don't try to associate literacy with douchebaggery.

-----

antimatter15 951 days ago | link

In the FAQ section, they mention a "Cloud IDE" named Brightly, which frankly seems more interesting than the language itself:

"How does this affect our cloud IDE (Brightly)? Brightly will enable building any web application in V1 using today’s Javascript plus the additions in Harmony. As soon as it is ready, Brightly will support Dash as well. We expect that the more prescriptive development aspects of Brightly that will come on line in the future will be more Dash focused."

-----

feronull 949 days ago | link

Google is working on a web-based IDE named Brightly for building JavaScript and Dart apps.

source: http://geddesign.com/post/10097230191/google-dart

-----

cousin_it 951 days ago | link

Whenever I look at all these old and new curly-brace languages, I imagine a world where they are different runtime libraries for the same language instead, and no one has to learn the subtle syntactic differences introduced by the latest group of well-meaning overlords.

I mean, there's only one widely accepted way to write a "for" loop in a curly-brace language, right? Only one possible syntax for the ternary operator. One obviously right way to organize classes and imports. A couple competing ways to declare types (Foo foo or foo:Foo), but perhaps we as a community could make a bold choice just this once? One obvious syntax for generics, and so on.

The lowest common denominator I have in mind looks almost exactly like early versions of Java, except with optional typing ("var"), some rudimentary generics and without checked exceptions.

There seems to be no good reason for new languages like Dash to embrace a different style. And there's one big reason why you'd want source-level compatibility: polyglot libraries! For example, there's a rather huge open source library for dealing with geographical coordinate systems, basically a huge bunch of complicated math with almost no platform dependencies. How awesome would it be to have it compilable for the JVM, the CLR and the Flash player from the same source code?

I'd imagine many shops would jump at the chance to future-proof big parts of their code in this way. And the syntaxes are already so tantalizingly close to each other! Juuuust different enough to enable platform lock-in...

-----

josephg 951 days ago | link

It sounds like you're not looking for a bold choice; you're looking for language innovation to stop.

The only widely accepted for loop syntax is the C-style for loop, which was invented 40 years ago and is vastly inferior to for..in loops, ruby's .each / .each_index and python's list comprehensions. That says nothing of generics[1].

The reality is, we can make much better languages today than Java or C#.

[1] http://weblogs.java.net/blog/arnold/archive/2005/06/generics...

-----

cousin_it 950 days ago | link

As a consumer of programming languages, I'd like the evolution of languages in the mainstream to be less incremental and more punctuated.

If you make a new language that's exactly like the old language but has a slightly tweaked syntax for one or two little things (e.g. changing the capitalization of the name of the string class), you're forcing lots of programmers everywhere to rewrite their code in the new flavor. You're forcing companies everywhere to spend more resources on hiring, retooling, etc. And you actively contribute to bitrot by weakening the incentives to keep old code running as-is on newer runtimes, because "no-one writes such code nowadays anyway". It's basically a lot of waste that could be avoided.

The jump from C++ to Java was big enough: it introduced garbage collection, proper modules, proper strings and other nice things into the mainstream. The jump from Java to Python, if it happens, might be marginally big enough to merit rewrites (we gain many nice small-scale constructs like dicts, generators and list comprehensions, but lose the IDE tooling and guaranteed-correct refactorings enabled by static types). The jump from JavaScript to Dash doesn't seem big enough to justify all the busywork. Please come back in five years with more shiny things.

...A man can dream, can't he. Obviously the big guys will keep introducing new languages where a new library or a new runtime could've done the job. They have incentives to do so. But it's not so pleasant to the rest of us.

You'll note that I have avoided using the word "innovation" so far. That is because genuine language innovation generally happens outside of the mainstream and takes decades to percolate. For example, the idea of list comprehensions is older than I am (NPL '77). For that matter, so is the idea of lazy pure functional programming (SASL '76), and the idea of parameterized types (ML '76), and any number of other ideas that people mislabel as "innovative" to justify creating new languages today. Adding 30-year old features into curly brace languages, bit by little bit, and forcing us to rewrite all our code at every step doesn't sound to me like the noble practice of innovation. It's more like a big coordination trainwreck.

-----

ehsanu1 950 days ago | link

As a consumer of programming languages, I'd like the evolution of languages in the mainstream to be less incremental and more punctuated.

While there is such a thing as punctuated equilibrium, I believe you'll find that evolution is largely incremental in nature. Seems like evolution simply has to happen this way, whether we're talking about biology or technology, including programming languages.

-----

quotemstr 948 days ago | link

> The jump from C++ to Java was big enough

You are aware that many people still write C++, yes?

-----

frou_dh 950 days ago | link

Today's C# is much better than its original Java-clone status. I wouldn't brush it aside lightly.

-----

StrawberryFrog 950 days ago | link

The article is specifically about generics in Java. I don't know Java generics, just the c# ones, so it's hard for me to say if the author is right about generics in java only or just wrong in general. Either way, a pointless article for this discussion.

-----

haberman 950 days ago | link

There is much much more to programming languages than syntax. If syntax was the main difference between programming languages it would be very easy to write translators from one language to another. Lots of people like their pet language more than JavaScript, so why don't we see tons of compilers like Python->JavaScript, Lua->JavaScript, Ruby->JavaScript etc?

The answer is that syntax is just the tip of the iceberg. Even ignoring major language differences (garbage collection, static vs. dynamic typing, lexical vs dynamic scoping, eager vs. lazy, threads vs. coroutines) there is an incredibly long list of very detailed semantics that you probably don't even realize you're dealing with when you move from one language to another. For example:

  - in a complex inheritance hierarchy, which method is selected for a.b?
  - how much precision do numeric types have?
  - what happens when numeric types overflow?
  - what order are arguments evaluated in?
  - what happens if fewer arguments are passed than were declared?
  - are keyword arguments supported?
  - are default arguments supported?
  - when are default arguments evaluated?
  - are simple types like integer and string classes?
  - can they be subclassed?
  - can they be monkey-patched?
  - will types be implicitly converted?  (ie 1 + "2")?
  - does 0 evaluate to true or false?  what about "0"?
  - are function arguments passed by value or by reference?
  - are values hashed by their identity or by their logical value?
  - what hooks can you define to customize the behavior of your object?
Nothing in this list is about syntax. Syntax is just the tip of the iceberg when it comes to what makes languages different.

-----

cousin_it 949 days ago | link

> Lots of people like their pet language more than JavaScript, so why don't we see tons of compilers like Python->JavaScript, Lua->JavaScript, Ruby->JavaScript etc?

Uuuuhhh, I'm really embarrassed to ask, but did you check with Google before posting that? "Tons of compilers" is exactly what we have now: https://github.com/jashkenas/coffee-script/wiki/List-of-lang... . In fact my own job involves writing Java code that ends up being compiled to JS.

I'd be overjoyed if such things were not necessary. I would even be okay with never using things like 1 + "2" or monkeypatching in 50% of my code if that made that 50% conform to some widely adopted cross-language standard. That would mean 50% less effort spent on any future rewrite. 50% less risk from using the new and shiny platform that came out yesterday. 50% lower rate of platform-induced bitrot for the project as a whole. C'mon, who wouldn't want the world to work like that?

-----

gnaritas 950 days ago | link

You presume syntax is like fashionable clothes all decorating the same basic thing underneath; that's not at all true. Syntax is a reflection of the underlying differences in semantics of these languages, they're not just decoration.

You can write procedural C style in any language, but you're not really using the language if you aren't using its idioms which will inevitably reveal the reasoning of its syntactical choices. Lisp is a perfect example, as is Smalltalk.

-----

cousin_it 950 days ago | link

I explicitly talked about minor syntactic differences between curly-brace languages, not about Lisp or Smaltalk. Switching from one curly-brace language to another generally doesn't involve any deep paradigm shift, it's essentially just memorizing a bunch of irrelevant syntax differences. If I have some procedural C style functionality implemented the same way in languages X and Y (happens pretty often), having the code 95% identical is missing out on the nice things that I could have if the code were 100% identical.

It's true that the Java runtime and the C# runtime provide different services. But the same is true for databases. Oracle's feature set is different from PostgreSQL's. Yet the database community got its act together enough to standardize the syntax for basic features at least, so you don't have to relearn inner joins when you switch, and you can mention "SQL" in job openings and be understood. (I wonder if the NoSQL community ever gets smart enough to do the same?)

-----

mibbit 950 days ago | link

BS. Syntax is exactly like fashionable clothes. It's irrelevant to how warm your clothes are.

The number of developer years wasted coming up with yet another programming language or syntax is staggering.

It's a solved problem. Pick an existing syntax and use it.

You don't see people endlessly coming up with new syntax for math do you. We've got one, it works well, so we use it.

-----

gnaritas 950 days ago | link

> It's a solved problem.

No it isn't.

> You don't see people endlessly coming up with new syntax for math do you.

Actually, yes, yes you do.

-----

ajanuary 950 days ago | link

There are many mathematical notations for the same things, usually depending on the domain or different focus. Just like with programming languages.

-----

drothlis 950 days ago | link

Choice of syntax affects how easy it will be to create tools for the language (IDE syntax highlighting, code browsing/navigation, automated refactoring, etc). There is still plenty of room (and need!) for improvement, for innovation. At the other extreme, imagine a world where every language used C++'s syntax.

-----

mibbit 950 days ago | link

Imagine a world where instead of writing books, authors spent forever needlessly inventing new languages to write them in.

-----

gnaritas 950 days ago | link

They already do both; have you not ever read Lord of the Rings?

-----

asynchrony 950 days ago | link

There are more differences between steel-toed boots, sandals, and stiletto heels than just how warm they are. In modern times it is also rather rare to encounter individuals wearing togas and/or powdered wigs. I'm not convinced that fashion is a complete explanation for these phenomena.

-----

nopassrecover 950 days ago | link

FYI (based on comments in this thread made by you and others), C# is nothing like Java, despite similar C-derived syntax.

-----

ricardobeat 951 days ago | link

... Flash player?

-----

equark 950 days ago | link

I have a feeling that Dart may be some version of Bracha's Newspeak. If you read his blog post on Javascript's failings, you'll see him talk about how they are already trying hard to have Newspeak fill the gap:

http://gbracha.blogspot.com/2011/03/truthiness-is-out-there....

There is also an uncanny link between the features Dart highlights -- security, optional typing, modularity -- and Newspeak. The timing of Newspeak development and Google's Dart also coincide perfectly. The blog post talks about a Javascript compiler, pluggable type system, IDE (Brightly?) all being in the works.

Newspeak's pluggable type system sounds similar to what is known about Dart. For instance,

http://bracha.org/newspeak.pdf

> We also intend to extend Newspeak with an optional type system and a framework for pluggable types , enabling the language to enjoy most benefits of static type systems without incurring their limitations.

It also seems like a smart engineering choice to base whatever Dart is heavily on some proven language, even if there is a new VM. Given that Newspeak is Bracha's most recent attempt and it's goals are so well aligned, it's hard to imagine he'd start from scratch.

-----

nickik 949 days ago | link

Newspeak has a very cool IDE (that is written in Newspeak). Maybe this "Brightly" is just that with HTML/CSS as a presentation layer. I belive he said that its written in a way that could make it possible to replace the presentation layer.

-----

jink 940 days ago | link

Maybe Dart does not require HTML/CSS.

-----

mumrah 951 days ago | link

Maybe rather than a new language, we should work towards browser "assembly" code. Lots of modern JavaScript development is in the direction of: write in language X, compile to JS. Would be nice if there was a lower-level target than JS

-----

jules 951 days ago | link

They are doing that with NativeClient. It runs x86 assembly and LLVM IL in the browser. Supposedly they'll even make it work in other browsers than Chrome.

-----

stephenhalter 951 days ago | link

NaCl does not allow direct manipulation of the DOM or provide other JavaScript APIs like canvas. NaCl provides alternative ways of getting things done like pp::Graphics2D, but it is not meant for DHTML. Dash, on the other hand, provides access to JavaScript APIs.

I think that browser "assembly" code, like Dash, would have to support this, particularly if it is meant to be an alternative to compiling to JavaScript.

-----

Detrus 950 days ago | link

Pepper is the link between NaCl and browser APIs.

-----

nxn 950 days ago | link

PNaCl seems like a separate project from NaCl to me, and NaCl itself can't run LLVM IL.

Also, there's really opposition of having it implemented in other browsers, at least Mozilla vocally opposed it. I think that if they managed to do it via a plugin though, that could work.

-----

compay 950 days ago | link

Agree 100%. The fact that Javascript is the only language you can realistically use to script the browser is a terrible limitation and legacy of bad technical decisions at Netscape more than a decade ago. I'm always surprised at the lack of concern about this.

While I do actually like Javascript a lot, I think we need to have more choices. When people point out Node as a benefit because "you can use the same language on the client and the server" I agree - but it misses the bigger problem in that, if you want to use the same language on the client and the server, you only have one real choice.

-----

peterhunt 951 days ago | link

I really wish that we would see a concerted effort to get Python in the browser (or anything reasonable, really) rather than creating yet another new dynamic language that needs half a decade to grow a decent ecosystem. JavaScript has been around for years and only in the past few years have we seen a legitimate developer ecosystem emerge around it.

-----

zmmmmm 950 days ago | link

I think that going from a language with real genuine closures to one with the half measure that Python has (lambdas) would actually be a backwards step.

Plus I agree with the other (downvoted) commenter that whitespace would be a huge annoyance. A language for the web has to be something robust to copying and pasting to / from web pages.

-----

andybak 949 days ago | link

Closures and lambda (anonymous functions) are orthogonal features. Python has closures (and one last limitation related to scope and rebinding was fixed in Python 3)

Furthermore although I agree Python's limited lambda's make it slightly uglier to do some constructs, it's merely syntactic sugar.

First-order functions are the critical feature. Whether you are compelled to give them a name or not isn't critical.

-----

ma2rten 951 days ago | link

That's because heavyweight clientside applications are only a more recent thing and JavaScript engines have improved alot.

JavaScript is great for event based programmming because of it's scoping rules. Python can't offer that.

That's why a few langang

-----

riffraff 950 days ago | link

what scoping rules make javascript better than python for evented programming? I am not a big JS writer, but I can't seem to see anything important (nested functions, globals).

Maybe you are referring to the fact that JS has an arguably better syntax for anonymous functions?

-----

sid0 950 days ago | link

Python has implicit declarations, which lead to a world of hurt because you can't directly modify variables in arbitrary scopes. Python 3 has nonlocal, but that only extends the number of function scopes you can refer to to three.

I think having implicit declarations is probably the worst mistake Python made. It just makes things so much more confusing.

-----

sid0 950 days ago | link

Sorry, I made a mistake: nonlocal gives you as much power as usual closures. I still stand by my statement that implicit declarations make things very confusing.

-----

crizCraig 950 days ago | link

In python nested functions must be declared before calling them. Also stuff like this seems to crop up on me when I ry using closures: http://stackoverflow.com/questions/2516652/scoping-problem-i...

-----

riffraff 950 days ago | link

that is what I meant as having a better syntax for anonymous functions. I agree it's bad (even with nonlocal in python 3) but that is not a matter of different scoping rules, it's only syntax.

-----

tzs 950 days ago | link

Wouldn't Python's use of whitespace to indicate nesting be annoying? JavaScript sometimes gets into pages embedded in script tags (as opposed to be being loaded from external files by script tags), and this is sometimes done by being echoed by server-side PHP or something similar.

Having to deal with getting the whitespace right while doing that could be annoying, and would also make the code much harder to read on the server side.

I think for this application, the more forgiving a language is about layout the better.

-----

fuzzythinker 951 days ago | link

coffeescript is probably the next closest thing. I think I remember firefox and/or chrome will enable it soon.

-----

jameskilton 951 days ago | link

This is from a year ago, but this is also the first time I've heard of it. Do we know the progress of this movement today? Googling for "Dash Language" and variants doesn't give me anything of note.

-----

arctangent 951 days ago | link

Google is unveiling this new language at the Goto conference next month:

http://gotocon.com/aarhus-2011/presentation/Opening%20Keynot...

-----

patrickaljord 951 days ago | link

There you go https://plus.google.com/112643613234453381402/posts/XTDu92t9...

Edit: this one says Dart, not Dash

-----

goodside 951 days ago | link

Calling it 'Dart' is rather confusing, given that there's already an existing Google product called DART: http://www.google.com/doubleclick/publishers/dart.html

-----

Dobbs 951 days ago | link

And Dash is confusing because there is already a shell/language called dash: https://secure.wikimedia.org/wikipedia/en/wiki/Debian_Almqui...

-----

malbs 950 days ago | link

So is it Dash or Dart? It was referred to as Dart earlier in the week when someon linked the conf that Lars Bak / Gilad Bracha (spelling) would be revealing all at. I'm confused now.

-----

tonfa 950 days ago | link

It is Dart.

-----

drgath 950 days ago | link

But considering Google already stole the name "Go" from another language, it's likely that they just don't care.

-----

CurtHagenlocher 951 days ago | link

There seem to be quite a few ex-Microsoft people involved.

-----

mythz 951 days ago | link

I Like the ethos behind Dash but language design is also an art, and judging by Go - Google is not very good at it.

-----

enneff 951 days ago | link

Wow, way harsh.

Those of us that actually use Go are pretty enamored with it.

-----

mythz 950 days ago | link

Let me explain, Rather than trying to make a language as aesthetically pleasing to the programmer as possible, the Go team tried to get by its limitations with design kludges and workarounds that are visually less appealing and intuitive then the many well-designed solutions that preceded it, e.g:

  - Error codes are a poor substitutions for Exceptions

  - Have to code around lack of generics, e.g. by abusing their typed map if possible 

  - Defer less desirable and intuitive than C# using

  - array bracket notation prefixing the variable

  - No proper classes?
I mean, take their example on a File type (http://golang.org/doc/go_tutorial.html):

type File struct { fd int name string }

func (file File) Read(b []byte) (ret int, err os.Error) {}

func (file File) Write(b []byte) (ret int, err os.Error) {}

file := &File{fd, "file.txt"}

The same signatures in CoffeeScript can be achieved by:

class File

  constructor: (@name) ->

  read: (cb) ->  

  write: (contents) ->
file = new File "file.txt"

Which I'm sure a majority of people would find a lot more readable.

Just for kicks I decided to rewrite Go's Cat example to StdOut in CoffeeScript for a side-by-side comparison. The examples are fairly close but not exact, i.e. cat.Go implements via streaming while CoffeeScript's is non-blocking.

https://gist.github.com/1207994

The CoffeeScript version ways in at 12 LOC, while Go's example is over 110 LOC and a lot more unfriendlier on the eye.

-----

enneff 950 days ago | link

I didn't want to get into a slinging match, but I take issue with all of your points.

"Error codes are a poor substitutions for Exceptions" This is debatable.

"Have to code around lack of generics" Some people complain about this, but in practice their absence hasn't been a big problem. It's still an open issue, though.

"Defer less desirable and intuitive than C# using" Again, debatable.

"array bracket notation prefixing the variable" http://blog.golang.org/2010/07/gos-declaration-syntax.html

"No proper classes?" This is a bizarre complaint. Go doesn't have classes. It has types and methods. Why would you need classes? What is a "proper" class?

The tone of your complaints implies that we didn't consider any of these things, or that these decisions were made through sheer incompetence. This couldn't be further from the truth. Language design is just as much about what you exclude as what you include. One of Go's major strengths is its simplicity. It's a very small language; so small, you can read the spec in one sitting! http://golang.org/doc/go_spec.html

As has been pointed out already, your comparison between Go and CoffeeScript is not illustrative of much. Go is typed, CoffeeScript is not. The "cat" comparison is very strange. Your (very unidiomatic, and in some places plain wrong) Go program re-implements everything from a syscall level, while the CoffeeScript example uses library calls. Why?

Here's how one might write a similar "cat" in Go:

    package main

    import (
        "io"
        "log"
        "os"
    )

    func cat(name string) os.Error {
        f, err := os.Open(name)
        if err != nil {
            return err
        }
        defer f.Close()
        if _, err = io.Copy(os.Stdout, f); err != nil {
            return err
        }
        return nil
    }

    func main() {
        for _, arg := range os.Args[1:] {
            if err := cat(arg); err != nil {
                log.Print(err)
            }   
        }
    }
This handles multiple files specified on the command line, and handles errors. (The CoffeeScript one just throws them, right?) Not bad for 24 lines of code.

-----

mythz 950 days ago | link

If you considered them it's even worse - by keeping the language simple you've made it more unintuitive and less readable for the programmer. IMHO the primary beneficiaries of Go are the compiler writers, not the programmers having to read and write source code.

Your example is not the same, this is just a C-style single method. The whole point of my example was using Go's own sample source code to showcase the hacks needed around structs to get around the deficiencies in not having classes. The resulting struct method signatures are ugly, verbose and unintuitive - it's not nearly as readable and wrist friendly as grouping them in a single class definition.

In following this pattern the defer keyword is a magic method that doesn't visually demonstrate its behaviour - compare that with C#'s using statement which does.

-----

enneff 950 days ago | link

If that's what you were trying to demonstrate then you were pretty far off the mark. The two programs are far from equivalent, and your Go code is just bizarre.

I think this statement of yours is quite revealing: "Your example is not the same, this is just a C-style single method." It's not a "single method," it's a function. Not everything is or should be about object orientism. It's not always the right choice, and people who obsess over making everything an object (those who think functions are a special type of method) are doomed to overcomplicate their design. (For example, there is no reason you should need to construct new objects to write cat.)

I'm confused as to why someone who clearly doesn't know Go would try so hard to discredit it. What's your motivation?

-----

mythz 950 days ago | link

The Go code is bizarre? That's the introductory Go tutorial showing off Types in Go (http://golang.org/doc/go_tutorial.html) Not a single line of the Go code is mine (I just copy and pasted the entire tutorial in a single file). If you want to blame someone for making Go look bad - blame the author of the tutorial - or better yet the inventors of the Go Language.

If you think OOP is not important for building and encapsulating large software code bases, then we operate in different worlds and Go wasn't designed for my purposes in mind. Feel free to keep using Go as a better C and I'll stick to mainstream languages without these deficiencies (aka trade offs).

-----

munificent 949 days ago | link

Just to play devil's advocate, here's what that example would look like with exceptions and something like `using()` in C# (here, any curly block can implicitly be treated like a try block, like in Ruby):

    package main

    import (
        "io"
        "log"
        "os"
    )

    func cat(name string) {
        using (f := os.Open(name)) {
            io.Copy(os.Stdout, f)
        }
    }

    func main() {
        for _, arg := range os.Args[1:] {
            cat(arg);
        } catch (err os.Error) {
            log.Print(err)
        }
    }

-----

akkartik 950 days ago | link

That's a terribly biased comparison. The go example defined stdin/stdout/stderr from scratch and much else besides, while the coffeescript version basically called a library function.

It's very hard to compare statically-typed system languages with dynamically-typed HLLs. And it's utterly misleading to judge one by the standards of the other.

-----

phoboslab 950 days ago | link

Your comparison is unfair, because CoffeeScript and Go try to do vastly different things. Go is a fairly low level systems language, while CoffeeScript is as high level as it gets.

That said, what Go achieves with its syntax is remarkable, imho.

Consider this: How do you add another function (e.g. "close()") to your file class in CoffeeScript? By extending the existing class into a "MyFile" class? But then you have to make sure all your "File" instances are actually instances of "MyFile", so you can call your newly defined function on them.

In Go you just define the new function.

-----

Ezku 950 days ago | link

Not to detract from your point of vastly different things, but you picked a bad example. You add a method to the prototype:

    File::close = ->
Et voilà, all Files are closeable.

-----

phoboslab 950 days ago | link

Nice, I didn't know that CoffeeScript has a shorthand for .prototype.

So, to revise my point: with "proper" classes (i.e. Java or C++) this wouldn't be possible, or at least more complicated and not the way to do things. Classes are not the ultimate solution and it's a good thing that Go tries a different approach to OOP.

-----

dchest 950 days ago | link

Nice logic! Shell is better than CoffeeScript or Go:

    #!/bin/sh
    cat file.txt

-----

Jach 950 days ago | link

I always liked Perl's version:

    perl -e 'while (<>) { print; }' file.txt

-----

samwyse 949 days ago | link

I like Perl's other version:

  perl -p file.txt

-----

jroseattle 950 days ago | link

As are those who use just any language/environment of their choice. So what?

-----

DanWaterworth 950 days ago | link

Speak for yourself, I really don't like Go.

-----

equark 951 days ago | link

Your best bet is to check out Strongtalk to see if the main designers have a good artistic sense. It actually has a number of similarities to how Dart/Dash is described.

http://www.strongtalk.org/index.html

Although perhaps because it's Smalltalk you can't learn much from this example.

-----

More



Lists | RSS | Bookmarklet | Guidelines | FAQ | DMCA | News News | Feature Requests | Bugs | Y Combinator | Apply | Library

Search: