Slashdot Mirror
Gnome Goes JavaScript
mikejuk writes "Much to most programmers' shock and dismay Gnome has made JavaScript its main language for apps. It will still support other languages and it still supports C for libraries, but for apps it is JavaScript that rules. JavaScript seems to be a good choice for Gnome 3, as the shell UI is written in the language. It is also consistent with the use of JavaScript in WinRT, Chrome Apps, and FirefoxOS apps, and generally the rise of web apps. As you might expect, the initial reactions are of horror at the idea that JavaScript has been selected rather than the favorite language of the commenter. There is a great deal of ignorance about (and prejudice against) JavaScript, which is often regarded as an incomplete toy language rather than the elegant and sparse language that it actually is."
Javascript is fine, it just give you enough rope to hang yourself. (and a little extra, as it turns out) The language itself has some patterns that allow for terrible patterns, and ambiguity, but all in all, I don't think it's bad. Waiting for someone to disagree...
loosely typed language without declaration requirements for methods/variables makes it such a huge pain in the ass to debug/understand/update source that I want to have nothing to do with it.
-SaNo
Javascript is fine, once you divorce it from all of the browser peculiarities, but it's an untyped language and untyped languages suck for refactoring. They should never be used for complex apps requiring maintainability. And yes, that goes for python too.
Yeah, I know they said "apps," but even most apps quickly grow beyond the comfort zone of a script.
XFCE is the new Gnome. I hate both KDE and GNOME. Luckily there is XFCE (and LXDE).
Don't fight for your country, if your country does not fight for you.
Gnome has always been on the wrong track from day 1. It was a political response to KDE's use of Qt (which was QPL back then) and always a mishmash of libraries and utility applications rather than a fundamentally solid desktop environment. That it might have been usable at some point is more luck than anything.
I don't use KDE (or GNOME, I prefer RiscOS On X because it's insanely fast and powerful), but at least KDE has had a solid vision from the get-go, if sometimes flawed.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
I'm one of the first C programmers and I've switched to js and node.js. it's better and faster than C.
Then you're doing it wrong. And if you had half as much experience as you claim to have in this and your other post, you would understand that.
Just because you've written some C, doesn't mean you know what you're doing. I've worked with plenty of 'programmers' who have been 'doing it all their life' or better yet, 'longer than you've been alive' (refering to me) and those statements universally come from people who suck and are too stupid to realize it.
You go on to further my point about you not really knowing what you're talking about when in other posts you talk about the x86 emulator written JavaScript as if thats supposed to be something to show how awesome it is. When you make that awesome emulator there out run my copy of QEMU without kmod, then perhaps I'll give you a listen, but you've got to be absolutely retarded to actually think JavaScript as a language has a technical reason for it to be faster than compiled C in reality, you being unable to write quality C withstanding.
Yes, decent Javascript can out run really really shitty C, but only if you stack the deck so that C doesn't have a chance first. Just because you've seen a porn, doesn't mean you know how to be a parent.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Hmmm... javascript is pretty much the exact opposite of lock in. It is the closest a language has really come to being "write once run anywhere". Even most node.js stuff runs in the browser and vis versa with ease.
Well, the first metric I saw when when a web server written in node was faster than Apache.
I know there's a lot of variables there, but still, when an interpreted language beats C for something like this, that's impressive.
TO be sure, you can do the kind of I/O js does in C, but it's a real pain and usually platform dependant in some way, even the difference between linux and bsd can start the ifdefs popping up, but js brings asynchronous I/O to the 10 GOTO 10 crowd. That, and the fact the js x86 emulator not only works but runs linux under which you can edit, compile a real program no slower than unix used to be on an 11/45 and you're doing this in a browser tab.
That's the metric I use for me to consider it fast. Obviously this is a contentious and complex topic, but as a rough approximation, I think it's fast.
Or at least it CAN be. The loops FB makes it jump through are insane and they manage to kill any js interpreter they throw at it and even the mighty V8 is now starting to strain so something will have to change there. But if they knew what they were doing it'd be as slick as it was performance wise 3 years ago, this isn't the fault of js, just bad (or no) performance profiling and tuning in Palo Alto.
So, while this may not mean any code you write will be fast, if you're used to real-time programming you'll love the language and the stuff you can do now with css3/html5 (gradients, css-masks) may not have the underpinnings of the next Pixar like NeXt did, there's still enough there to, say, keep the molbio crowd happy for the next decade with very fast real time renderings of molecules they can play with to cite one example.
I agree the success of is tied to the web, but so what, that's like saying the success of C was only because of Unix.
Need Mercedes parts ?