Submitted by Google believes Dart speeds up both developers and the programs they write, but skeptics worry that it fragments Web programming and undermines the industry’s focus on better JavaScript. So far, it’s been a largely academic debate, but that will change in coming months.
That’s because Google right now is building Dart technology directly into Chrome.
Does anyone here use Dart?
I’m considering it for my next personal project, just for the sake of trying it out and experimenting. Probably wouldn’t bring it up at my next project planning at work though.
Good thing about Dart is that it maintains compatibility by compiling to JS on non Dart-enabled browsers, although that impacts the performance.
Courious whether it will follow the fate of GWT.
So if it can compile to Javascript it can’t do anything which Javascript can’t? If my assumption is correct, what’s the point of it, might as well just carry on writing in Javascript!
The idea is that dart code is easyer to write (there are other, more popular tools for this, for example cofeescript) and that the language is easyer to optimize for the compiler (speeding up execution).
Dart is actually *less* functional than javascript. But they only threw away parts of JS that nobody should use, and are just early mistakes that hamper JS to this day.
That said, until dart gets traction from other browsers, I won’t even try. Mozilla’s asm.js is less ambitious in a way, but I think it is a better way forward.
CoffeeScript makes JS less fugly, and TypeScript makes it more scalable for larger teams and bigger projects (through static typing). Both compile to idiomatic JS.
I don’t see a good “niche” for Dart, since both of these interact perfectly with existing JS ecosystem and provide the same “better language” benefits as Dart.
I’d rather see a JS-with-perf-extensions in the VM (e.g. structs and type annotations, integers, …), that TypeScript, CoffeeScript & friends would compile to.
That’s pretty much what asm.js is. It’s hard to call it an “extension” because it removes stuff from the language instead of adding to it, but it has the distinct advantage of being proper javascript that can run unmodified even on a browser that only knows about plain javascript (not sure what the performance profile is in this case).
As for type annotations and similar, since you can generate asm.js code from llvm bytecode, you have a large choice of languages to write your code in.
I’m thinking something sane and debuggable (asm.js doean’t even have a string type).
asm.js is also very new technology. They’re considering a string type, among other things.
All touring complete languages can do everything any other touring complete language can do so why bother using anything but Assembly?
Anyone who coded in Javascript knows that the languace grown in a way it is now a collection of patches (classes on it are a bad joke) and Dart seems to be a modern restart that avoid some bad heritage and is nice like C#.
Disclaimer: I am a C++ coder, but I do like C# syntax, I worked a lot with Javascript in commercial projects, and I know it is trash.
Personal experience is that you always lose performance writing in compiled languages, although it is usually much easier.
I assume it is run natively on Chrome with no need for Javascript at all, is it compiled in any way or interpreted directly?
Both Javascript and Dart are neither compiled or interpreted. They both use JIT (just in time compiler), that compiles the block/method/function that is being executed in memory. There are more variations of this method that browsers use actually, but this is the basic idea.
The thing is that, a non-organized language is much harder to optimize when compiling (even if using JIT), and Javascript was not designed to run games or keep executing in background during all time, while Dart is.
It isn’t quite as simple as that.
http://programmers.stackexchange.com/questions/138521/is-javascript…
“There are more variations of this method that browsers use actually, but this is the basic idea.” – you see, it was just an example,. and it is dependent on the browser it runs in. Again, I did not said it was all JIT.
JavaScript isn’t trash. I get fed up of this opinion.
The language has it quirks but is very flexible and it is mis-understood. Especially because C#/Java/C++ guys tend to try to write it like it is C#/Java or C++.
It the only language which I like programming these days.
Edited 2013-12-20 14:39 UTC
Let me clarify: it WAS a language I liked and loved. It grow up to be a ugly monster that eat little kids.
Take, for instance, its object/pseudo-class implementation, it is a nightmare if you are not the one who developed the original code – commong thing in industry, you will always ending with tons of old code someone else wrote and did not care to document. The lack of types, mostly in the object case, is also very bad for mantaining large pieces of code.
Also, it is very easy just say “people don’t use the right way” and do not face the problem: people CAN use it in the wrong way very easily.
Reguards.
I seen horrible things done in Java and C# code bases, it isn’t the language it the programmers and you can’t blame the language.
Edited 2013-12-20 14:44 UTC
I bet I’ve seen worse thing in more “evolutionary” and flexible languages like C++ and PHP
lucas_maximus,
“I seen horrible things done in Java and C# code bases, it isn’t the language it the programmers and you can’t blame the language.”
Obviously languages are subjective, but in principal there’s no reason you cannot blame the language for it’s cons just like protomank did. Ie having too many ways to do the same thing, confusing abstractions, just look at perl. Also, just because I can personally use the subset of the language that fits my personal preferences doesn’t mean I won’t have to use other code at times.
It’s outright lousy that javascript doesn’t have better namespace support. For both performance and coding standards, I prefer a language to have strict typing and static objects, yet with javascript I have no guarantees about any object. Even if I see where an object is declared, I cannot tell if an object has other properties dynamically added somewhere else using dynamic assignments and/or prototypes. I cannot prove the type of any variable without analyzing the entire JS codebase. Since nothing is statically enforced in the language, it makes it much more difficult to predict how a small snipit of code will execute without understanding the program as a whole. JS cannot effectively be “unit tested”. This is a con not shared by static languages such as Java/C/C#/etc.
What makes javascript hard to predict for us as humans also affects the javascript JIT VMs too, which is the whole motivation behind asm.js – “don’t use these features of js because we cannot convert them to static code”.
I don’t think javascript is so bad for how it’s typically used, but I do think it is bad for the high performance and complete application programming environments that it’s being pushed towards. When it comes to robustness, compilers are worth having since they can verify a great many problems that would not show up at all in a JS program until the faulty code executes. As always, the best answer it to choose the language that fits the project. Javascript often gets used because there’s no other choice when it comes to native browser support. If I had a choice, it would probably be C#/mono.
That one I will totally agree with. It has caused no end of pain over the years and is something that could have been addressed and dealt with in the beginning.
The problem is not that JavaScript doesn’t have them, in practice it does. Its just that there is no specific syntax for defining them. You can always do this:
And just go to town. The problem is there are like 500 variations of the above, no one agrees on which approach is “best”, so there is no consensus on it.
The real problem though isn’t a lack of namespaces (that really is mostly just background noise), it is the omission of any kind of concept of module loading… THAT is the worst problem in the language. There are patterns to deal with it, but again there are so many variations, and unfortunately with the modules concept the variations are almost never compatible…
Anyway, these are the kinds of things that make it bad for “structured” development – I personally don’t think that dynamic typing and prototype-based OO are it’s problems – those are arguably strengths, depending on how you look at it.
galvanash,
I agree.
Also there are other practical problems that aren’t strictly part of the language, but never the less impede development. An example I came across recently were the difference with XMLHttpRequest . All browsers except IE will start streaming data as soon as readystate>=3. IE throws an exception until readystate=4.
Opera and Chrome won’t trigger readyState change until 1024 data bytes are received, from that point forward each additional packet triggers an event regardless of length. Safari and FF trigger as soon as any data is available. Consequently streaming AJAX requests need to be padded with useless characters just to get the client javascript portion to work.
I also found browsers work differently with regards to AJAX HTTP Origin policies. Safari in particular requires additional “preflight” requests, where as other browsers can usually use the http Origin header without an HTTP OPTION request, which can require extra configuration / programming for scripts that wouldn’t normally expect an OPTION request.
I’m a bigger fan of having a well defined OOP class and I like having a compiler check for errors, but it’s just an opinion and ultimately you are right: it depends on how you look at it and what the project requirements are.
I’ve never run into these problems because I have a library do the hard work for me.
CORS with IE8 and IE9 support is a PITA, but that all you gotta worry about.
Edited 2013-12-21 12:23 UTC
lucas_maximus,
“I’ve never run into these problems because I have a library do the hard work for me.”
Well obviously I realize that. Many library users might even be oblivious to the incompatibilities that needed to be overcome by the core developers. But even so it’s not good to need browser specific workarounds in libraries, it makes them more bloated & fragile, more difficult to maintain and extend, and can compromise clean code paths for browsers which do not exhibit the problem.
For the streaming AJAX example I used earlier, I needed to modify the *server* to account for client-side limitations in some browsers.
Another example is I needed to extend TinyMCE for a client, but it exhibited too many problems in IE (even though it’s officially supported) so I had to ditch that in favor of CkEditor, which worked but I still needed browser specific workarounds. We’re still not at a point where you can just develop in one browser and assume it will work in all others. Now I’m pretty used to this as a fact of life for web development, but clients on the other hand expect things to work everywhere, I’ll get no end of calls if they have a friend with an old browser that’s not supported by one of the libraries in use.
In honesty through, my gripes don’t stem from the technology itself. It’s just that I’d rather be doing something else. Web development has never been a good fit for me, I’m only here because I am qualified and it is where most of the work is at. I find PHP/Javascript/HTML/etc rather boring and I’d much rather be working on something more meaningful to me, like complex algorithms for solving research problems and AI. My resume is full of web work that only attracts more of the same. On account of having kids, I’ve had to give up the personal projects that used to keep me interested in CS, that depresses me. Wow, this is quite the tangent, but maybe it clarifies the actual source of my frustrations.
I feel your pain, and while this kind of frustration tarnishes the reputation of JavaScript, the fact is it has nothing at all to do with the language. While there are a few minor incompatibilities between different JavaScript engines, probably 98% of the problems that people regularly run into are because of differences in each vendor’s underlying DOM implementation – something totally unrelated to the language itself.
In web programming the DOM acts more or less like the languages standard library or framework… Virtually any language you can think of with a standard library offered by multiple independent parties (C is a good example) suffers from exactly the same problem. You could come up with lots of examples of code say targeting BSD libc that simply would not work if you then tried to compile it against glibc.
Even Java, .NET, etc. have the same problems – it just doesn’t matter in practice because 99% of the developers in those languages only bother with the “official” language author provided libraries – the other implementations are either ignored or used in isolation. Mono is not 100% compatible with the .NET framework, even OpenJDK and Oracle’s Java JDK differ in some areas – and those are both fundamentally based on the exact same code…
For the streaming AJAX example I used earlier, I needed to modify the *server* to account for client-side limitations in some browsers.
And never will be. These days with my current work, due to the size of the website, I am either having to implement an elaborate hack or having to completely rewrite a module on the website and I am running up against problems where I am almost at the point where I can’t fix them anymore.
Soo many patterns …
http://addyosmani.com/resources/essentialjsdesignpatterns/book/
There isn’t that many, they differ on the toolkit you are using … but whatever form they are in it is the same basic principle.
Maybe we should get back on topic: Dart
And Dart is supposed to solve that ? Does it ?
I actually like asm.js approach better.
We all know people need system languages and scripting languages. Most of projects that use system language use both.
Examples: A lot of C-programmers use make in their projects. Many games have a the game logic written in Lua. And the game engine is more generic and handles all the performance critical parts.
You get Javascript and go with asm.js on parts of the code that really needs performance, like calculations.
You always use a compiler for system languages, so that is why asm.js is fine.
Obviously, Google has their solution for that called NaCl.
But here asm.js has the advantage again, it can run in any browser. It is a subset of Javascript which is easier to work with for the VM.
Years ago, Javascript was interpreted only and was 100s to sometimes 1000s times slower than native compiled. Now it’s 10 times as slow (actually usually between 6 and 15). With asm.js, with just a few weeks of work, they got half as slow as compiled.
They think they can do a whole lot more. asm.js is like a bytecode. So all the optimizations Java and others use can then be applied to asm.js. And that byte code can still run in any browser (but slower of course).
People used to say, if only the browser supported my preferred language. Now asm.js exists and you can do that. People have also ported other scripting languages by compiling the runtime. Like the Python runtime.
Really, I see no use for Dart and NaCl to be supported in the browsers.
And with asm.js on the table, I see no other browser supporting Dart or NaCl.
Edited 2013-12-21 08:26 UTC
Lennie,
Until Dart is natively supported by all browsers I want to target, I don’t see myself using it. Maybe my preference for native (non-emulated) languages is overblown, but I doubt I’m alone. The situation is not so different from the Eiffel programming language we learned at university (which gets compiled into C).
Something even better than Dart (or anything else) emulated in javascript, and perhaps even better than javascript itself, would be to have native support for something similar to LLVM within the browser, eliminating the intermediate javascript conversion all together. Finally we could have a great unified platform for both client and server side code.
Without benefit of human readability, you might as well use a bytecode that’s designed to be efficiently used as a bytecode. Or at least use a language with trivial grammar (such as Forth) that doesn’t have any syntactic sugar and takes very little code to parse.
Unfortunately we are where we are not because it makes great engineering sense to have languages compiling down to javascript, plus complex optimization to compile that down further to native. The reason we are here is because when it comes to browsers, javascript is the starting point which we’re largely stuck with.
Well, I think you’re probably right that’s the best we can expect. Better solutions are technically in reach, but corporate politics being what they are, javascript is going to have a unique role as the least common denominator for the foreseeable future.
Edited 2013-12-21 18:11 UTC
I think you missed one thing: When Javascript is the bytecode and runs close to native performance you can compile any language LLVM supports for the browser. Even port existing runtimes of other scripting languages if you don’t have a compiler/transpiler yet.
If there any language you prefer not on the list ?:
https://github.com/jashkenas/coffee-script/wiki/List-of-languages-th…
This works best with source maps, that minimized or compiled bytecode doesn’t have to be completely useless for debugging:
http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
Supported at least by Firefox, Opera and Chrome.
Also see this presentation:
http://kripken.github.io/mloc_emscripten_talk/#/
http://www.ustream.tv/recorded/29324270
(there is some annoying music in the start of the presentation which will go away after the first few minutes)
Edited 2013-12-22 00:23 UTC
Lennie,
I know that there isn’t anything that cannot be build on top of javascript, it is Turing complete after all. The point was that just because something can be done doesn’t mean it should be done. The motivation for javascript in this case has little to do with technical merit, only that it runs in all browsers. We’re just lucky vbscript in the browser didn’t work out (yuck yuck yuck)! Something like NaCl is more suitable on pure technical grounds, but fails on account of the fact that it’s just not available. So, realistically javascript may very well be the best we can do on account of it’s current availability. What bothers me though is that fact that its adoption as an intermediary language will only solidify it’s position against superior alternatives in the future.
I’m not sure there’s anything more we can get out of our little discussion, so I guess I’ll just end it by agreeing with you that emscripten is very cool regardless of my critic and that it will likely open up some new innovative uses of software in the browser that were previously not very practical (linux distro in a browser anyone?)
Edited 2013-12-22 05:23 UTC
Actually playing with VBScript on the web could be source of money if you want it.
VBScript is still in IE, strangely enough there are things VBScript is allowed to do which Javascript can not.
I’m almost a 100% certain there are security holes there waiting to be exploited. They aren’t being found because nobody is looking at the moment.
There is money to be made these days with 0-day exploits. So there is some potential there. 🙂
Linux distro, well, in a way that has already happened. GTK and Qt both have a HTML5-backend which use HTML5-canvas to display the application running on the server. FreeRDP has a Webconnect side-project which you can use to connect to Windows or Hyper-V virtual machine console on the server. And there is SPICE for HTML5-canvas (SPICE is a protocol for the KVM-console).
But that is cheating. 🙂
If you compile the HTML5-backend of GTK or Qt in asm.js. Then you could run lots of Linux applications out of the box.
Some have already ported an OpenRISC emulator to asm.js and is running Wayland on WebGL: http://www.phoronix.com/scan.php?page=news_item&px=MTQ4NDI
From their Wiki:
“The overall speed is equivalent to a Pentium 90. With asm.js it around 50% faster than a Pentium 90.”
Obviously, as you can see running an emulator is never the best way to go about doing these things. 😉
GTK and QT port have a Wayland backend too. And a port of Wayland for WebGL has already been done.
So you could potentially run Wayland, GTK and Qt with Wayland-backend compiled for asm.js and run it on WebGL.
asm.js is most of the time build with Emscripten and LLVM ( there is also: http://www.mandreel.com/?page_id=48 ).
And some people from Debian have been busy trying to build everything on LLVM. The last statistic I found is: 18854 packages have been rebuild. Among them, 2188 (11.6 %) failed.
So, sure a Linux distribution in the browser isn’t that far off. 🙂
But currently the closed thing to melting Linux and HTML5 together as a Linux distribution is obviously FirefoxOS.
As an experiment I bought a 150 euro Geeksphone Peak with FirefoxOS which works surprisingly well. There is no lag I’ve seen, in that regard it is better than older releases of Android on similar hardware. Any problems or missing features I’ve encountered are because FirefoxOS itself is still a bit new.
Lennie,
“Actually playing with VBScript on the web could be source of money if you want it.”
Ugh, no thanks. It belongs in the dustbin.
“There is money to be made these days with 0-day exploits. So there is some potential there. :-)”
I’ve found exploits a few times in various things. Heck anyone working with widespread packages like OSCommerce should know that it’s not even particularly difficult given the quality of that code. Still, how’s an honest individual going to profit off of them? You tell the maintainers, they fix it, you get nothing. You’d be surprised how many companies leave vulnerabilities in code because they don’t want to pay to fix problems they haven’t encountered yet. I recall an instance with a very large client of one of my former employers who’s website was open to XSS and SQL injection, yet I wasn’t permitted to fix them despite my insistence that this placed the client’s data at major risk. This really disturbed me. I cannot give more details, but the point is having a keen eye for these things has never been financially rewarding for me. I guess you might have been talking about the black market?
In response to the money blackhats are offered for bugs, the bug bounties for whitehats have increased. Here is an example for IE:
http://technet.microsoft.com/en-US/security/dn425036
I’ll add just one last comment.
Just this Sunday Mozilla says they achieved 1.5x slower than native (for certain workloads obviously):
“at around 1.5x slower than native, or better. That’s a big improvement from earlier this year, when as mentioned before things were closer to 2x slower than native.”
https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-perf…
Lennie,
It’s an impressive micro-benchmark, but I’m curious about performance in general. To me though the performance aspect isn’t my reason for disliking this solution. I’m not sure everyone else realizes exactly how asm.js is being used.
http://arstechnica.com/information-technology/2013/05/native-level-…
The idea behind it is that the intermediary javascript code is syntactically standard javascript, but it does not make use of any of javascript’s dynamic objects whatsoever. We essentially have a huge array of static type, which in conjunction with asm.js allows the array to be implemented as nothing more than a hunk of raw memory. Since we are not using javascript objects, in order to use this memory, the program needs to implement normal heap management operations like memory allocation, garbage collection, etc on top of the static array. This effectively avoids all javascript’s dynamic objects, as well as their inherent performance overhead.
At this point I’m hesitant even to call this java-script, though strictly speaking it is a subset of it. By eliminating javascript’s slow dynamic objects, it performs more like a static language. I see no reason that it couldn’t theoretically perform as well as native C other than the fact that ahead of time compilation has fewer constraints on compilation time & memory for optimization. I’d guess that instructions without a 1:1 correlation will probably result in slightly longer javascript instruction sequences. Also there’s an additional indirection caused by the javascript array compared to native code which operates in raw process space, but that’s probably not so bad if there are enough cpu registers to handle this.
The trouble is when it comes to more “advanced” features like multi-threading. Do any dialects of javascript even support multi-threading at all? We can see the “worker” model allows javascript to spawn a new thread, but the semantics of it resemble that of a “process” rather than a “thread”.
https://developer.mozilla.org/en-US/docs/Web/Guide/Performance/Using…
Even in the long term, I do not envision javascript being introduced to multi-threaded programming. If this is the case, and if our intention is eventually to support other languages fully (and not merely a subset of them), then the asm.js approach would ultimately have to emulate it, but since javascript lacks interrupts as well that’s a problem. We’ll be left with one of four choices:
1. Change the java-script language to accommodate the requirements of other languages (and face the consequences of introducing new MT race conditions into javascript if people were to actually use them).
2. Break the constraint that other languages must compile down to legal javascript.
3. Keep standard javascript, but instead of translating linear code flow directly into javascript code, generate a new code flow such that recursive function sequences can be transparently interrupted and resumed. This would imply building a new emulated function stack, and would probably work in a similar way to how QEMU can regenerate code flow. This becomes a very complex solution just to work around javascript limitations.
4. Simply accept that some language features are incompatible with javascript browser targets.
Ultimately I just don’t like contorting javascript to work this way. We could emulate a whole machine inside a single string if we wanted to, but that really doesn’t make it a good design (even if we add special optimizations to our language to make it perform well). The fact that it can be made to work does not make it the right tool for the job from a software engineering perspective. I guess it’s silly to get worked up over this, but from my perspective we are witnessing a VHS versus Betamax moment, where the less meriting technology becomes ingrained as the defacto standard.
Edited 2013-12-23 17:48 UTC
Yep, it is a huge hunk of raw memory. Just like pretty much every system programming language which is compiled with a compiler. And a worked is like a process with a message based IPC. A bit like Erlang does it.
They do have a bigger plan, one of their ideas would be to compile an existing C++ VM (like a Java VM) as asm.js, which emits Javascript JIT:
http://kripken.github.io/mloc_emscripten_talk/#/39
http://www.ustream.tv/recorded/29324270 At 28:00 or so.
I won’t say it’s a perfect world. 😉
I wouldn’t be so pessimistic. Google’s javascript compilers (Dart and Closure) play up to the fact that browsers have to stay backwards compatible, so any language that efficiently can be compiled to javascript stand a chance of success.
asm.js is wasteful, typed javascript is not good enough, closure is a crutch… Dart is not as static as I like it to be, but it is good enough to make decent IDE-support possible, both when coding and when debugging. Dart is a bit too scripty, but the alternatives are worse, much worse.
Dart provides an environment with good debug functionality, well working closures, well rounded libraries etc. There are some minor syntactical issues (if you mistype a . /.. you risk getting the wrong reference assigned), but not big enough to be a show-stopper. I can’t see it fail, unless Chrome fails, but then again… I could be wrong.
I think a lot of programming languages get unfairly picked upon. JavaScript being one of them.
I’ve recently upgraded an application that been working for years that was VB.NET / .NET 1.1 and VB supposed to be this horrible language, that always creates bad software. The reason why most VB.NET stuff is crap because a lot of novices tended to code in it in the past … the Language going forward is going to have feature parity with C#.
PHP is another one, it has crap syntax and has a ton of problems again, the community over the years have solved a lot of those problems, and with a bit of Googling you can build something decent.
lucas_maximus,
“I think a lot of programming languages get unfairly picked upon. JavaScript being one of them.”
I’m not sure what you are alluding to in this instance. Never the less, it’s true that javascript has dynamic typing & object models and consequently it shares all the cons implied by such models. It’s not javascript’s fault per say, but it’s that the dynamic model is appropriate for some tasks and not for others.
Hopefully none of that is controversial, the problem now is that more and more app development is being pushed into the browser, it’s forcing more and more developers to use the dynamic model even in instances where compile time error checking was extremely practical for development.
“PHP is another one, it has crap syntax and has a ton of problems again, the community over the years have solved a lot of those problems, and with a bit of Googling you can build something decent.”
PHP was developed by incompetent devs who made made numerous blunders year after year (many which should have been obvious to them). If any language deserves to get picked upon, it’s PHP. After many years of compatibility breaking changes, It’s admittedly getting better. Some problems, like a disregard for naming conventions in standard functions, may never get fixed. But at least they’ve got superb documentation.
* Unit Tests
* JSHint
* “Use Strict”
You should be using these anyway. Also I fed up of this Static typing argument as it magically gets rid of errors in your program, It doesn’t. You are still going to get runtime errors.
PHP is pretty good these days compared to the bad old days when I used PHP 4. Again the community has picked up where the language fails.
Need a routing solution for you application? use Flight.php, need a templating solution use mustache for PHP, need a datamapper use the PHPDataMapper project.
Edited 2013-12-23 18:27 UTC
lucas_maximus,
“You should be using these anyway. Also I fed up of this Static typing argument as it magically gets rid of errors in your program, It doesn’t. You are still going to get runtime errors.”
Then again, I think you are smart enough to know why this isn’t really a good rebuttal to static typing. Static typing gives you compile time assurances that you’d otherwise need to explicitly test for at run time, or you have to leave it to chance and rely on programmers keeping track of variable types mentally. To illustrate the issue clearly, look at this function, which should logically always print “Testing:0” (Hint: it does not).
This is surprising in more ways than one; take note of how many invocations there were for F versus how many lines of output! Even among javascript experts, I doubt very many would have confidently predicted these exact results. The missing line was a silent runtime exception in FF. Oh you might argue it’s merely a theoretical problem since no would pass in the wrong types.
Simple and obvious, right? In real code it’s much easier to miss this especially if the test cases didn’t include numeric values outside of two digits (ie Jane=10 works).
I’m sure you get the picture by now. I won’t go as far as to say these bugs were caused by dynamic typing, but there is absolutely no denying they would have been caught at compile time with static typing. Furthermore, even if the programmers are using types consistently and doing the right thing, the dynamic-typed language ends up produces a lot more overhead than a language where datatypes are settled at compile time, resulting in far more streamlined code generation. That’s just the nature of the beast, and is exactly why asm.js opted to get rid of dynamic typing for translated code.
Mind you I’m not advocating against dynamic typing, it’s just a matter of pros and cons, and I’m trying to get you to recognize that dynamic typing does indeed have cons. If someone else were claiming that static typing were always better than dynamic typing, my message to them would be the exact same: there is no single methodology that is best for everything, it depends.
Correction, I noticed the Firebug was hiding dup results, the exception was in another part of the script.
F(null); // Testing:0
F(0); // Testing:0
F(false); // Testing:false
F(”); // Testing:
F(new Array()); // Testing:
F(new Object()); // Testing:0
You could build something decent with shell script cgi but that doesn’t mean it’s good or even acceptable.
PHP has gotten better but considering where it was starting from it still means it’s awful.
I respect your opinion, so please don’t take offense.
Looking at JavaScript and calling its object models “pseudo-classes” demonstrates you have a strong bias towards class based languages. That’s fine, to each their own – but prototype based inheritance is not an after-thought or a whim, it was absolutely intentional and is really kind of the fundamental point of JavaScript (it is, after all, a scripting language).
You can model virtually any OO concept (inheritance, polymorphism, encapsulation, Superclasses, subsclasses, factories, etc.) through two simple mechanism in JavaScript – cloning and prototype manipulation, and importantly, both are purely runtime operations…
I’m not saying this approach is necessarily better or anything, but it is powerful. People think of Javascript as a rather simple high level language when it fact it is the opposite – Javascript is like assembler for OO programming. It is actually an extremely low level language, because everything is built up through a very small handful of language features.
Javascript can be molded to work in a variety of ways, it is great for meta-programming, it is great for scripting, etc. It can be great for application programming, in much the same way that Python and Ruby are, but its low level nature makes it quite a bit more quirky. It probably isn’t something you would want to classify as a “general purpose” language, but that doesn’t make it bad.
JavaScript has types, it just doesn’t have static typing…
I would argue (and have many times before) that static typing is primarily a performance optimization, not a feature. Thing is that there are two schools of thought on this, and I’m in the other one
A language that doesn’t let me put whatever I want into a variable at runtime is, imo, broken. But that is because I mainly do meta-programming – and you can’t really do meta-programming with static typing.
That said I understand the argument for it from the “don’t let me shoot myself in the foot” point of view when doing applications/system level programming.
Ah… That is it in a nutshell I think. JavaScript biggest problem is it almost too flexible. Almost everyone uses it wrong. But when it is used right it can actually be quite elegant.
Hi, thanks for your reply, and I kinda of agree with it.
Yes, I like languages with a good class semantics, but I coded a lot in plain ANSI C before, so I’m experienced with both types.
Javascript could not add a complete class, with types that can be easily tracked from a function that uses it, surely, the language was never developed with that in mind, so it had to follow the path that was created.
That doesen’t mean this is the best scenario, of course, and the debuggers in browsers help you to track types A LOT.
I don’t pretend to spit in the dish I’ve eaten before (PHP and Javascript paid com CC degree), I like to play with javascript, I think some new features like web-sockets are incredible. It is just that, Dart is better in all aspects I’ve ever looked into.
To be honest, I wish javascript was “fixed” on its weak points instead of a new language to be created, but I do not believe it is possible to do so, while keeping backwards compatibility.
I think you may have missed my point. ANSI C has no OO features. You can of course using OO techniques in any language, even C, but the language itself wasn’t designed with doing that in mind.
JavaScript was designed for OO programming, it just doesn’t use the same mechanics as class based languages. In many ways it is in fact far superior to class based languages, at least from the point of view of flexibility.
It surely could have, but it didn’t want to. Most of the things you find fault with are not mistakes, they are features…
You can model class based inheritance (even with typing) in a prototype based language quite easily – but you cannot do the inverse… Granted, it isn’t static typing (there is no compile time checking), but adding tags to objects to denote their type and their ancestry is trivial – its just that no one does this because it really doesn’t matter. As a javascript programmer, I don’t really care what “type” an object is, because the only reason to care about that is to keep you, as a programmer, from doing something to it you “aren’t supposed to do”.
Type checking doesn’t enable any functionality – it only removes it. The problem is there are entire classes of problem solving methods that when passed through the filter of type checking look like mistakes, when in fact they are not…
Most of its weak points are honestly in syntax (minor things), not the kind of things you are mentioning – the fact that it is prototype based and dynamically typed are its strong points.
I don’t personally have a problem with Dart, because Dart is a language intended for general purpose programming, specifically “structured” programming by teams. That is something that JavaScript is not so great for, and it does it in a way that doesn’t break JavaScript – because it is a different language.
Fixing the “weak” points you describe in JavaScript would be, in my opinion, totally destroying the essence of the language.
I agree. While JavaScript is not my favorite language it can be quite nice and effective but you have to change your mindset and best practices compared to C/C++ coding. I come from a full system-level C/C++ background and my first experiences with JS were horrible but after working with experienced JS coders for a while I came to love it. It needs some discipline to get things right but then again every language does.
Javascript is trash (and I write MUMPS/Cache Objectscript)
Maybe it’s just that combined with the awkwardness of html and css it’s the trifecta from hell.
You might need to seek professional help for that
I’m use both C# and C++ and I also like C# more because it seems cleaner, a little bit easier to do stuff in, and more readable. But while C++ has all the features of C# and more C# has less features.
I also like Java, for the same reasons I like C#.
What I wish is someone writing a compiler to compile C# to native language. I extensively tested C# against C++ and when it comes to do the heavy lifting, C++ is far ahead of C# with exe ngened or not.
I wouldn’t say JS is complete trash but it is rather chaotic, averybody and their granny modifying the language. I’d even use Node.JS instead of PHP. For me, PHP sucks more.
Well ngen only helps to launch software for the first time faster.
I used dart for a project (http://kri-web.googlecode.com) in its early development days (pre-1.0). While it does increase the fragmentation on the web, it doesn’t provide anything revolutionary to the table. It’s still a dynamically typed language, with just a bit more OOP and modern programming idioms.
Now I’m a happy Rust programmer, looking for the moment it gets supported by NaCL, which is a much more promising piece of tech from Google then Dart.
Until a customer request us to use it, I will ignore it.
In the case of my customers, they couldn’t care less what I code in as long as it works!
On my Fortune 500 consulting world, the customers are the ones calling the shots for what technology stacks get used.
We are a bit like hired guns, as long as the payment is ok, we use anything.
I’m a Dart user, I’ve even have Dart code in production, I feel I’m more productive with it than with JavaScript, the optional typing is very Handy, it has its problems, but for a 1.0 reléase it is very usable.
Does anyone here use Dart?
thank you for your question.
You contributed with own 5 words and a question mark.
Did this take you more than 10 seconds?
All we’re going to get with Dart is one more so-so web language, except this one will run fastest in Google’s browser (just as everyone else is finally catching up to V8). I’d rather they focus on asm.js, because that is basically a combination of the best of NaCl and Dart, and with Google’s help it could certainly lose its worst aspects far more quickly. It also asks for far less of a commitment from browser vendors to simply optimize their existing engines rather than implement two large-ish Google-blessed specifications in order to get basically the same performance gains.
As a programmer I can say JavaScript is a horrible language, giving lots of subtle and hard to track ways to introduce bugs into code. Even its name is misleading, as it is completely unrelated to Java – Netscape engineers managed to fail even in this field. When you learn how to force JavaScript to create something like “inheritance” known to other programming languages, you come to realise just how ridiculous JS is. I don’t think any other programming language used until today has its own libraries/higher level languages fixing JS broken syntax (Underscore, CoffeeScript) and websites like wtfjs.com.
I don’t believe JS can be improved, because the industry believes it is the most important to keep the backward compatibility – so I don’t think Google does something harmful to the Web trying to introduce Dart.
I embedded Dart VM in a software to test Dart as a potentential scripting language. I was believing Google who said “it’s soooo much faster than regular JavaScript.”
Wasted my time. I’d rather use Mono or some kind of Java implementation as a scripting engine.
1. Make a comitee
2. Throw away parts of JS which are trash
3. Add features if needed
4. Standardize
5. Name it JS 1x
6. Get approval from ISO/IEC
7. ???
8. Profit!
So…starting from scratch it is then.
Edited 2013-12-22 13:11 UTC
I really wonder if people would complain about Scheme as much …
If you insist on ‘lisp’ on browser, you can use Clojurescript.
I’d rather use JavaScript because I am already very good at using it.
Since I’m no fan of Scheme either…maybe, although my frustration with JS is probably tied to how frustrating it is to work with the DOM.
At least it’s not that random collection of C-library function wrappers known as PHP.
Use jQuery, problem solved.
Yeah, because “chain ALL the functions calls” is an awesome philosophy for readable and maintainable code….
That said, JQuery does make things less awful but it’s still goddamn awkward.
Nobody makes you do that. It is just there when it is useful.
Edited 2013-12-24 21:54 UTC
Yes I know but it’s such prevalent mindset, even in the official documentation, that you’d be hard pressed to find any code that doesn’t.
if it has better syntax and a better DOM then I say bring it on!!
Yes, I use Dart. It is currently the only sane development environment for web applications. Javascript just does not cut it once you reach 1000 lines.