More information on Google's new web language, Dash
markmail.org
markmail.org
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."
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.”
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.
Make the byte-code VM a first class citizen and things are completely different.
If you don't mind me asking, what part of debugging/development in haxe turned you off?
People's skepticism of Microsoft is based on what they (MS) have done in the past.
> 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.
> 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.
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?
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.
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.
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.
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?
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.
And yeah, I agree: it felt exactly like reading an internal MS memo...but ballsier.
It's like an ex-MSFT .NET party over there!
I think the "Don't be evil" factor is well represented on that sentence.
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.
Sweet talking is no evil!
"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."
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...
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?
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?
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...
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.
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.
You are aware that many people still write C++, yes?
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.
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?)
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.
No it isn't.
> You don't see people endlessly coming up with new syntax for math do you.
Actually, yes, yes you do.
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.
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.
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.
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.
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.
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.
JavaScript is great for event based programmming because of it's scoping rules. Python can't offer that.
That's why a few langang
Maybe you are referring to the fact that JS has an arguably better syntax for anonymous functions?
I think having implicit declarations is probably the worst mistake Python made. It just makes things so much more confusing.
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.
http://gotocon.com/aarhus-2011/presentation/Opening%20Keynot...
Edit: this one says Dart, not Dash
So it'll have all the inherent downsides of Javascript, because you can't cross-compile without restricting the abilities. I wonder how they feel about CoffeeScript?
At least Mozilla is trying something completely different with Rust. Maybe they could support that effort instead?
Sorry, I mean "support teams for a long time on the current generation".
Those of us that actually use Go are pretty enamored with it.
- 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?
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) ->
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.
"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)
}
}
}
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.
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?
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).
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)
}
}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.
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.
File::close = ->
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.
#!/bin/sh
cat file.txt perl -e 'while (<>) { print; }' file.txt perl -p file.txthttp://www.strongtalk.org/index.html
Although perhaps because it's Smalltalk you can't learn much from this example.
I think by choosing a not so unique name, they're ensuring that people remember to prefix these names with Google (Google Go, Google Dash etc). This should has a significant effect on Google's branding.
- runs in all browsers
- works client side and server side
- scales from large projects to small projects
- contrary to your point, supports in browser scripting (admittedly, crudely).
- highly performant (with some specific issues)
I see this as very much Google saying "We need a new Java, one that we control this time".
Also, I think an implicit item on the list would be "doesn't suck", which is the whole point of the effort, not merely a constraint on feasible solutions like the "goals" you listed. They want something that sucks less than JavaScript, not something that sucks more, such as Java.
So I don't think "the reasons not to basically boil down to NIH, politics and the encumbrances"; they boil down to Java being a shitty non-solution to their problem.
Does Dash replace Java?
For many projects that will be a viable option but it
requires significant engineering effort on Dash tooling
and an extensive set of libraries.http://gotocon.com/aarhus-2011/presentation/Opening%20Keynot...
(Assuming Dart is just Dash renamed.)
This seems more about fighting Apple Appstore than fixing Javascript issues.
"The Dash Cross Compiler should be capable of taking typed Closure code (with some restrictions) and converting to Dash. Although the migration process won’t be fully automatic, it should make moving over to a Dash codebase somewhat easier."
I agree that a JS->Dash/Dart compiler is necessary to improve take-up of the new language.
http://en.wikipedia.org/wiki/OS/360
If you trully belive that the last 50 years of PL/Compiler/VM research did do nothing, I pity you.
Luckly for you that these old PL/1 and Cobol-System will be almost imposible to replace since they are a monilitic blocks of messy code. I know of banks that teach the unimployed programming so that they can update there cobol code.
If you truly believe what you say, then you should tell IBM to stop providing PL/I certification (http://www-03.ibm.com/certify/certs/pl_index.shtml), and stop updating their PL/I compilers (http://www-01.ibm.com/software/awdtools/pli).
Apparently, the last 50 years of PL/Compiler/VM research did do something: It turned you into a sourpuss. I pity you.
"The geeks shall inherit the properties and methods of object Earth."
Why should I tell them that, I never sad its not ok to make money of people that still use this stuff! Why should IBM not do it if there are still lots of people with old code that they can make money off? All I said is that there are languages way better then PL/I.
You should tell IBM, what I said, because their compiler upgrades and certification programs are not just for people with old code. PL/I is being used for new code, mostly by companies who are not persuaded by the shininess of the latest fads. PL/S, a proprietary dialect of PL/I, was used internally, by IBM, to create much of z/OS. XPL, another dialect of PL/I, was used to create the compiler for HAL/S, the language in which the programs that controlled the Space Shuttle were written. Incidentally, I note that HAL/S supported GOTO, which is amazing, considering that mission-critical aerospace applications could use GOTO, when written in a good language, whereas Javascript and its modern, GOTO-less brethren, regardless of speed, are not, as far as I know, worthy of such important applications.
I submit that there are no languages intrinsically "better" than PL/I, or, at least, that there isn't much else, that's been created since 1970, which is better than the latest PL/I (which is likely to be IBM's Enterprise PL/I for z/OS). Pretty much anything important, that you can code, in one of today's hip languages, I can also code, in my ancient PL/I "F" compiler, on OS/360, and those things which I can't do there, I probably could, by upgrading to MVS, under S/370, again on Hercules, where I can use the PL/I "Optimizing" compiler, but even that additional capability still puts me in the 1970's.
My original, fundamental point, which is correct, and which you cannot successfully argue against, is: Since the end of the OS/360 era, there has been a definite trend towards a tremendous waste of resources in rediscovering old programming truths, with some of the worst waste being in permanently forgetting about some very cool advances which we thus have to do without, today. A great deal of expensive, expert domain knowledge has been lost in old, abandoned codebases, and usually for no more reason than merely a glimmer of hope that some new way of doing things will be "better". One small example is Multics, an amazing operating system, written mostly in EPL, yet another dialect of PL/I.