Google's JavaScript assassin: Web languages are harder than VMs
The problem with programming languages is that everybody’s got an opinion - just ask Lars Bak, the Virtual Machine guru who is building Google’s planned (by Google at least) replacement for JavaScript. Bak has spent 15 years working on object-oriented VMs (virtual machines) at Google and Sun Microsystems and notched up 50 …
This topic is closed for new posts.
Re: My Two Cents on A Browser Language
It's sad that some developers think that the best way of improving performance is to 'compile stuff directly into machine code'.
Re: My Two Cents on A Browser Language
Why is it "sad" ? JIT just adds complexity for very little to no advantage. If you really need profiler data, that could be distributed in a different file alongside source to give the compiler optimization hints.
Or the browser runtime could collect that profiling data and then do a recompilation of the source.
Plus, distributing some sort of semi-opaque Bytecode only helps to obfuscate code for commercial purposes.
Re: My Two Cents on A Browser Language
Whoops, must not feed the troll. My apologies everyone.
Re: My Two Cents on A Browser Language
Replies?
A not-so-retarded academic designed Pascal, oh not-so-clever opinionated one.
Personally, in an environment as malware-hostile as the internet, I rather like VMs and rather dislike the idea of machine code being generated and blindly trusted to execute safely. But that's just me.
That's also the reason I rather like JS - the browsers do not trust it. Java on the other hand is handed over to a real VM which is trusted, with disastrous results. Raw speed is not always the most important thing and having a clear trust demarcation between real programs and web-based scripts is not a design flaw.
Re: My Two Cents on A Browser Language
errm, we "need a VM", because bytecode has proven to be more secure than distributing source ??
Java ans JS just proved the opposite. And, engineers at Borland made lightning-fast Pascal Compilers. The idea came from an academic, though.
The truth is that the JVM (and probably also the current JS ebńgines) are extremely complex pieces of code. And they are laaarge. That creates a huge attack surface. Too big for Oracle to secure.
I bet you could create a very secure and fast compiler for a memory-safe Pascal variant in less than 30K lines of C++ code. As opposed to millions of loc for the JVM and JS engines. The generated code would be highly efficient without much optimization.
Re: My Two Cents on A Browser Language (Delphi/TP)
What you describe is exactly JIT w/o recompilation (i.e. deoptimization/optimization cycles). FYI, GC is optional to JIT. GC however is a true blessing for any multithreaded code where detecting liveness is pain in the butt.
Actually GC is a true blessing anytime.
Read-barrier GC may make sense for fluid user experience (i.e. no freezes due to STW [stop the world] GC) but it's a hit in the benchmarks since each load has to be verified.
Sophisticated techniques like Escape analysis (escape detection) to reduce the amount of object created would most likely not worth but w/ enough core it might be useful via tiered compilation.
Good luck to Dart - strongly typed languages are much easier to reason in terms in corrects and static analysis.
lightning-fast Pascal Compilers
Weren't they 'lightning fast' because you had to write your code so that it wouldn't require two passes of the compiler?
Re: My Two Cents on A Browser Language
"[H]aving a clear trust demarcation between real programs and web-based scripts is not a design flaw."
Words to live by, except that I would expand that statement slightly to say having a clear trust demarcation between the _hosting system_ and the _application_ is not a design flaw.
To thee I raise a pint!
"Just because Dart is Google's baby, that doesn't mean Dart is a shoo-in."
Quite the opposite I'd have thought.
It stands a chance of adoption because it's OO, fast, scalable etc DESPITE having anything to do with the data-snaffling privacy bashers.
Re: "Just because Dart is Google's baby, that doesn't mean Dart is a shoo-in."
As the commercial arm of NSA, Google certainly hires only the best and brightest software engineers.
Here's an alternative to Google and Bing: YACY. Run the crawler on you own PC.
Re: "Just because Dart is Google's baby, that doesn't mean Dart is a shoo-in."
Strong typing and proper classes are actually a feature of any sane programming language. JS does not provide this. You never know what to really expect inside an object. You will have a hard time to make any assumptions on the correctnes of your code based on this lack of invariants.
So, almost anything that is conventional and reasonable will be better than JS.
The funny thing is that everybody thinks it will have to adhere to the Java-esque ideas of "needs VM", "everything will be a heap object", "we don't need synchronous destructors" and so on. I call this Intellectual Shallowness.
"the VM doesn’t have to take time running floating point connections to run new objects"
Huh? I'm not that familiar with language internals let alone Javascript but... floating point connections to objects?
Don't you mean (integer) pointers to new objects?
I'd appreciate clarifications...
"50 patents"
1) Go to: USPTO search
2) Query: in/Bak-Lars (where did they get that syntax?)
3) ???
"Method and apparatus for reducing memory usage by encoding two values in a single field"
"Mixed execution stack and exception handling"
"Method and apparatus for performing byte-code optimization during pauses"
"Method and apparatus for concurrent thread synchronization"
"Method and apparatus for implementing fast subclass and subtype checks"
etc...
Sigghhhh~
Re: "50 patents"
Shertainly Google Would Never, Ever Do Evil, if anybody used their contraption and violated their patents.
What's the point
Who (but Google) is going to support this?
Does anyone fancy writing code for Chrome only, or are we expected to write systems twice (once in js, once in Dart)?
We're just getting rid of the last bone-headed round of browser lock-in (IE6 I'm looking at you).
Let's not start that again.
Still at least its better than Google's Salt idiocy (and how is Google Go doing?)
Re: What's the point
The point is that JS is a real dog of a language. You know, as in "German Dackel", not as in "German Sheperd Dog".
http://www.vondersingoldau.de/images/dsc01245480_480.jpg
Re: What's the point
"The point is that JS is a real dog of a language. "
So is Dart at this point. Just try it. Or if you don't have time for that, just Google "dart non nullable objects" and enjoy the cursing on Google Groups.
Hold me back.
I believe I speak for the majority of professional programmers on the planet when I say, with sarcasm, "oh goody, another programming language."
The trouble with programming languages
is that if you cant be arsed to learn the ones available you've got properly you can always write another one.
The real trick is to get involved in ECMA or ISO to make sure that someone else's language doesn't achieve nirvana before yours gets ignored.
We are continually reinventing the wheel using shit graphics programs running on the spare CPU cycles on our matter transporter while people argue over what colour wheels the matter transporter should have.
Re: The trouble with programming languages
I would put some credence in this, except that google and THIS MAN have done the most to advance ECMA of anyone in the last decade.
Catch 22
The thing with Google is that they have a bit of a lot of 'previous', when it comes to announcing "The Next Big Thing" only to abandon it again, a few months or years down the line. Not such a problem when "The Next Big Thing" is something fairly trivial like Wave, but when "The Next Big Thing" is something as fundamental as a replacement for JS, I'd be pretty surprised if there's much of a stampede of folks willing to invest the man-hours in learning it, before it's gained traction.
And it won't gain traction without a stampede of folks willing to invest the man-hours in learning it.
Re: Catch 22
>The thing with Google is that they have a bit of a lot of 'previous', when it comes to announcing "The Next Big Thing" only to abandon it again, a few months or years down the line.
You could interchange Microsoft with Google in this statement (see Silverlight, WPF, and soon to be TIFKAM)
Re: Catch 22
With JavaScript I reckon there are two concepts the programmer has to understand:
- The various Document Object Models.
- JavaScript syntax.
Plus the fact you can insert JavaScript (seemingly) anywhere on a web page.
I would like a bunch of getters and setters for DOM elements and Dart offers this.
Re: Catch 22
With JavaScript I reckon there are two concepts the programmer has to understand:
- The various Document Object Models.
- JavaScript syntax.
And a few other things, one might hope, such as the HTML and CSS standards, Javascript[1] semantics, good UI/UX/UIM practices, etc.
I would like a bunch of getters and setters for DOM elements and Dart offers this.
As do a zillion ECMAScript frameworks and libraries. True, the vast majority of them are horrible code written by people who can't be bothered to understand the language (hello, JQuery), but there are a few decent ones, and it's hardly difficult to write your own, if you have actually learned the subjects listed above.
And why is it useful to free developers from having to learn about the DOM? Do we really need more software written by people who don't understand what they're doing?
[1] Actually ECMAScript, which is the name of the language. "Javascript" is the proprietary, non-standard ancestor of ECMAScript, or the name of one ECMAScript implementation. The camel-case "JavaScript" is a typographic error or barbarism.
"... who can't be bothered to understand the language (hello, JQuery)"
I'm only just learning Java[Ss]cript and was looking forward to learning JQuery which I thought everyone loved. What's wrong with it?
Twice as fast?
Speed obviously isn't the selling point for this: twice as fast means about one generation of mobile phones and that in a small part of user experience. Offloading stuff to hardware via, say WebGL or CSS, brings a lot more. It's far from perfect but the slow and steady development and adoption of HTML 5 (including CSS and JS) is gradually moving things along.
Re: Twice as fast?
And, of course, if you speed up the execution environment, application developers will just add more bloat to compensate. There's an optimal area in the UI-crap-vs-user-impatience curve, and most apps will follow that gradient.
Dart -- Great in theory, but doomed to fail?
After keeping up with Dart progress for the better part of it's lifespan, I can see why hard core developers would like the concepts it bringing to the table for web developement. However, aside from the performance gains, most of what dart would deliver can already be done with existing stuff. For example, for structured development GWT/GXT presents a much better option since all the knowledge, tools, middleware etc ... are already entrenched.For more basic needs, there are enough JS frameworks and planned language additions to fit most people needs.
So the question remains, is there enough developers from those 2 camps who will by into Dart?
Re: Dart -- Great in theory, but doomed to fail?
I'm a Java and Android developer but I want to get into HTML 5 development because Mozilla OS for mobiles sounds really interesting. However JavaScript is chaotic compared to Java.
With Dart, the idea of writing a single program in an object-oriented language that is referenced by a web page, just sounds really appealing.
And the learning curve, with regards to the syntax seems straight forward.
I reckon there are a lot of Java and C++ programmers out there who feel the same.
P.S.
There's the likelihood that Dart will be supported by Android and suddenly 75%+ mobile devices around the world are compatible with it.
Meh
Dart's problem is that there really is no advantage to using it over Javascript and it's not supported by ANY current browsers. Google can't just force everyone else to support a new programming system, this should have all gone through a standards body. That way we could be seeing support in all major browsers.
As is, I'm not going to use it in any production projects. It's just a toy at this point unless it gets picked up by other browser vendors.
P.S. Python whitespace is it's biggest issue, but not it's only. I've seen it used for everything from web apps to full graphical client apps and I think it's biggest issue is that people use it for things it was never designed for. If you're doing a web app, a system designed for web apps is the way to go and for complex client apps python's performance is just too poor.
Untie the Gordian Knot
One of the things that make Javascript weird, especially for newbies, is that the DOM manipulation (getting and tweaking HTML and CSS information) and browser events appear inexorably tied in with the language semantics - they really aren't, but the only real gateway to the DOM is via Javascript (unless you are writing browser-specific add-on's).
To be a bit Pollyannaish, maybe the browser manufacturers could agree upon an interface implementation that just was about DOM access, manipulation and event notification; and leave the language semantics and constructs at the "plug-in" level, triggered by script tagging. If you want to implement PERL or PASCAL for the browser, go for it. Grammar, punctuation, white space handling, collections, variable naming, whatever, the browser should not worry about it.
When the browser comes across a type attribute in a script tag it hasn't encountered before, the browser can prompt the user to download or find an appropriate plug-in. Embedded scripts would have to play nice with HTML syntax and grammar, but external scripts can use whatever markup they want.
Security? Well, scripting languages can't do anything with the underlying system that the browser doesn't allow (i.e. no unlimited file system or device access), same as today. Browser manufacturers would have to do some work to make sure that the sandbox scripting engines would play in would be sufficiently isolated from the file system, heap, etc.) . This approach may be somewhat in line with the "browser is the OS" meme that Google pushes, but in any sophisticated website, the browser really is acting like a very limited OS. I don't have a problem with that as long as the limits are well defined, understood and complied with (no nasty ActiveX-like shenanigans please).
Mine's the one looking for his "Python for Web Pages" O'Reilly book...
Forget the desktop, Android is the major influence.
Google have the power to make Dart an important web technology just by implementing it in Android.
The desktop computer is circling the drain. HTML 5 apps on mobile devices will become more important, especially with the release of Mozilla OS.
If Android integrates a Dart VM then I reckon Mozilla will have to offer it on their mobile OS.
Re: ...eyeroll...
Side effects are why we write code. If not for them, execution of a program would have no observable effect in the outside world. On the other hand, side effects don't tell you all there to know is about the internal state of an object. So debugging (or optimizing) based upon side effects alone is incomplete.
Obligatory XKCD
http://xkcd.com/927/
Was intended more for standards, but applies perfectly to languages.
The world does not need another Javascript.
So... it compiles to some VM byte code???
Ignoring the fact that a "byte code" is barely platform independent because not every platform has 8 bit bytes,... wouldn't that mean that you don't get the source code?
Dart
From the Dart documentation:
Here’s another example of code that behaves differently in JavaScript and Dart:
if (1) {
print('JavaScript prints this line because it thinks 1 is true.');
} else {
print('Dart in production mode prints this line.');
// However, in checked mode, if (1) throws an exception
// because 1 is not boolean.
}
Dart has got to be the only language going that thinks that 1 is not true. Every single time someone invents a new language, they always manage to fuck it up by doing something different and unexpected, resulting in years of errors and frustration by developers. The choice is arbitrary - make it do it the same way as everything else and people will understand it. Do it differently for no reason, and nobody will buy into your spangly new language.
This topic is closed for new posts.
