Building Linux Applications With JavaScript

crankymonkey writes "The GNOME desktop environment could soon gain support for building and extending applications with JavaScript thanks to an experimental new project called Seed. Ars Technica has written a detailed tutorial about Seed with several code examples. The article demonstrates how to make a GTK+ application for Linux with JavaScript and explains how Seed could influence the future of GNOME development. In some ways, it's an evolution of the strategy that was pioneered long ago by GNU with embedded Scheme. Ars Technica concludes: 'The availability of a desktop-wide embeddable scripting language for application extension and plugin writing will enable users to add lots of rich new functionality to the environment. As this technology matures and it becomes more tightly integrated with other language frameworks such as Vala, it could change the way that GNOME programmers approach application development. JavaScript could be used as high-level glue for user interface manipulation and rapid prototyping while Vala or C are used for performance-sensitive tasks.'"

Comments

Takes the idea of "open source" to a new level

[Yvan256]

Since javascript is interpreted code and you need the source to actually run it.

Re:Takes the idea of "open source" to a new level

[gravos]

Javascript is just one more language, but it's a VERY popular language and a hell of a lot more people know it and use it then C# or GNU-C or anything else. Gnome is about providing a programming environment for normal people to use and if Javascript allows that then they will use it. However...

Gnome's base libraries are C and probably are always going to be programmed in C. This is because C is very universal.. it's relatively easy to port to other platforms and it's able to be included in most other langauges as modules.

Re:Takes the idea of "open source" to a new level

[ianezz]

Since javascript is interpreted code and you need the source to actually run it.

Well, the same is true also for Perl, PHP, Python and even Lua, so that's nothing radically new.

Re:Takes the idea of "open source" to a new level

[arth1]

Gnome's base libraries are C and probably are always going to be programmed in C. This is because C is very universal.. it's relatively easy to port to other platforms and it's able to be included in most other langauges as modules.

Don't forget that C produces smaller and faster binaries than pretty much any other language except very good assembly. For code that's called hundred if not thousands of times per second, and where latency is a factor, you want small and fast. Good C delivers that.

C's biggest advantage is that you tend to work directly on the data, not a copy of it.
C's biggest weakness is that you tend to work directly on the data, not a copy of it.

Re:Takes the idea of "open source" to a new level

[Rei]

C++ and javascript aren't mutually exclusive. In fact, I'm checking slashdot right now during a break from debugging a home project that makes use of both of them. I'm quite fond of the mixture of a C++ backend with a javascript frontend that can be used over the web. In this particular case, it's an electric vehicle simulator that lets you specify your vehicle details and plot a route over Google Maps. The frontend uses form POST requests to call the simulator to run the CPU-intensive simulation on the backend (where it has access to many gigs of heightmap data). The backend talks to the frontend by returning javascript function calls with the results asynchronously.

I've done several projects of this nature before. One weakness is that if the backend takes longer than two minutes, the connection gets dropped. Not a problem on this project, but on a web-based Povray interface I did in the past (lets you customize car paint jobs, then renders the car in a variety of scenes), it was. The solution is simply to have the frontend take responsibility for periodically fetching the results from the backend.

All in all, I find it a very nice balance between the cross-platform web-accessible functionality of an HTML/Javascript frontend and the extreme speed of a C++ blackend.

Re:Takes the idea of "open source" to a new level

[FishWithAHammer]

There's nothing stopping you from writing a JavaScript compiler. Hell, there's an ECMAScript 4.0 JavaScript implementation for .NET.

Re:Takes the idea of "open source" to a new level

[FishWithAHammer]

Gnome is about providing a programming environment for normal people to use

Then why the fuck is its primary windowing library (and a lot of other stuff) written in something as absolutely cretinous as object-oriented C? You get the compatibility arguments, sure, until you start running into breaking ABI because you've run out of reserved values in the core structs (like they're facing now, hence the talk about GTK 3) and other problems related to old, problematic languages. C might be easy to port (and yes, it is), but holy shit, does it make transitions shit--and very much not "for normal people". (Or businesses, but hey, fuck them, they dare write proprietary code, etc.)

GNOME isn't about a programming environment or any sort of environment for normal people. I'm not sure what it's about, but that ain't it.

Re:Takes the idea of "open source" to a new level

[erikdalen]

Well, Javascript isn't exactly radically new either (appeared in 1995 according to wikipedia). But sure some of those examples you gave have even been around a bit longer than that.

Re:Takes the idea of "open source" to a new level

[Anonymous Coward]

Oh God...If Slashdot is any indication of Javascript gone to shit, why would anyone want to write an application in Javascript. These days any sort of decent Javascripted website is generated through a 3rd party compiler and not really suitable for hand editing. I mean really just look at the source code for some of these AJAX-type websites. It's a terrible mess and I really wouldn't want to see it run on the desktop. I think if somebody wants to run a scripting language as an interpreted language, python is a very suitable alternative.

Re:Takes the idea of "open source" to a new level

[caseih]

Umm, because it's precisely the *right* language for the job. C++ restricts your binding options to other languages pretty dramatically, especially if you use parts of C++'s object model such as multiple inheritance. In short, no C++ is the wrong too for the job, Qt's use of it notwithstanding. Although it's true that Qt does have bindings for many languages, the simple fact is that these bindings, such as PyQT, are against the *C* wrapper on the C++ api. So an entire extra layer in the way. Gnome and GTK's gobject-based object model is just about one-to-one with most models of object-oriented languages. Hence you can use just about any language under the sun to develop Gnome apps. All without losing any features of the API.

If you do want to program in C with GTK, you can and it's very easy, actually. Memory leaks are minimized because of the coolness in glib. However, if you're not a C programmer then you shouldn't be programming GTK/Gnome apps in C at all. Use something more powerful like Python. In fact I can't think of any reason (except embedding on small systems, or core libraries and programs) where it's appropriate to write a Gnome app in C. There are tons of awesome bindings available. Use them. Write in C++ (which is a much nicer API at times than Qt's moc-ified native apis) if you want.

So yes. Gnome is able to target the languages that normal developers want to use. Whether that's C#/.Net, Python, C++, Ruby, or C.

If Gnome wasn't written in C, what language would you suggest? How would you provide extensive, 100% coverage of the API in any arbitrary language? Writing GTK itself in C# seems pretty silly. Same for Python, Ruby, etc, unless you want to restrict the entire toolkit to just one language.

Re:Takes the idea of "open source" to a new level

[maxume]

Actually, you can compile python into an intermediate bytecode, and then distribute that (I imagine this is similar for the other languages you mention). It is relatively trivial to decompile/reverse engineer (the tools come with python), but you don't absolutely have to have the source.

Re:Takes the idea of "open source" to a new level

[Pseudonym]

I'm quite fond of the mixture of a C++ backend with a javascript frontend that can be used over the web.

C++ has the advantage that, unlike C, there's less of an impedance mismatch between it and Javascript. Javascript is optimised for manipulating DOM-type structures which have a very natural expression in C++ and, with a small amount of template-assisted boilerplate, is fairly straightforward to bridge.

Re:Takes the idea of "open source" to a new level

[Randle_Revar]

Perl goes back to the 80s, I think. Python... early 90s maybe? PHP is probably about the same age as JS. Lua seems very new but I feel like I heard it is much older than you would think.

Re:Takes the idea of "open source" to a new level

[garphik]

So, open sourcing becomes mandatory.

Re:Takes the idea of "open source" to a new level

[AKAImBatman]

Javascript is just one more language, but it's a VERY popular language and a hell of a lot more people know it and use it then C# or GNU-C or anything else.

While the language is VERY popular, I disagree that a "hell of a lot more people know it" than most other GNU languages. The vast majority of coders have no idea how to correctly write Javascript. In fact, you can't even say that Javascript is an Object Oriented, LISP-like functional language on Slashdot (of all places) without ten or twelve people trying to tell you you're wrong.

Which sucks. Because Javascript is an AWESOME language. Plus the modern VMs (as opposed to the last-generation interpreters) are getting quite fast. Fast enough to use JS for anything short of compute-intensive applications. Even professional video games could use it as a scripting language with the right underlying APIs. (See my sig for how far it's come with Web games.)

My hope is that as Javascript shows up in more places, developers will take the time to sit down and truly understand the language. And maybe we can even get a few books on the market that don't suck. ;-)

Re:Takes the idea of "open source" to a new level

[Anonymous Coward]

Oh God...If Slashdot is any indication of HTML/Perl/JS gone to shit, why would anyone want to write an application in HTML/Perl/JS.

Fixed that for you. Slashdot is more a reflection on the skills of its developers (or lack thereof) than any reflection on the technologies used.

These days any sort of decent Javascripted website is generated through a 3rd party compiler and not really suitable for hand editing.

*cough*wholelottabullshit*cough*

I mean really just look at the source code for some of these AJAX-type websites.

The vast majority of what you see is minified code. It's like an obfuscater for the web. While some might argue they do this for code protection (worst reason ever) the real reason is to keep the code download as small as possible. Stuff like GWT is very rare.

It's a terrible mess and I really wouldn't want to see it run on the desktop.

Deal with it. Especially if you run Firefox or any other Mozilla product. Then you currently run a whole suite of Javascript applications on your desktop.

I think if somebody wants to run a scripting language as an interpreted language, python is a very suitable alternative.

I think if someone wants to write GUI code, Java is a very suitable alternative. (Hey, one good troll deserves another!)

Re:Takes the idea of "open source" to a new level

[Anonymous Coward]

Umm, because it's precisely the *right* language for the job. C++ restricts your binding options to other languages pretty dramatically, especially if you use parts of C++'s object model such as multiple inheritance.

Have you heard of Swig you Bulgarian sodomite?

Re:Takes the idea of "open source" to a new level

[caseih]

Sure. But even swig would have a hard time with some C++ things going to, say python. In many cases it's not an automatic task. Hand coding (wrapping in straight C!) is still required in some circumstances. Currently GTK has managed to get it so that most bindings can be generated automatically with little wrapping required at all. This would not be possible with C++. Besides that fact, C++ libraries are a nightmare across compilers. With straight C, you can jump compiler and glibc revisions without many problems or recompiles. Bump the libstdc++ version and you're recompiling everything. No really. C++ is not a good language for base libraries.

Re:Takes the idea of "open source" to a new level

[The End Of Days]

In fact, you can't even say that Javascript is an Object Oriented, LISP-like functional language on Slashdot (of all places) without ten or twelve people trying to tell you you're wrong.

That's because Slashdot is full of bigots who believe their own opinion is the one true way. With that mindset, they see no point in learning, and I see no point in giving their opinion any weight.

I'd really like a more complex, personalized moderation system where I could mark off people I've discovered as being closed to new ideas so I could know right away to give their posts less weight. Unfortunately using the current moderation system for that purpose is something of an abuse.

Re:Takes the idea of "open source" to a new level

[tepples]

Writing GTK itself in C# seems pretty silly.

But how else would you write a UI toolkit to be used on a .NET Compact Framework that uses digital signatures to block you from P/Invoking your own C or C++ code?

Re:Takes the idea of "open source" to a new level

[Toonol]

I've been programming a lot in Actionscript 3.0 (the backend scripting language for the newest version of flash). This is basically a refined version of javascript, and I have to say it is the most pleasing language to program in I've touched in quite a while.

I think that breaking projects into two levels is often the way to go. Write the crucial, high-speed, massive-volume bits in C or C++, test them thoroughly, and then write the rest of the app (in which performance doesn't matter and reliability and ease of programming is key) in a high-level scripting language.

Re:Takes the idea of "open source" to a new level

[arth1]

[...]and the extreme speed of a C++ blackend.

Your whole post writes as if the parent to it talked about C++ -- it didn't mention it with a word.
C != C++

As for "extreme speed", C++ will almost always be at least slightly slower than C, if nothing else because of data being copied whenever there's an inheritance or overloading, and because the linked library routines are larger.

There's also a pervasive myth that you can feed a C program to a C++ compiler and get C++ code that's as fast as C. In practice, the C++ compiler will have to use more memory for global function call constructors, and links with much larger libraries and linker code, making the C++ program use more memory and stack, and get fewer cache hits. I.e., the resulting code will be slightly slower, even when the source is identical.
Which is why you don't feed your C code to g++, but to gcc. :-)

Again C != C++. The main advantage of C++ isn't "extreme speed", but good speed combined with the convenience of coding and linking.

(I won't even mention Objective C, which is an abomination unto Nuggan)

Re:Takes the idea of "open source" to a new level

[Anonymous Coward]

I think the parent's problem with GTK is that it tries too hard to be OO instead of just doing the damn job. C doesn't support OO elegantly, why force it to? Apply the concepts of OO (encapsulation, polymorphism) and have it just work under the hood.

Then again, "just work" is practically the antithesis of open source sometimes. I feel the focus is more on the "look what we can do" at times.

Re:Takes the idea of "open source" to a new level

[Larryish]

PHP FTW!!!

bitches

Re:Takes the idea of "open source" to a new level

[Rei]

There's a pervasive myth that C++ is just objects on top of C. Or that because you can use objects, that means that you *have* to use them everywhere.

C++ is useful for tons of things. Someone who doesn't know how to use templates will create a nightmare's worth of code in a situation that calls for them. People who don't use object data structures in areas that aren't performance critical (and oftentimes even where they are, since there are a lot of optimizations in the std libraries that a lot of people miss out on when reinventing the wheel) often create a memory management nightmare and leaky code. People who don't use const correctness slow down their code and are at more risk for bugs. And on and on down the line.

You misunderstand the concept of cache hits. Whether you get a cache hit or miss isn't dependent on how much memory your *program* loads up; it's based on what's being executed at a given point in time. If you have a core loop iterating through some data structure, if you're not calling any big libraries, then they're not affecting cache hits for your core loop; the cache is going to be dominated by that data structure. Quite the opposite, C++ actually often has a *greater* chance of cache hits because data stays local to an object, and when a block of data is read from memory to the cache, you're more likely to get variables that you need cached.

Again C != C++.

C is a subset of C++. If C can do it, so can C++. Anyways, why did this become a C vs. C++ thread?

Re:Takes the idea of "open source" to a new level

[FishWithAHammer]

Ding ding ding. I came back to post precisely this, but you said it well enough.

The GTK system is just obnoxiously built and more of a hindrance than a help. (Personally, I don't think that being able to use the libraries in "any language" is a good thing; I think that a concerted effort to get the desktop away from native code is the right move. But I digress.)

Re:Takes the idea of "open source" to a new level

[tyrione]

Know it? Really? Try, `` a hell of a lot more people have tried it'' on for size, if Truth is what you're projecting.

Re:Takes the idea of "open source" to a new level

[Anonymous Coward]

I'd really like a more complex, personalized moderation system where I could mark off people I've discovered as being closed to new ideas so I could know right away to give their posts less weight.

It exists today. Just add them to your foes list and then assign a negative modifier to foes.

Re:Takes the idea of "open source" to a new level

[John Betonschaar]

(I won't even mention Objective C, which is an abomination unto Nuggan)

And why exactly if I may ask? I'm not an objective-C expert but to my knowledge it's exactly what most people think C++ is: C with support for objects, period. For many tasks it's actually a really nice language that combines some of the main advantages of C++ (objects, inheritance, etc) with the advantages of C (small and clean syntax, fast compilation, fast execution).

So if you don't need full-fledged C++ or know you aren't proficient enough using its powerful features properly (like so many developers that think they do, C++ is still pretty difficult to really master), Objective-C is the perfect middle ground.

Re:Takes the idea of "open source" to a new level

[John Betonschaar]

Have you heard of Swig [swig.org] you Bulgarian sodomite?

Have you ever *used* it?? As much as I like and use SWIG (even for my daily development), wrapping something huge as the complete Gnome libraries with SWIG is not going to be fun, especially not if you want bindings for any possible language (and not to forget: every interpreter version). You'll end up with of 100MB+ sourcefiles to compile *for each script language*, that compile to multiple huge shared objects *for each script language*, and these libraries will not be portable between different interpreter versions. And let's not forget that even SWIG cannot wrap all C++ constructs, and you will have to write tons of typemaps for all the C++ classes and structures that you want to use natively in your scripting language. Which means you need to be an expert in the intricate details of all the scripting languages you want to support.

All in all, SWIG is great and you can absolutely use it to create scripting bindings for Gnome, but calling it a substitute for the portable C-style bindings Gnome now has is just nonsense.

Re:Takes the idea of "open source" to a new level

[MemoryDragon]

I do mainly javascript coding full time. The awesomeness of the language in my opinion for real world project is rather limited unless you can use the more recent ECMA standards.
The language is functional, that is true, but it has lots of design weaknesses, you have to bypass with your own often incompatible constructs.
Prototype inheritance, while rather flexible introduces a certain mess because third party libs often have clashing implementations with oo constructs on top. The entire functinal handling and no real this binding construct (you can workaround that however via execution functions). Ever wondered where why your this in your function suddenly is something else? No scopes of visibility no namespacing etc...
The list of quirks and problems is endless!

All this can be fixed and many of those issues are fixed, but the javascript dialects most people have to use still have those issues!

Re:Takes the idea of "open source" to a new level

[Anonymous Coward]

You misunderstand the concept of cache hits. Whether you get a cache hit or miss isn't dependent on how much memory your *program* loads up; it's based on what's being executed at a given point in time....If you have a core loop iterating through some data structure, if you're not calling any big libraries, then they're not affecting cache hits for your core loop; the cache is going to be dominated by that data structure.

And if a data structure is larger than a layer of cache, you have to go to the next layer. That is to say, you get more cache misses and have to hit RAM.

See the "Pigeonhole Principle".

Re:Takes the idea of "open source" to a new level

[Cyberax]

Have you heard about COM? You know, a cross-language toolkit which is widely used in Windows?

Look inside it - it can be built right on top of C++ objects. And it has FAR less overhead than gobjects in GTK.

So C++ bindings can certainly be done.

Re:Takes the idea of "open source" to a new level

[Anonymous Coward]

C++ libraries are a nightmare across compilers

This hasn't been true for at least five years or so, since everyone adopted the Cross Vendor C++ ABI.

Re:Takes the idea of "open source" to a new level

[segedunum]

Umm, because it's precisely the *right* language for the job.

Hmmmm, and that is based on? :-

C++ restricts your binding options to other languages pretty dramatically

I wish people would drop this stupid bindings argument. It's brain dead. Firstly, bindings have to be maintained, properly, if they are to be of any use to developers. That takes effort. Secondly, why bother with binding object orientation and other languages on when you can have a language built with proper object orientation in the first place because that's what your software requires? Vala shouldn't even really be necessary.

Oh, and the Smoke bindings that KDE uses have proved you wrong. So pffffffffffffff.

Re:Takes the idea of "open source" to a new level

[TheRaven64]

It doesn't have to be interpreted. We just committed a partial implementation of a JavaScript dialect (EScript) to Etoile svn as a front end to LanguageKit, which works as both a static compiler or a JIT. It's not a complete ECMAScript implementation, but it's very close and integrates completely with our existing libraries.

We use hidden class transforms at run time to allow Objective-C objects to be used as JavaScript prototypes (you can also use them as prototypes in Smalltalk by using key-value coding with a BlockClosure instance as the value). In the next few weeks I plan on writing an AST transform that will do the hidden class transforms at compile time for the most common cases (i.e. when the prototype is Object or similar).

Access to the source code is nice, but it's less relevant when you have a proper introspective environment and can replace methods in existing classes on the fly.

Re:Takes the idea of "open source" to a new level

[scientus]

have you heard of bytecode? bytecode is not source, although it is possible to dissassemble it

Re:Takes the idea of "open source" to a new level

[sholsinger]

You might want to look into a JSON object being returned. It could be more extensible. Although if you're controlling the output and how it is used, it may not be a huge deal. :)

Re:Takes the idea of "open source" to a new level

[MadKeithV]

TPeople who don't use const correctness slow down their code ...

That's actually a rather persistent misconception (usually). See Guru Of The Week 81

Re:Takes the idea of "open source" to a new level

[nesstopher]

Absolute WORD sir. C++ for fast shit, python calling the shots. Heaven.

Re:Takes the idea of "open source" to a new level

[arth1]

There's a pervasive myth that C++ is just objects on top of C. Or that because you can use objects, that means that you *have* to use them everywhere.

And there's a pervasive ignorance that C++ earlier was named "C with classes".

Re:Takes the idea of "open source" to a new level

[petermgreen]

Then why the fuck is its primary windowing library (and a lot of other stuff) written in something as absolutely cretinous as object-oriented C?

So what were the other alternatives?

C++ until fairly recently had a very unstable ABI on linux. The libstdc++ on linux is at major version 6. The gtk/glib stuff is only at major version 2, Also has the same problem of breaking abi if you change the field structure of core objects. Also hard to bind with from other languages.

bytecode languages like java get arround the "abi is broken by adding fields" problem but they intoroduce a load of problems of thier own.

The gtk1 to gtk2 transition has indeed been painfull but that was mostly because they decided (rightly or wrongly) to break API as well as ABI.

Re:Takes the idea of "open source" to a new level

[AKAImBatman]

no real this binding construct

Is there something wrong with "MyObject.prototype.mymethod = function() {};"? Or are you referring to the fact that a function can always be reapplied to a different object context? This is actually a feature, not a bug. It makes functions highly portable across your code. Yes, this means that passing a function as a parameter can create some issues, but that is what closures are for. Rather than creating entire objects to implement interfaces, you can create a very [i]private[/i] communication channel at any time with a closure. Doing this in a structured language like Java is a pain and a half and generally leads to the practice of exposed, but undocumented APIs.

Ever wondered where why your this in your function suddenly is something else?

Not since I understood Javascript scoping. Once that was done, my issues with what "this" is disappeared.

No scopes of visibility

This is a myth. A popular myth, but a myth none the less. Javascript works by implicit visibility rather than explicit visibility. Thus:

function MyObject() { var value = 0; /*private*/ this.pubvalue = 0; //public
this.getValue = function() { return value; };
this.setValue = function(newValue) { value = newValue; };
}

More info here.

no namespacing

There are more ways to do namespacing in Javascript than Carter has little pills. e.g.:

var com = {mypackage: {stuff: function MyObject() { } } }

Which can then be instantiated with:

new com.mypackage.stuff.MyObject();

Some people even use a helper function to reduce the vulnerability that a package will get overwritten:

function namespace(space) { var spaces = space.split("."); var index = 0;
function createSpace(parent, child) {
if(!parent[child]) parent[child] = {};
index++;
if(index < spaces.length) return createSpace(parent[child], spaces[index]);

return parent[child];
}

return createSpace(this, spaces[0]);
}

namespace("com.mypackage.stuff").MyObject = function() {};

But I don't recommend it. Usually you want to reduce your footprint to as little as possible. Zero is ideal. e.g.:

(function() {
var myvar;
function myFunction() {}
alert("I can put code here willy-nilly and it will never impact the parent context unless I specify. Weee!");
})();

Unless you need to share out public APIs:

var MyAPI = (function() {
function myFunc() {};
//Create a proxy object to expose only the public parts of this inner sanctuary.
return {myFunc: myFunc};
})();

If I were to sum up your complaints (and those of 95%+ of people programming Javascript) I would do it like this: You're trying to write C-Style code in a LISP-style language. Stop it. Things get better after that. :-P

Go watch this video series: http://video.yahoo.com/watch/111593/1710507 I guarantee you'll have a few "aha!" moments. Especially when it comes to scoping. Once you understand how to make JS scoping work for you rather than against you, life gets a lot easier.

The following text is garbage to make Slashdot's stupid filters happy. Ignore it. Apologi

Re:Takes the idea of "open source" to a new level

[lwsimon]

Amen to this. Short of ActionScript, the best thing that has ever happened to me was finding jQuery. I get to forget about dealing with differing implementations, and worry about coding again!

I don't think I have a full understanding of the inheritance model in Javascript yet, but I know how to right clean, readable code. Most of my insight has come through trial-and-error, though. As far as I can tell, everyone who truly understands how Javascript works is busily creating webapps, and all the posers who can't get jobs sit down and write tutorials.

Re:Takes the idea of "open source" to a new level

[nobodyman]

I do like Javascript, and agree that it has suprising depth. That said, I think that Brendon probably didn't anticipate how large some of these javascript codebases would become. Well over a decade ago you never saw anything like the javascript frameworks like what you have today. Sure there are ways to mitigate javascript's scalability issues but it's not formalized and explicit.

I really like some of Brendon Eich's proposals for JS2, and they seem to address some of the issues of the grandparent's post: packages, visibility qualifiers, (optional) static type checking. @AKAImBatman: I've come to really respect your comments here on slashdot, so I'd be keen to get your take on JS2.

Re:Takes the idea of "open source" to a new level

[AKAImBatman]

I'd be keen to get your take on JS2.

I have a rather conflicted view on JS2. There are a lot of aspects I like about it, yet I understand the various arguments against it. I think both sides have a lot of merit in their arguments and should be heard out. Perhaps most telling is that the only widely-deployed implementation of JS2 (ActionScript 2.x) actually compiles its code down to JS1 code. (Do a decompile of a Flash 8 movie sometime and you'll see what I'm talking about.)

More to the point, most of the features offered by AS2 can be accomplished in AS1 or require a compiler to be effective additions. In result, I think the market's current solution is the best solution. Which is for complex projects to use a JS2 compiler as an intermediary step for type checking and object translation. The end results will operate and interface correctly in the browser, but the abstractions will be a bit more familiar to traditional programmers.

Of course, the implication is that large-scale projects CAN be done in JS1. And I'm going to voice that opinion right now. (e.g. See Pixtastic for a well-architected and scalable application.) The catch-22 is that JS development leaves more power in the hands of the developer. This forces the developer to decide on the best organization for his project.

Unfortunately, leaving more power in the hands of developers can be disastrous for programmers with insufficient seniority. They create a huge mess, then they curse the language for its apparent failures. Languages like Java force them to think a particular way about project organization, so why should Javascript leave so many options open?

These are the people for which JS2 is a very good idea. JS2 promotes good development practices without completely removing the underlying power that makes Javascript such a great language to work with. Thus my opinion on why the market will choose JS2 compiled to JS1 in the same way that C++ is a powerful object system on top of C. (Though a little less hokey in practice. ;-))

Re:Takes the idea of "open source" to a new level

[Rei]

And there's a pervasive stubborness about refusing to admit that that's not all it is. Perhaps back in 1980, but certainly not now.

Re:Takes the idea of "open source" to a new level

[caseih]

For others' information: http://techbase.kde.org/Development/Languages/Smoke

Smoke looks more like a COM-style marshalling system than a mere language binding. From what I've read, basically Smoke wraps every object in special qobject proxy. If this is correct, then my original reasoning stands. C++ requires wrappers or proxies to work well with other languages. gobject C-based libraries, as nasty as they are to develop, require much much less of this.

So no. Smoke bindings haven't proved me wrong.. in fact they've proved my original point. No the binding arguments aren't stupid. Besides all this, arguing that core Gnome APIs should be C++ based is just silly because they are already C-based. If we rewrote everything we'd just end up with KDE/Qt anyway.

Re:Takes the idea of "open source" to a new level

[Trinn]

I agree that Obj-C is not an abomination, but its not exactly a middle-ground either. In a lot of ways, it's C++ done "right", a thin layer doing nothing more than adding good solid object support to C, with admittedly slightly odd syntax based in its choice of "messages" instead of "methods", which with late binding actually adds a lot of flexibility. Also, Objective-C has good introspection support where C++ basically has none

Re:Takes the idea of "open source" to a new level

[Anonymous Coward]

Makes one ponder, why has no one thought of this before now?

Seriously though, GTK's base libraries are written in C because of GObject. GObject is a C library which, while making programming a bit more annoying, makes it incredibly easy to use your library/software with other languages. You write it once in C (using GObject), then it can very easily be ported to C++, Python, Ruby, Vala, etc. Going the other direction isn't so easy. The idea is, you write libraries other people will use in C, then people write front-ends (which aren't typically reused by other software) in something like Python.

Re:Takes the idea of "open source" to a new level

[tyrione]

``(I won't even mention Objective C, which is an abomination unto Nuggan)''

Bravo! Nice shot of bs.

Re:Takes the idea of "open source" to a new level

[tyrione]

Objective-C is a superset of C. End of story.

Re:Takes the idea of "open source" to a new level

[tyrione]

When is Etoile going to be ready to just build against the stable GNUstep APIs and not the unstable? Debian is so far behind the curve on having the latest Stable, let alone Unstable that it's rather annoying.

Of course, if the Debian maintainers for GNUstep published their build procedures I'd keep amd64 packages current with both Stable and Unstable.

Re:Takes the idea of "open source" to a new level

[kelnos]

(I won't even mention Objective C, which is an abomination unto Nuggan)

I love Objective C. I hate C++. ObjC is what C++ should have been: a thin object-oriented layer on top of C that adds dynamic runtime type-checking. The fact that method calls are simply messages passed to objects is brilliant. Now, ObjC's syntax can leave much to be desired, but the technical details of the language are great, IMO.

Re:Takes the idea of "open source" to a new level

[kelnos]

More or less, yes, but licensing terms can still be whatever the author wants. It's harder to enforce proprietary licensing terms when you have to give the source away (obfuscated or otherwise) for the program to run, but it's still doable.

Re:Takes the idea of "open source" to a new level

[segedunum]

If this is correct, then my original reasoning stands. C++ requires wrappers or proxies to work well with other languages. gobject C-based libraries, as nasty as they are to develop, require much much less of this.

This means what, exactly? There's no criteria saying you can't use wrappers or proxes of any kind to aid in providing bindings. The stupid and utterly meaningless implication was that C++ made libraries too hard to bind to. That isn't the case. Sorry.

So no. Smoke bindings haven't proved me wrong.. in fact they've proved my original point.

Yes they have. You implied that it was utterly fantastic for GTK and Gnome to be using C, even though they are inherently object oriented bit os software in their nature, because C was far easier to bind to than and implied it wasn't really possible with C++. It was a stupid metric to use to decide on a base language to use, but still wrong.

No the binding arguments aren't stupid.

Yes they are. Firstly, when you have a GUI toolkit and desktop environment that is inherently object oriented in nature then it is sensible to develop off a toolkit and a language that uses object orientation. Why bother using C and GTK and then creating object oriented bindings off the back of it? It's a lot of work for nothing. Secondly, very, very few people actually use language bindings and C is still the primary language of application developers within Gnome. Thirdly, there is an awful lot more important criteria than how easy your language and libraries are to bind to. The more bindings you have and the 'easier' it is to do them doesn't write applications and create functionality. I've never understood this whole bindings thing that comes out. It doesn't matter and no one cares how many bindings you have or how seemingly easy they are to create. It only matters if it is helping developers to develop lots and lots of applications and functionality that users care about with them. They aren't.

Besides all this, arguing that core Gnome APIs should be C++ based is just silly because they are already C-based.

Yes it is and yes they are. However, they were still completely wrong to develop an object oriented toolkit and an object oriented desktop environment with a language that has no object oriented features whatsoever and then hack them on.

If we rewrote everything we'd just end up with KDE/Qt anyway.

ROTFL. There you are then. Nuff said.

Re:Takes the idea of "open source" to a new level

[TheRaven64]

Etoile 0.4 builds against the latest stable GNUstep release. I don't think trunk requires anything newer, but I could be wrong (I tend to run GNUstep trunk so I can help spot bugs there too). I think Hubert Chathi is GNUstep maintainer for Debian - you could try poking him to get the latest GNUstep in. Or you could just run FreeBSD, which has Etoile 0.4 in ports...

Re:Takes the idea of "open source" to a new level

[badkarmadayaccount]

What do Bulgarians have to do with this? And someone tell me what a sodomite is.

Re:Takes the idea of "open source" to a new level

[Anonymous Coward]

There's no criteria saying you can't use wrappers or proxes of any kind to aid in providing bindings.

There is a performance hit to wrappers and/or proxies. You need more memory and more CPU cycles to call wrapped or proxied APIs.

It may well be that, in your humble opinion, the penalties are small enough that they don't matter. The people working on little embedded devices such as cell phones may disagree.

So, we have the situation that for Qt, everyone uses C++ to develop Qt apps, because nothing else works as well. For GTK+, some people use C++, some use C, others use other things. This is the point GP was making.

The stupid and utterly meaningless implication was that C++ made libraries too hard to bind to. That isn't the case. Sorry.

Damn you're being pissy about this. Chill out dude.

Why bother using C and GTK and then creating object oriented bindings off the back of it? It's a lot of work for nothing.

The guys writing GTK in C are gaining the advantages of C (portable, efficient, and reasonably compact code). They are writing in an object-oriented style; C doesn't natively support this, but you can do it anyway. So then, it's easy to wrap this object-oriented API in any language, including C++.

You might say "screw that, I want C++ anyway, so I'll just use Qt which was written in C++ in the first place". Fine then, good for you, have fun with that. But I would like to use, say, Python to write apps; and the job of wrapping GTK+ in Pythin is way easier than the job of wrapping Qt in Python.

You can scream and call me an idiot now.

Re:Takes the idea of "open source" to a new level

[Anonymous Coward]

Wait a minute, your argument for JS1 viability is based on the fact that Flash _bytecode_ can be decompiled to it? Because it could also be decompiled into Fortran if you wanted to badly enough, but it doesn't exactly mean we should make a start on changing all our "=="s to ".EQ." in preparation for Web 3.0.
And yes JS2 features can be emulated using JS1... kind of like how C++'s features were once implemented in C (think CFRONT), and anything in C could also be done in assembly... so now that we've covered building namespaces in JS with object literals, why don't we discuss embedding assembled opcodes in C strings?

Re:Takes the idea of "open source" to a new level

[try_anything]

I think that a concerted effort to get the desktop away from native code is the right move

Away from native code or away from crappy, unsafe languages? It's true that those two things are firmly linked by history and culture, but it's not completely correct to conflate them.

Re:Takes the idea of "open source" to a new level

[try_anything]

As for "extreme speed", C++ will almost always be at least slightly slower than C, if nothing else because of data being copied whenever there's an inheritance or overloading

Ah, but inheritance in C++ is faster than faking it in C. If you can't afford OO features as implemented in C++, then you damn well can't afford to fake them in C.

Yet that's consistently what people do after rejecting C++ as "too slow" or "too bloated," which only proves that they may *aspire* to care about such micro levels of performance, but in practice they can't tell the difference.

Same thing for code complexity. People reject C++ as "too complex" or "too kludgy" and then use macro-based homebrew OO systems for C that are more complex, more obscure, and much harder to use correctly. Gee, if only I could think of a relevant example :-)

Re:Takes the idea of "open source" to a new level

[arth1]

Ah, but inheritance in C++ is faster than faking it in C. If you can't afford OO features as implemented in C++, then you damn well can't afford to fake them in C.

Right. Which is why you do not think OO when you want performance. The two are, with today's technology, incompatible. Anything that can be done with OO can also be done without OO, faster, but you have to redesign your algorithms, and not try to shoehorn your C++/C#/java vision into C.

Re:Takes the idea of "open source" to a new level

[try_anything]

I don't think it's fair to say that any language with useful applications is incompatible with performance. Emacs Lisp is way too slow for the work that I do, but it performs just fine for me when I'm use Emacs. Putting that aside, I think your idea of OO is bigger than the C++ idea of OO. The C++ idea of OO is rooted in its history: people were slogging through a lot of problems writing object-oriented systems in C, and C++ was originally developed to make that task easier. (Bjarne Stroustrup was already looking for a fast OO language before he started working on C with Classes, but the early evolution of C with Classes/C++ was focused on serving its early adopters, which were dissatisfied C programmers who wanted support for OO but couldn't afford the overhead of traditional OO languages.)

So C++ has a concept of object-orientation that is very different from the OO ideal that came from the Smalltalk tradition. In C++, object orientation is more about the way a program is conceived and the way source code is expressed and organized than about runtime support, though C++ does provide efficient runtime support for common OO constructs if you want to use it.

The definition of OO you're using is probably more widely accepted, and many people say that C++ code isn't OO unless it uses dynamic dispatch and run-time type identification, which do have runtime costs, so you're basically right IF those costs actually affect performance in your work -- but you have to admit you're in a very small minority in that case.

Re:Takes the idea of "open source" to a new level

[MemoryDragon]

I knew about all this firsthand. I dont have a problem with function reapplyment, I have a problem that in many cases this reapplyment happens automatically which then results in sideffects which are if you are not aware of those problems can be horrendous (and face it 99% of all programmers are not aware of them)
I know you can bypass this problem with function.apply(target, params) but this is the wrong way, it should be that reapplyment should be verbose instead of automatic why the non reapplyment is verbose!

About namespacing, I use all of those workarounds to get javascript up to the level i need it. I use the map workaround to get at least basic namespacing. But selling a definitive lack thereof with dirty hacks and it is nothing more as feature is beyound me. And no I do not program javascript C style, I program it functional language style with the function being the basic of everything and shifting them around the data.

But I simply hate the mentality of the people promoting functional languages by selling dirty hacks as features.

Who in his right mind would sell a direclt VTBL manipulation in C++ as a feature and yet this is promited via prototype function. Who in his right mind would sell a map hack in Modula as a feature to reach namespacing but yet exactly that happens here!

Sorry I do get it but I simply do not like it!

Re:Takes the idea of "open source" to a new level

[MemoryDragon]

The problem I see is more along the lines that JS1 does leave out too many constructs which have been proven in the organisation of big projects. It does some critical things implicitely (this reassignment in function shifts in certain not all constructs) which then can cause problems in the codebase hard to identify for the medium skilled programmer. It leaves vital language concepts open just by opening the interpreter basics, resulting in various often incompatible operations of the same operations over various libraries.
To the worse it has no isolation concepts at all leaving everything open in the wild. And history has shown certain library authorse use that to the extent to break a huge load of other libraries that way!

Javascript 1 might be a neat proof of concept und with a good set of programmers you even cann pull of decent applications but I think this language is more dangerous than goto!

Re:Takes the idea of "open source" to a new level

[AKAImBatman]

It seems to me that the core of your argument is that you don't like using what you like to call "dirty hacks" in Javascript. Which I'm afraid I cannot understand. While I can understand wanting to use the language in a standardized fashion to prevent unmaintainable spaghetti code, the methods I mentioned are how the language was designed to be used. The patterns that you use in Javascript obviously are not analogous to any other language, but that's because Javascript itself is a very unique language.

I'll grant that the language will happily allow you to slice your own arm off* if you're not careful with it. But educating programmers on the best practices can help solve that in much the same way that best practices in Java helped cure programmers of writing highly procedural code, abusing exceptions for information that should be checked, using reflection to accomplish functional code, and other practices that just weren't good for that language.

Who in his right mind would sell a direclt VTBL manipulation in C++ as a feature

Steve Russel? The concept of functions as data elements is a very powerful concept that has its roots in Lambda Calculus. C++ virtual functions are a poor man's functional solution at best. Javascript, LISP, and other functional languages use functions are true data items. Javascript has seen fit to turn this into a complete object system. Such a system is known as Duck Typing.

Who in his right mind would sell a map hack in Modula as a feature to reach namespacing but yet exactly that happens here!

I'm trying very hard to wrap my head around this argument, but I'm not reaching much success. I presume you're talking about the dynamic spaces hack? Modula is in a whole other class of languages. (Imperative languages at that.) Doing anything functional in Modula is obviously a hack. But in Javascript, it's how the language is designed to get things done.

Functional development works in Javascript, and it works really well. If you can just get past your prejudices from doing years of imperative development, you'll see that there's nothing really wrong with Javascript's approach. It's just different. And trust me. I found it just as hard a pill to swallow at first. ;-)

* Like a lightsaber. Very powerful yet very dangerous weapons. They have no counterweight to protect the bearer! ;-)

Didn't RTFA....

[Chabo]

So, this is basically Seed uses Javascript to make GTK+ code easily, so you can move on to make the heart of the program faster?

Re:Didn't RTFA....

[Chabo]

Edit: Remove "this is basically"

Stupid lack of an "Edit" button... talk about user interfaces!

Re:Didn't RTFA....

[Bloater]

But javascript is an awfully convoluted language. Why does it become easy when you put a language like that into the equation?

Re:Didn't RTFA....

[Chabo]

I'm not defending it, I was just asking if I condensed the point of the project correctly.

As for writing JS to make GTK+ code... if you've ever coded a GUI by hand, you know it's a pain. I realize that tools like Visual Studio, Eclipse, et al are supposed to take care of this, but some people like to code GUIs from the CLI for some perverted reason. I only had to for a class, and I never want to do so again.

That said, if I understand the point of the project correctly, I think it's hugely pointless.

Re:Didn't RTFA....

[siride]

C++ is awfully convoluted, maybe. JavaScript is pretty simple and straightforward, aside from a few minor gotchas. Most of the problems with JavaScript are browser API issues and not with the core language itself. It's pretty much the opposite of convoluted.

Re:Didn't RTFA....

[Tetsujin]

As for writing JS to make GTK+ code... if you've ever coded a GUI by hand, you know it's a pain. I realize that tools like Visual Studio, Eclipse, et al are supposed to take care of this, but some people like to code GUIs from the CLI for some perverted reason. I only had to for a class, and I never want to do so again.

I feel like the tough part is simply working out the layout of the thing - the nested containers, the widgets that go into 'em, etc. From there, hooking up code to the widgets seems like not such a big deal.

You can get through the layout phase with a tool like Glade... Or you can code it by hand. I'd agree that coding it by hand is a real chore, but it's only really awful if you have the code/compile/test/fail/repeat cycle in there. (If it's just code/test/fail/repeat, that's not so bad... But I'd still sooner use Glade.)

Re:Didn't RTFA....

[FishWithAHammer]

some people like to code GUIs from the CLI for some perverted reason

Some people might say that those people should not be allowed to program GUIs.

Re:Didn't RTFA....

[SanityInAnarchy]

some people like to code GUIs from the CLI for some perverted reason.

The main reason being, you then have an easily-scriptable commandline version, and an easily-usable GUI version. Bonus is that you won't need any GUI installed at all on a server in order to use the commandline version.

You've also decoupled logic from presentation, which is generally considered A Good Thing -- it makes replacing the GUI easy, and it makes competing GUIs possible, without having to dig into any of the core logic.

Granted, it would be better to take the whole system into account when writing either -- it's a lot easier to write a GUI for a commandline app which was written with that in mind, than one which was written with nothing beyond a VT100 in mind. But the advantage still stands.

Re:Didn't RTFA....

[SleepingWaterBear]

But javascript is an awfully convoluted language. Why does it become easy when you put a language like that into the equation?

I don't know, I used to think javascript was a mess, but having learned a good bit more of it recently, it's really a much more elegant, flexible, and well designed language than a lot of people give it credit for. Personally, if I wanted scripting built into my Desktop I would choose python for the documentation, ease of coding and power, but you could do a lot worse than javascript.

Re:Didn't RTFA....

[Phantom of the Opera]

javascript is closer to lisp/scheme than to C in many ways. It supports closures, macros (functions that build functions), and evals. Rather than list oriented, it's dom oriented.

Of course, it is convoluted. It's just far more subtle than it appears (or is often used).

Re:Didn't RTFA....

[Otter]

The main reason being, you then have an easily-scriptable commandline version, and an easily-usable GUI version.

Huh? Whether the application is scriptable has nothing whatsoever to do with whether a layout tool was used to create the GUI.

Re:Didn't RTFA....

[Anonymous Coward]

JavaScript is pretty simple and straightforward, aside from a few minor gotchas.

Inheritance is pretty weird in JavaScript. Most people aren't used to a prototype-based system.

It's pretty easy to leak memory without meaning to by creating a closure you didn't want.

There are probably other issues. Those are just the ones I have seen the most in discussions on Slashdot.

Are those the "minor gotchas" you had in mind?

Re:Didn't RTFA....

[SanityInAnarchy]

Whether the application is scriptable has nothing whatsoever to do with whether a layout tool was used to create the GUI.

Ah, sorry -- I'm with you there, I'd much rather create the GUI with some kind of graphical assistance, even if it's just Firebug.

Re:Didn't RTFA....

[multipartmixed]

It's not DOM oriented. DOM isn't even necessary for javascript. It would be more accurate to say it's object-oriented, except that implies OOP, which it isn't.

Re:Didn't RTFA....

[AKAImBatman]

It's pretty easy to leak memory without meaning to by creating a closure you didn't want.

Generally speaking, that's a problem with Internet Explorer. (That took them FOREVER to fix.) You can still leak memory by foolishly creating closures all over creation, but for the most part it's pretty difficult to leak memory on accident. At least, no more or less difficult than it is with your average OOP language.

Re:Didn't RTFA....

[AKAImBatman]

It would be more accurate to say it's object-oriented, except that implies OOP, which it isn't.

I think you're confusing "class based" with "object oriented". Javascript is very much an Object Oriented language. Otherwise, how would this code work?

function MyObject()
{
    var value = 0; //private
 
    this.getValue = function() { return value; };
    this.setValue = function(newValue) { value = newValue; };
}
 
var obj = new MyObject();
 
obj.setValue(10);
alert("Value = "+obj.getValue());

(You can save yourself the trouble of creating an HTML file by using this page to test it.)

Prototype-based OOP can do almost everything Class-based OOP can do, except that it is far more flexible at runtime. You lose some compile-time checking, but it's been found that strict compile-time checking doesn't offer nearly as much error-catching benefit as was originally envisioned.

If you're absolutely in love with compile-time checking, consider a Javascript 2.0/ECMAScript 4.0 compiler. That will help catch typing errors up front while still creating code that's deployable in Javascript 1.x/ECMAScript 3 VMs.

Re:Didn't RTFA....

[shutdown -p now]

Actually, yes, JS is much more convoluted than it has to be, partly because it pretends to be so many things at once. Non-local local scope is a good example. For a Java-looking language, you'd expect code blocks to introduce scope, but they don't. For example:

var x = 123;
 
function foo()
{
  document.write(x);
 
  if (true)
  {
    var x = 456;
  }
 
  document.write(x);
}
 
foo();

This will not give any errors on the second var, but it won't print "123123" as expected, either. This is because the var declaration makes the variable local in the scope of entire function (despite the declaration itself being in a block), and the declaration applies to all references to that variable within the function, even those preceding the declaration.

If that's not a gotcha, I don't know what is. It's worse than VB6 scoping rules.

And no, it's not the only messy thing in JS.

If you really want to see what a clean, non-convoluted language with JS-like philosophy should look like, see Lua. It's no surprise that the latter is heavily used for scripting in many places where there's a lot of it (e.g. games).

Re:Didn't RTFA....

[siride]

Honestly, I don't see the big deal with having strict block-level scoping rules. It really seems like it makes it harder to deal with the code because you have more levels to keep track of. If you really need levels of scope nesting, just use functions. And then your code will be more clear.

I've never run into a situation where I though "damn, I could really use proper block-level scoping" when using JS or PHP. And I came from a background of C, and I really like C. I appreciate the theoretical value of block-level scoping, but in practice, it seems to be nearly useless.

Re:Didn't RTFA....

[shutdown -p now]

It's not a big deal in and of itself, the problem is that it's hidden. I wouldn't mind if JS restricted "var" to the beginning of the function, for example - the way Pascal (which also didn't have block scoping) did. But the language that allows a variable declaration in the middle of the block should do what every other language that allows it does. And that's not even mentioning the "backwards scoping" misfeature - in fact, JS is the only language I know in which you can use a local variable before its local declaration...

Re:Didn't RTFA....

[MadnessASAP]

So you're above proofreading then? I'm personnally more inclined to blame the user rather then the interface.

Re:Didn't RTFA....

[SwedishPenguin]

That's what happens when you proofread *after* you post. ;)

I believe the lack of an edit button is intentional..

Re:Didn't RTFA....

[Anonymous Coward]

You lose some compile-time checking, but it's been found that strict compile-time checking doesn't offer nearly as much error-catching benefit as was originally envisioned.

Lol, gotta love slashdot. Citation please? Unless you can come up with a thoroughly researched and peer-reviewed paper which accounts for all the more recent approaches to static type checking (like typeful programming, dependent types, etc.) supporting this, I'd say you were full of shit. Hint: The static/dynamic type checking isn't anywhere close to settled.

Besides, JavaScript gets what is arguably the most important feature of any language, namely scoping, completely and utterly wrong.

Re:Didn't RTFA....

[AKAImBatman]

Unless you can come up with a thoroughly researched and peer-reviewed paper which accounts for all the more recent approaches to static type checking (like typeful programming, dependent types, etc.) supporting this, I'd say you were full of shit.

I'd say you weren't paying attention. I didn't say that static typing never catches errors, I said that it does not catch as many errors as originally envisioned. As nearly any programmer can attest, it's a rare treat to have a program operate correctly after the first compile. More often than not, you need to perform iterative development and debugging to ensure the correctness of the code. The unfortunate result is that developing for a statically-typed vs. dynamically-typed language makes little difference to this process.

That being said, there are some advantages to a statically-typed language. e.g. There are no untested code segments with typing errors waiting to blow up. The code may blow up for other reasons, but typing won't be one of them. (Unless you force a cast, that is. Casted objects can blow up quite nicely.)

The other area where it's a good idea is when your code will share out or access a standard interface outside your project. In such cases, typing can create a contract that ensures the correct use of all APIs.

That's why I suggested the use of a JS2.0 compiler for times when typing is important. JS2.0 is a softly typed language. Typing can be defined to ensure correctness, but typing is not required. This allows for interfaces and APIs to be exposed properly while leaving the individual developer a free hand to design his code in a classless fashion.

I'm not going to write an entire dissertation on this, so see Bruce Eckel's excellent article on this issue for a decent introduction to the compile-time checking issue.

Besides, JavaScript gets what is arguably the most important feature of any language, namely scoping, completely and utterly wrong.

You've just pointed a finger at the very thing Javascript gets absolutely correct. While the scoping system may seem weird and even incorrect to coders with experience in other C-style languages, the Javascript scoping system is what welds the OOP aspects of the language together with the functional aspects of the language. If you changed the scoping system, you'd completely destroy Javascript's object system in addition to gimping its functional aspects. Which would leave you with the just the crappy procedural code that your average web developer creates for neat webpage effects.

Re:Didn't RTFA....

[TheRaven64]

Have you ever read the ECMAScript specification? I did when implementing EScript. It's horrible. The rules for when variables are bound to a closure are insane. It's like someone started with Self, added Java-like syntax, and then thought 'hey, this language is pretty nice. How can we fuck it up?' The rules for calling functions with and without the new keyword are bizarre and the implicit beta-reduction when returning a closure (but no explicit one) is just bizarre.

Re:Didn't RTFA....

[MadKeithV]

I was about to post a retort, but you have a point about it pushing developers towards using less scope inside functions, and more functions.
I realized it's not all that different than Python's indent-based scoping, which I like.

Re:Didn't RTFA....

[Coryoth]

I'd say you weren't paying attention. I didn't say that static typing never catches errors, I said that it does not catch as many errors as originally envisioned. As nearly any programmer can attest, it's a rare treat to have a program operate correctly after the first compile. More often than not, you need to perform iterative development and debugging to ensure the correctness of the code.

I'm not actually sure that's so. Yes, with many popular statically typed languages that's the case. On the other hand I've heard plenty of stories of Ada, Haskell, and other language programmers finding that, indeed, if they can get it to compile it works as they intended. This, of course, raises its own issues: you may have to do some hoop jumping and work to manage to get that compile to actually work. That means those languages might not be so ideal when you just want to muck out or quickly protoype some code (depending on exactly what you want to do of course). On the other hand, you are actually getting something for all that static typing.

Re:Didn't RTFA....

[mrlpz]

Then you're unclear as to the reasons for having scope in the first place. It's why books are divided chapters, and chapters into pages, pages into paragraphs, and so on. It's to give it some semblance of context. Geez, why even have '{' or '}' then ? There's no reason to have key characters if there's no logical demarkation of scope after all. And if we're going that far, let's get rid of the ';'s then. We're all adults, we should KNOW where a statement ends, right ?

Obviously I'm being facetious, but only half so. It's because for as many nice things there are in JS, I keep coming up with more rationales for why JS must wither. Lua is a great example of scripting done right ( or at least more coherently than JS will ever be ), but it has it's limits of utility as well.

JS was a hack when it was incepted, continues to be a hack, and will plague us into the future unless people get a grip already.

I've said it before, and I'll say it again, the road to RIA is not paved in JS (even if embedded away from eyesight).

Re:Didn't RTFA....

[siride]

I'll ignore your reductio ad absurdum rant at the beginning (except to say that just because there are a lot of theoretical cases that we *can* respect, it doesn't mean that we necessarily *must* respect all of them) and go straight to the point. First of all, I don't think nor did I say that JS was the be all end all of languages. It's small, fairly clean and gets the job done. Are there better languages out there? Sure. Are there better languages in the same "niche" as JavaScript? Yes. Is JavaScript a terrible, convoluted, ugly mess? No (but DOM and web-browser support make it uglier than it needs to be). And that's really the extent of my point.

What about Python?

[Anonymous Coward]

Doesn't this already exist with Python? What advantage would there be to using JavaScript over Python? Python is a much cleaner language...

Re:What about Python?

[nurb432]

Same thing, different flavor.

Besides, you know people, they have to keep re-inventing the wheel, in their favorite color.

Its why we never get anywhere.

Re:What about Python?

[Anonymous Coward]

Golgafrinchans indeed.

Re:What about Python?

[icebraining]

Python? This already exits in javascript! Wasn't this the whole purpose of XUL? You can make a whole app with XUL, Javascript and XulRunner...

Re:What about Python?

[CarpetShark]

Doesn't this already exist with Python? What advantage would there be to using JavaScript over Python? Python is a much cleaner language...

Some people just have to be different.

Re:What about Python?

[Dreen]

All popular scripting languages have GTK support. Perl, Python, PHP, Lua, Ruby, they all have it. Now they are making one for JavaScript. Why? Boredom and overhypeness I guess.

Re:What about Python?

[irtza]

The wheel may have been invented, but different variations have their use - steering (car), scrolling (mice), tires (car), entertainmetn (ferris, of fortune, roulette), you know - let me check something... yup it exists: http://en.wikipedia.org/wiki/Wheel - the people like you would have stopped after the first wiki page ;) (j/k - aiming for funny here my friend, don't think anybody has been enlightened by this post though some may have been flamed (by accident)).

Re:What about Python?

[Tetsujin]

Same thing, different flavor.

Besides, you know people, they have to keep re-inventing the wheel, in their favorite color.

Its why we never get anywhere.

Well, really, the reason why we never seem to get anywhere is because accomplishing meaningful tasks is hard. Putting together a good app is a lot of work. Getting people to use it is more work. And without clear leadership, there could be a dozen people trying to solve the same task - and as a result, coming up with different solutions and competing with each other. "Getting somewhere" depends on clear leadership. Someone has to be able to take the available coding talent and steer it into a useful direction. That's very hard to establish when the coders in question aren't being paid. :)

It's not quite true to say we "never get anywhere", though. These days, on Linux, we can play all kinds of different video formats, we've got word processors, vector and raster graphics editors, modeling software... we didn't always have all that.

Re:What about Python?

[Anonymous Coward]

Common myth, often repeated, in many variations, by people who only know Python.

Re:What about Python?

[Urza9814]

It'd be quite nice for people like me who _can't stand_ python. Purely a personal preference, but I just can't stand any language that has specific rules about where you can and cannot put a space. Hell, I had a python script I was writing the other day that wouldn't run because in one place I had used a tab to indent after an if statement rather than a series of spaces. I like my damn curly braces! They're easier!

Re:What about Python?

[Anonymous Coward]

The source of your problem was the inconsistent use of tabs, not Python (and is a problem you will continue to experience until you do what every top notch developer eventually does in their career, which is to stop using tabs and ban them completely from all of your projects.)

I used to joke about Python: "friends don't let friends use white space for a control mechanism". I had the exact same attitude as you about Python but, since I am fairly intelligent, I was able to figure out that the curly braces are an unnecessary and distracting hassle and the indentation is going to be there anyway, and so I changed my mind. Too bad you are not able to do that.

Re:What about Python?

[Anonymous Coward]

Or maybe it's the reason we get anywhere at all. It works pretty well for evolution so why not for software?

Re:What about Python?

[ozamosi]

One advantage of using Javascript is that it doesn't already have a standard library that can do anything for you. This is a feature, since Glib can do those things for you already: if you mix too much, you'll run into inconsistencies (example: Gnome's virtual filesystems are really neat, and if your application uses Gio for file access, Gnome's virtual filesystems will be completely transparent. If you use Python's open(), everything will break). This is the kind of stuff everybody learns the hard way: by using a language without a built-in standard library, people can't do that mistake.

Another is obviously that all web developers "know" javascript, which some hope will bring more developers to Gnome.

Re:What about Python?

[mweather]

Well Gnome's entire existence owes itself to reinventing the wheel. It's kind of ironic now that QT is going LGPL and Gnome has come down with a bad case of Mono.

Re:What about Python?

[Toonol]

I don't know Python, but the grandparent post seemed to indicate there was a syntax bug because of the presence of a tab in place of spaces. This means that two programs can, visually, be absolutely identical and yet not behave consistently? Who would design a language like that?

Re:What about Python?

[cryptoluddite]

I had the exact same attitude as you about Python but, since I am fairly intelligent, I was able to figure out that the curly braces are an unnecessary and distracting hassle and the indentation is going to be there anyway, and so I changed my mind. Too bad you are not able to do that.

Python just recently added parentheses to print() function and zero-arg functions because, lo and behold 50+ years of computer science and thousands of years of mathematics were right. There actually is a reason to use characters to denote groups and blocks, and to note the difference between functions and variables.

Python's indentation requirements are like hungarian notation -- it sounds good to some people, but causes trouble in all sorts of annoying ways.

Also, python does use a block start/end character: the newline. Most other languages use a '{' or 'begin' to start a block or '}' or 'end' to end it. Python in contrast uses '\n' as a start symbol and '\n' as either a block continuation character or block terminator. Your language is not any different from those that use { and } except for being less well defined and more absurd.

Re:What about Python?

[chthonicdaemon]

Actually, the reason for the brackets in print() is that it is now a function where it used to be a statement. All the other statements are still there (like return or def, etc). The decision had nothing to do with delimiters. The point the GP was trying to make is that most people who have coded for any amount of time indent consistently as part of their routine. I have been tripped up many times by code that was indented to look different from the actual flow of control. But then I prefer begin end to {}, too.

It is flawed to hold up C as the only language that got things right just because it's popular, and I would hold out on the "more absurd" comments until you have given python a fighting chance (and this means not using whatever brace language you are used to for about 3 months to retrain -- before then you'll just be fighting habits from the other language).

Re:What about Python?

[Anonymous Coward]

A stab in the dark says....more developers to develop apps. Remember kids, a great man once said "developers developers developers"

Re:What about Python?

[Dhalka226]

Its why we never get anywhere.

Nah, the two things really have nothing to do with each other. People who make this link seem to think that if these people hadn't been working on JavaScript for linux apps thing, they would have been off doing Something Really Important(tm). In reality that's not true. Some people aren't cut out for big apps, some people don't know what the next new important thing is, some people don't have the technical skills to do whatever that may be. And more importantly, with open source, people are out to scratch an itch; they're creating something that they themselves might use and find valuable, directly or otherwise. It isn't terribly likely that these folks would have been writing drivers or coding an Exchange killer or what-not had they not been doing this.

More to the point, the statement's not even true on its face. We do get somewhere: we get another way that somebody can contribute to the open source ecosystem, and maybe they'll do that Something Really Important(tm) with it that you seem to be looking for. Somebody who wants to create something wants to create something. They don't want to first spend time learning a new language because it happens to have the appropriate bindings and the one they know and are comfortable with doesn't. Any way to bring more people into the fold is going to be a net positive.

Re:What about Python?

[Anonymous Coward]

Python is nice, but still it is not the lowest barrier of entry: if you leave it for a few months, you will forget. Also, the language itself is changing in a fast pace.

I have been working on a JavaScript shell with Google v8 engine for private use. For example the following script take a directory of jpegs and resize them:

var files=ls('..');
for ( i in files )
        if ( files[i].match(/.+jpg/i) )
        {
                var str = 'gm convert \"../'
                        + files[i]
                        + '\" -resize 1024x -quality 80 \"'
                        + files[i] + '\"';
                print( str );
        }

The ls() is written in C++, called within the script. The output can be redirected/written to a ".bat", or simply call cmd.exe or even a Bash shell or system call to execute. This one use GraphicsMagick executable to do the resizing. Or you can export GraphicsMagick api from C++ so that you can create a new function called Resize( width, height ) in JavaScript.

The point is JavaScript has so much potential and the barrier of entry to C programmer is so low. It also provide all the functional programming method you need. Sure you can do that in Python, or make a Scheme script in Gimp. But then the above script make sense to me more, probably make sense to a lot of people because the syntax is clear, concise and C-like. Learn Scheme to script in Gimp? Forget it, I might as well "perform" the batch processing by hand.

Re:What about Python?

[Anonymous Coward]

Wow. If that's your best argument, then you probably don't have much of a case...

Re:What about Python?

[Yvanhoe]

I discovered recently that the grudges I hold against Javascript (I used it when CSS was still science fiction) are no longer valid and that a lot of the features I like very much about python exist as well in Javascript:

a={}
a["this"]="is a hash table"
l=[]
l.push(a)

this is both a valid python or javascript code. Both languages are very similar. Javascript's image suffer from its earlier implementations. It is now a much more convenient language than it used to be. Python is fine for a lot of things and is still my language of choice but Javascript has been promoted from "over my dead body" to "preferable to many other alternatives"

Re:What about Python?

[jellomizer]

Portability.
You take you Gnome App. Rename a couple of files and put some HTML in front then you have a Web App. (yes yes gasp no we all hate web apps especially after RMS says they are bad) But for people who live in the real world it allows excellent migration of your code without having to copy a compiler over to each system. And like now you have to tell people what version to download. (Dont get 3 because the App was written in 2.x) type of stuff.

Re:What about Python?

[Anonymous Coward]

Then why not a VBScript implementation ^^

Re:What about Python?

[MrWim]

See Havoc Pennington's blog entry on this

excerpt:
<quote>I would define an "embedded" language as one that doesn't come with a platform. It's small and easy to glue together with an app written in C or C++. It uses the same platform as the app. If the platform has an introspection capability like XPCOM or GObject-Introspection, then the platform can be exported to the embedded language in an automated way.</quote>

Re:What about Python?

[mweather]

Case about what? Reinventing the wheel? Gnome abandoning it's original reason for existence? The tables turning?

Re:What about Python?

[JesseMcDonald]

The point the GP was trying to make is that most people who have coded for any amount of time indent consistently as part of their routine.

This is true. Of course, most people avoid typos as part of their routine as well, but such are still a common source of bugs. (At least one can see that kind of error...)

The real problem, however, is in sharing code between multiple developers. Each may individually follow a consistent indentation pattern, but (if my experience is any indication) no two members of any dev. team follow the same pattern. Spaces vs. tabs, different levels of indentation, custom tab stops, editors that automatically change tabs to spaces or visa-versa, etc. It's bad enough when these differences only affect the appearance of the code, and not its function. I agree with Toonol (#26525455):

...two programs can, visually, be absolutely identical and yet not behave consistently? Who would design a language like that?

Re:What about Python?

[cryptoluddite]

Actually, the reason for the brackets in print() is that it is now a function where it used to be a statement. All the other statements are still there (like return or def, etc). The decision had nothing to do with delimiters.

Actually it was entirely to do with delimiters, because lack of () on a zero-arg function and lack of () on print was causing ambiguity in some situations.

But I see there are python fanboi moderators here.

It is flawed to hold up C as the only language that got things right just because it's popular

Which is why I said "most languages". I mentioned { and } and 'begin' and 'end' which covers the vast majority of computer languages. I didn't even mention C, you did and then you attempted to shoot it down -- that's the definition of a strawman.

If whitespace were such a great idea, one would think those pushing it so forcefully would be able to give rational arguments for it.

Re:What about Python?

[CarpetShark]

Except that GTK+ is much more of a portability layer than the web for anything that actually starts off using a modern, fully developed GUI with context menus, 3D rendering, context sensitive help, accessibility, etc (which isn't available on the web, and won't be for years).

Re:What about Python?

[chthonicdaemon]

I fail to find any reference for the delimiter-based argument for making print a function (I looked for reasons for a print function here, and that PEP has some references too). Note that they didn't just add brackets, they actually changed print's semantics from being a statement to being a function.

I am sorry about the C thing -- I suppose I meant C-like languages as I hear this argument from users of such languages the most.

As for "pushing it [significant whitespace] so forcefully", I think you will find that most of the "python fanbois" are just saying that they tried it and it works, while the delimiter guys are far more belligerent about the stupidness of not having delimiters.

Re:What about Python?

[artsrc]

It is clearly bad that visually identical programs behave inconsistently.

However many (most?) languages have this issue. One area this problem occurs in "C" languages is the requirement that a '\' be the last character on a line for continuation of a string. Python improves on this situation by having a better syntax for multiline strings.

Perhaps the solution is on the editor side rather than the languages side.

There should be no hard tabs in program source.

One thing Python's approach does fix is that the indentation the programmer uses to reason about blocks, is the same as what the compiler users. This removes the standard gotcha in C:
if (condition); {
____action();
}

Re:What about Python?

[Kidbro]

No. Inconsistently mixing tabs and spaces is a syntax error. The program simply won't run, and it will inform you as to why (much like how your C compiler will propably let you know when you've used a lower case l rather than an upper case I, even though they look the same in your font).

Re:What about Python?

[cryptoluddite]

I fail to find any reference for the delimiter-based argument for making print a function (I looked for reasons for a print function here [python.org], and that PEP has some references too). Note that they didn't just add brackets, they actually changed print's semantics from being a statement to being a function.

I can't find it either atm. I remember reading about it when looking at closures or tuples or something like that.

Anyway you might find these two links might be worth reading.

Re:What about Python?

[icebraining]

The Python version would be similar:

        files = os.listdir('..')
        for file in files:
                if file.endswith('jpg'):
                        print 'gm convert \"../%s\" -resize 1024x -quality 80 \"%s\"' % (file, file)

You can tell me you don't like the lack of extra characters and the forced indentation, but it's clear and concise, and I don't think that a shift from Javascript to Python is that bad. Before Python all the languages I knew (besides BASIC) were C-Like and the transition wasn't difficult.

PyBank

[ciroknight]

PyBank is similar. It also uses GObject-Introspection to automatically bind GObject libraries.

In fact, the Javascript side of this article is completely overlooking the technology that is GObject introspection; adding run-time dynamic introspection to C applications (and soon, reflection too).

Re:PyBank

[segphault]

You need to read more carefully. There is a whole section about GObject introspection on the first page of the Ars tutorial. It even mentions PyBank.

Re:PyBank

[Anonymous Coward]

The entire point of Seed is to provide introspection bindings for JS.

Re:PyBank

[morgan_greywolf]

Right. But Python already has introspection without GObject. I think that was part of the original poster's point. And GObject and GTK have had very stable and mature Python bindings for years.

So the question remains: What does JavaScript bring to the table that Python or Perl or Lua or Scheme or Ruby do not?

IMHO, nothing other than the fact there are probably a lot more JavaScript programmers than all of those other languages combined. Of course, in general, they tend to be lower quality programmers.

If you ask me, this whole thing reaks of another language *cough*VBScript*cough* that has been the root cause of multiple security vulnerabilities on another operating system platform. Mostly, in fact, due to the high percentage of low-quality programmers said platform brings to the table.

Whut? What happened to AJAX?

[Anonymous Coward]

Ahh.. nevermind... i don't take Slashdot serious either.. xD

Perl and Python

[perlhacker14]

Is this not already present with Perl and Python? I mean, both support GTK and are fairly powerful and efficient...
But, JavaScript for desktop GUIs? That just gives me an odd feeling inside...

Re:Perl and Python

[Anonymous Coward]

But, JavaScript for desktop GUIs? That just gives me an odd feeling inside...

Forget JavaScript desktop GUI applications-- the possibility of system utilities or init scripts in JavaScript makes me shudder.

Re:Perl and Python

[bcrowell]

JavaScript is actually a sweet programming language. It's got a very clean design, nice straightforward syntax, and good support for both OO and FP. (I think people get a bad impression of it from seeing it used by people who learned to do stupid web page tricks from JavaScript for Dummies. Also, people who believe in the One True Way of OO tend not to like it because it doesn't do OO the same way as Java. There are also many horrible problems with DOM incompatibilities, none of which have anything to do with JS per se.)

The thing is, I don't understand the logic of using JS for high-level tasks and Vala (basically glorified C) for low-level stuff. The thing is, JS is a very small, austere language. The whole advantage of having a high-level language is lost when you use something as bare-bones as JS. JS is also much, much slower than Perl and Python, so you'd end up having to do only a very small percentage of your programming in JS, and the rest in Vala, in order to get decent performance.

To me it makes a lot more sense to write 100% of your program in, say, Perl. (s/Perl/Python/g or s/Perl/Ruby/g is that's what turns your crank.) You pull in some CPAN libraries, many of which have the time-critical stuff written in C for good performance, but you don't have to touch the C. If there does turn out to be some very time-critical loop that you really want to optimize, and it's not something generic that's available in CPAN, then you write it in C and interface it to your Perl program. You end up writing 99.9% of your own code in a nice high-level language, and 0.1% in a crufty low-level language, and you get good performance.

To me the most interesting part of the whole article is the idea of using Vala rather than C as a low-level language. Manual memory management sucks.

Re:Perl and Python

[JanneM]

The thing is, I don't understand the logic of using JS for high-level tasks and Vala (basically glorified C) for low-level stuff. The thing is, JS is a very small, austere language. The whole advantage of having a high-level language is lost when you use something as bare-bones as JS. JS is also much, much slower than Perl and Python, so you'd end up having to do only a very small percentage of your programming in JS, and the rest in Vala, in order to get decent performance.

The idea is this I think, more or less: Vala feels a fair bit like Java and C# - the syntax borrows heavily from C# for instance - but is completely statically compiled to C. So, unlike Java or C#, it doesn't need a separate runtime installed, you just get a normal, self-contained binary. JS is a lot more lightweight than the Python/Perl/Ruby trio, and the interpreter is even small enough to easily be embedded into the binary if needed. It means you can write a self-contained "traditional" binary using both a modern language and dynamic scripting with no need for extra runtime stuff.

Sounds like a good enough idea that it's well worth pursuing at least.

Re:Perl and Python

[msuarezalvarez]

But, JavaScript for desktop GUIs? That just gives me an odd feeling inside...

Maybe you have not heard of this new little app... It appears that there are a few people out there who even like it. It's a bit hard to find, because for various reasons it has been renamed way too many times... The last name, IIRC, is Firefox. Google should be able to find it for you.

Re:Perl and Python

[bcrowell]

The idea is this I think, more or less: Vala feels a fair bit like Java and C# - the syntax borrows heavily from C# for instance - but is completely statically compiled to C. So, unlike Java or C#, it doesn't need a separate runtime installed, you just get a normal, self-contained binary. JS is a lot more lightweight than the Python/Perl/Ruby trio, and the interpreter is even small enough to easily be embedded into the binary if needed. It means you can write a self-contained "traditional" binary using both a modern language and dynamic scripting with no need for extra runtime stuff.

I think the article is mixing up two things. One is the question of what's a good language to use for scripting and extensions. Another is the question of what's a good language to write all the high-level parts of your application in. The article describes using JS for both.

Let's say you have a program written mainly in C++, and you're looking for a language to use for scripting. I agree that throwing a Python/Perl/Ruby interpreter into your app for that purpose is just nuts. JS would be a reasonable choice (as would Lua or Guile).

On the other hand, if your program is written mainly in Ruby, with some C or Vala for a few time-critical routines, and you're looking for a language to use for scripting -- well, obviously you just use Ruby.

What the article seems to be proposing as well is that you use JS to write most of the code of your app, and that seems to me like an idea that's guilty of stupidity until proven innocent. I can imagine certain advantages of JS in certain cases (e.g., you want your app to run both on a Gnome desktop and as a web app), but in general JS is just not the best choice if you're looking for a high-level language to write a large GUI app.

Re:Perl and Python

[Ed Avis]

JS is also much, much slower than Perl and Python

Are you sure? Modern dynamic-recompiling Javascript engines like Tracemonkey, Squirrelfish or V8 are much faster than traditional bytecode interpreters such as perl5 and CPython. (Other Python implementations like Psyco will be faster.)

Re:Perl and Python

[badkarmadayaccount]

Obj J is nice enough, methinks. It's based totally on javascript, so it'll run when compiled anywhere JS will, only it looks just like Obj C. Maybe GNOME are trying to steal Apple devs? *shrug*

BTW, Obj J is released along with the Cappuccino web framework. Check 'em out, and no, I can't be arsed for a link.

Re:Perl and Python

[tieTYT]

To me it makes a lot more sense to write 100% of your program in, say, Perl. (s/Perl/Python/g or s/Perl/Ruby/g is that's what turns your crank.) You pull in some CPAN libraries, many of which have the time-critical stuff written in C for good performance, but you don't have to touch the C. If there does turn out to be some very time-critical loop that you really want to optimize, and it's not something generic that's available in CPAN, then you write it in C and interface it to your Perl program. You end up writing 99.9% of your own code in a nice high-level language, and 0.1% in a crufty low-level language, and you get good performance.

How much slower is it going to be in Javascript? Is it so slow that the average linux user is going to notice? If not, I think you're preoptimizing.

FYI, Java has a JS interpreter called Rhino and it lets you compile the JS into .class files for performance improvements. You can read about it here: http://www.mozilla.org/rhino/jsc.html Perhaps the same could happen with these linux applications.

Bringing new devs into GNOME, that's why.

[Anonymous Coward]

To put it bluntly: "Because a lot of people already know it."

The problem with attracting developers is that so many of them these days have went on to develop web applications with awful scripting languages like Javascript, Python, Perl and PHP. Developers know these languages.

Bringing developers to the platform is what's important right now. The libraries have gotten better and better, and now it's time to have some real, awesome applications to use them. Part of that means having developers that actually want to write applications, and that means somehow attracting back the people who ran off to write web applications. And what better way to do that then to allow them to use their existing knowledge?

Re:Bringing new devs into GNOME, that's why.

[Chabo]

I don't want a web programmer coding my GUI apps. I wouldn't be able to get Firefox to render correctly in Gnome unless I ran it inside IE!

Re:Bringing new devs into GNOME, that's why.

[element-o.p.]

Compatability issues between Firefox and IE are hardly Javascript's fault...

Re:Bringing new devs into GNOME, that's why.

[Anonymous Coward]

There is no browser, only XUL.

Re:Bringing new devs into GNOME, that's why.

[morgan_greywolf]

There is no browser, only XUL.

Correct. In other words, this has already existed for years. Most of Firefox's user interface is written in XUL (read: JavaScript + XML)

Re:Bringing new devs into GNOME, that's why.

[3dr]

The whole of JavaScript programming is NOT just web programming.

The javascript engine is an embeddable interpreter (that is independent of a web browser), and it is common to combine it with C++ guts. The web browser is just the most well-known example of this combination.

On many projects I export key data structures via SWIG into a scripting language, then use the scripting side to quickly develop and test new algorithms without the compile/link cycle. I've done this on numerous projects, with C++ scripted by TCL or Javascript, and C bits scripted by Python.

The C++ / Javascript combo is a common mix (no GUI other than terminal). For GUI, one of the oldest combos is Tcl/Tk (~1993), then there is Perl/Tk, Python/Tk, and Python/Wx. I personally like the Python/Wx the best.

It's quite fun to have an embedded script engine in your application -- especially for data processing engines where tweaking the exact algorithm helps determine behavior / heuristics.

Re:Bringing new devs into GNOME, that's why.

[Chabo]

Either I suck at humor, or you didn't pick it up. Either way, it was supposed to be funny; I don't blame IE/FF incompatibilities on Javascript. ;)

says who?

[Anonymous Coward]

Javascript is easy and useful. Perl and python have nothing to do with the functionality of javascript. Neither do .net or Java. What exactly are you talking about?

Re:says who?

[_merlin]

Like JavaScript, Perl and Python (and Ruby, TCL and even PHP, for that matter) are interpreted, object-oriented languages that you can quickly build simple applications with. However, they're all a lot nicer and cleaner than JavaScript (with the possible exception of PHP). JavaScript desktop applications are trying to solve a problem that's already solved in a superior way.

Re:says who?

[schon]

Please tell me you didn't just call Perl "nice" or "clean".

The fact that you believe Perl is "cleaner" than Javascript tells me that you are already a victim of Perl Syndrome, and should report immediately to your local sanitarium.

Re:says who?

[Anonymous Coward]

First of all, calling JavaScript, Perl, and PHP OO languages is quite a bit of a stretch. JavaScript is a Prototype language, for instance. The others have had OO tacked on (rather badly).

And Perl, Ruby, and PHP are nowhere near as 'clean' as JavaScript can be when done correctly (Crockford style).

I use at least two of these languages on a daily basis, and of that list, my preference would be Python followed then by JavaScript. The rest I could chuck forever and be quite content.

Re:says who?

[Chabo]

One of the lines in the book "Learning Perl":

"Yes, Perl has objects; it's buzzword compatible with all of those other languages."

Re:says who?

[Anonymous Coward]

Having objects does not make a language Object Oriented.

JavaScript has objects too, in fact everything in the language is an object. It's still not an OO language, though, as it doesn't (naturally) support all of the 'pillars.'

My statement still stands, Perl is a 'multi-paradigm' language that had objects hastily tacked on. (Perl 5, IIRC)

So, no, not an OOP language by design.

Re:says who?

[element-o.p.]

Meh. Just because there exists an obtuse way of doing things in Perl doesn't mean you *have* to do it that way.

I *like* Perl. I've used it since ~2001 and it's my "go to" (not "goto" -- that's obviously bad :) language of choice. However, despite the fact that I'm comfortable with things I've written in Perl doesn't mean I can always read someone else's code.

However, the same can be said of JavaScript and pretty much any other language I've ever used...with the possible exception of Python, which from my limited experience *always* looks clean, no matter who wrote the code.

Re:says who?

[jhoger]

Is English a clean language? Is it possible to write concise, expressive poetry in it?

The term "clean" only really applies to expression, not to languages. The capacity of expression in a language is much more a function of the speaker (programmer) than it is of the language itself.

Big yawn

[Brandybuck]

This is news? How is this news? Scripting applications with Javascript has been a feature of Qt for quite a while now.

Re:Big yawn

[Anonymous Coward]

but now it's becoming part of the superior desktop environment

Re:God no!

[sydneyfong]

Javascript is actually a nice and clean language.

The reason why it has a bad reputation is because of "web developers" writing generally horrible hacks with it. Nothing to do with the language.

Python?

[ndansmith]

The availability of a desktop-wide embeddable scripting language for application extension and plugin writing will enable users to add lots of rich new functionality to the environment.

Why not Python? Seems like many Gnome apps already have Python bindings.

Re:God no!

[pavon]

The main purpose of this project is to enable easy embedding of Javascript into a GNOME application for scripting purposes, on the basis that lots of people know javascript so it makes a good extension language. The fact that you can write entire applications with it is just a (disturbing) side-effect.

But if you really want to frighten yourself notice that these applications are run just like any scripting language in unix - with a shebang header line. So javascript init scripts are now yours to have.

Re:God no!

[ltmon]

The monstrosity of JavaScript/ECMAScript is more a function of the browser/DOM and not the language. If you get the chance to use some nice prototype-based OO Javascript away from the browser, you'll find that it's actually got a lot going for it.

It could sure do with a nice standard library though, there's a lot of roll-your-own low level functionality going on, which adds to it's reputation as a pig.

If happens: KDE here I come!

[Samschnooks]

Unlike many other scripting languages, JavaScript's standard library is very slim and doesn't come with very much additional infrastructure. Developers who build GTK+ applications with Seed will have to use other GObject-based libraries from the GNOME stack in order to produce full applications. For example, native file access and basic remote data retrieval can be done with the Gio library.

Scripts are pigs. They're good for little maintenance things or tools or whatever. Write a program, that I have to use, with it?! Oh God no!

Interpreted languages are just too slow and in some cases, too flaky for desktops or any other intense application - especially apps that have a UI. Can't stand them!

Re:If happens: KDE here I come!

[icebraining]

Toontown uses Python for everything except the actual 3D rendering, which is handled by Panda3D, and it runs pretty well and fast.

Re:If happens: KDE here I come!

[TD-Linux]

You're too late. Some KDE apps already support QtScript, which supports ECMAScript in applications.

Re:If happens: KDE here I come!

[ADRA]

You better start packing your bags since a large number of Gnome GUI applications are already being written in Python these days.

Re:If happens: KDE here I come!

[mpyne]

And even before QtScript there was KJSEmbed, which has mailing list archives dating back to 2003.

Of course TFA itself pointed out QtScript and how it is used by Amarok...

Re:If happens: KDE here I come!

[RiotingPacifist]

from what ive read of Kde4, they also already have JS for alot of the plasma widgets

Re:If happens: KDE here I come!

[shadwstalkr]

You're about five years behind the times, bud.

Re:If happens: KDE here I come!

[SanityInAnarchy]

Interpreted languages are just too slow

In some cases, "interpreted" languages outperform "compiled" languages.

In the more common case, if it takes a hundred cycles to perform an operation in C, and ten thousand cycles to perform the same operation in something else, it still took less than a millisecond. I don't know about you, but if a GUI app responds in a tenth of a second, it's fine.

Do you have any specific examples of interpreted programs that are "too slow"? Are you sure it's due to being interpreted?

in some cases, too flaky

Citation needed. Many systems that need to be much more reliable than desktops run in interpreted languages. You're posting on one right now, in fact -- not only is D2 written in JavaScript, but the Slashdot server code (Slashcode) is written in Perl!

Are you seriously telling me that what's fast enough to run Slashdot isn't fast enough for you?

But because there's less code to right, there's actually fewer bugs. There is, in fact, a study which shows that bugs per LOC is constant across languages -- therefore, if I can write the same program in 100 lines of Perl, Python, or Ruby, that might take 1000 lines or more of C, it probably has ten times fewer bugs.

If it runs ten times slower, but it's fast enough, I'll take that reliability any day.

Re:If happens: KDE here I come!

[arth1]

In the more common case, if it takes a hundred cycles to perform an operation in C, and ten thousand cycles to perform the same operation in something else, it still took less than a millisecond. I don't know about you, but if a GUI app responds in a tenth of a second, it's fine.

I don't know about you, but I have GUI code that's often called thousands of times per second. Presentation of text, for example. Or mapping an image onto the screen. Heck, even blitting your backing store and redrawing widgets when you move a window.

Re:If happens: KDE here I come!

[FooBarWidget]

Stuff like that, in other words all the core code, are and will still be written in C. Or did you somehow imagine that *everything* must be written in an interpreted language?

Besides, most *application-level* GUI code doesn't do things like that. They tell the widget toolkit "put a button with this label here" and "render this text with this font and this transformation there". They don't render stuff pixel-by-pixel. In these cases it doesn't matter what language you write this kind of code in, the performance loss will not be noticable.

Re:If happens: KDE here I come!

[Anonymous Coward]

I don't know about you, but if a GUI app responds in a tenth of a second, it's fine.

No it's not fine. You don't want it to take it half a minute or more to move a window from one side of the screen to another. (just start up xev(1) and count one second for handling every 10 MotionNotify events).

Re:If happens: KDE here I come!

[SanityInAnarchy]

Presentation of text, for example. Or mapping an image onto the screen. Heck, even blitting your backing store and redrawing widgets when you move a window.

I'm trying to imagine a GUI app where I should have to care about any of these things, rather than letting a GUI toolkit, or the windowing system, take care of it for you.

Granted, there are cases where it might matter. Most don't.

Consider that even if you're only binding to OpenGL, most scripting languages are fast enough to make a reasonable game -- which you would expect to be far more resource-intensive than a 2D GUI app. I would argue that, in most cases, if your 2D GUI app is taking more CPU than a 3D game, you're doing something wrong.

Re:If happens: KDE here I come!

[SanityInAnarchy]

You don't want it to take it half a minute or more to move a window from one side of the screen to another.

Nor do I want my GUI app to even have to think about moving itself from one side of the screen to another. That's between the window manager and X.

Been doing this for a while

[Anonymous Coward]

I actually have been doing this for a number of years and I have done commercial projects using it. I started with Lua but lately I have been using Javascript via Tracemonkey in an attempt to get more buy-in. Javascript looks good because of its widespread web use. Javascript is still a pretty crappy and convoluted language that will probably never be able to perform as well as Lua(JIT) though.

I use it for Windows apps as well. I have my own custom bindings for Win32, FLTK, Gtk+, and Qt. Qt is my favorite right now since they're making it LGPL.

Don't kid yourself though, it will not perform anywhere near as good as an old fashion C/C++ application. I still use C or C++ when I need top performance. A lot of applications don't need it though and the end-user can't tell (my scripted software runs fine even on old 266 Mhz laptops with 128 MB of RAM).

Re:Been doing this for a while

[david.given]

Javascript is still a pretty crappy and convoluted language that will probably never be able to perform as well as Lua(JIT) though.

Actually, the modern JITs like V8 and Tracemonkey are a whole lot better than they used to be; V8 actually approaches the speed of LuaJIT for some tasks.

Of course, V8 uses about two orders of magnitude more memory, and Mike Pall is currently working on LuaJIT 2 which will be faster and more lightweight, so it's very much damning with faint praise. But, while Javascript is still pretty awful, it's not nearly as awful as it used to be.

(I want to know why nobody's tried statically converting Javascript into Lua and running it that way. The languages are very similar, and all the differences favour Lua --- special cases in Javascript that can easily be handled in Lua. Given how fast and small Lua is, and how widespread Javascript is, I'd have thought that approach would be a good match. But there seems to be nothing...)

Re:Been doing this for a while

[gnud]

Why your own bindings for QT? I mean, there is already EMCA scripting in Qt4...

QtScript

[NekoXP]

Hasn't KDE had this feature since the dark ages? :D

Re:QtScript

[RiotingPacifist]

yeah but the gnome guys implement the same thing and the partially washed masses that use ubuntu suddenly get to play.

Re:QtScript

[ChunderDownunder]

Indeed, a quick Google search will reveal that Canonical's endorsement of python as one language to rule them all:

Ubuntu prefers the community to contribute work in Python. We develop our own tools and scripts in Python and it's much easier for us to integrate your work if you use the same platform.

cf. Apple & objective-c.

Re:why even use gnome?

[monkeythug]

More to the point - this sounds very similar to QTScript which has been available for more than 18 months (since QT 4.3)

Re:God no!

[Anonymous Coward]

I'd go for Lua. But then again, that's my answer to anything

I have a bad feeling about this

[erroneus]

What part of "Active Desktop" was a good idea? Why are we attempting to recreate that?

At the very least, I hope steps and measures are taken to ensure that there is NO code that can be hidden and that a complete console allowing the viewing and editing of all Javascript code complete with the ability for users to DISABLE it.

I can see where some things would be nice... and in fact, nicer because it was written in a scripting language rather than a compiled or interpreted binary. But there are some things I would rather not see "uncontrolled."

Re:I have a bad feeling about this

[natrius]

This is not similar to Active Desktop at all. Building applications with the JavaScript language does not mean that the browser will suddenly have access to all sorts of system functions.

Re:I have a bad feeling about this

[SanityInAnarchy]

What part of "Active Desktop" was a good idea? Why are we attempting to recreate that?

Seems more like Active Desktop was a bad implementation of a good idea. (For other examples, see UAC -- I use sudo, and I like it fine, but I can't stand UAC, which is the same idea.)

But this isn't even the same idea -- it is not about setting your desktop background to some website. It is about writing new applications in a different language.

At the very least, I hope steps and measures are taken to ensure that there is NO code that can be hidden and that a complete console allowing the viewing and editing of all Javascript code complete with the ability for users to DISABLE it.

...why? Do you expect the same thing from C or Python?

Because, as I understand it, that's all that's happening here -- you can develop a desktop application in JavaScript, just as you can in C, Python, Ruby, or whatever else.

Re:I have a bad feeling about this

[yolto]

The problem with Active Desktop wasn't the Javascript language, it was the mixing of the OS and the Browser and the security problems that came from that mixing. Javascript had nothing to do with it; in fact, many of the malware related to ActiveDesktop was written with VBScript, not JS.

The article is talking about using Javascript as a scripting language to help build GTK applications. This is no different than using any other scripting language, such as Perl or Python. Just because it's Javascript doesn't mean it has anything to do with a web browser or the DOM.

Re:I have a bad feeling about this

[DrXym]

Active desktop in its first incarnation (i.e. Windows 95-98 era) stank because it stank. If you looked at the code, it was a mess of VBScript, JavaScript and a whole crap load of random ActiveX controls strung together with really ugly code. That might have been forgivable if it all worked without a hitch, but it didn't. The implementation was unstable and meant that when one part went down, the whole lot went down. The user experience was generally awful too not helped by the hyper-link-like-icons and single-click-to-launch behaviour. Ironically KDE stole that behaviour and tainted itself in the process.

I don't see blaming JavaScript for that. JavaScript uses whatever bindings are exposed by the executable it runs against. They can be awful or elegant. JS is just the runtime glue sitting on top of a foundation which can either be solid or rotten. In itself JS is an extremely powerful scripting language.

Anyway, JavaScript is already used in modern desktops. Windows & OS X use JS to drive their respective Sidebar / Dashboard widgets technologies for example. And of course a browser (practically a permanent fixture on most people's desktops) uses JS extensively - most of the UI is XUL, XBL, CSS and JavaScript.

I don't see much technical issue with GNOME or GTK supporting JS as an extension language. Obviously there is a directional level issue of fighting bloat and kitchen sink syndrome. Different runtimes are going to bog down system performance and affect disk / memory footprints. The core applications in GNOME should be heading in the same direction and not tossing in a mix of Mono, Python, JS, tk, Java or whatever the hell else is floating around there. Keep things tight and trim. Open Office is an example of an application which has seriously lost the plot in that regard and its easy to see the consequences too.

Re:God no!

[fishbowl]

>Javascript is actually a nice and clean language.

It is. I avoided it for years, just because I utterly hate that it was called Javascript. But AJAX forced me to use it. A good programmer can do good things with the language. I refuse to get into what bad programmers can do.

Re:God no!

[Anonymous Coward]

Javascript lacks a clear way of enforcing interfaces. Any part of the program can extend or modify the prototype of any other object on the fly and wreak havoc by invalidating reasonable assumptions which other programmers had about that object. Javascript also lacks multithreading support (no way to synchronize in the language itself). Closures are nice if you know how to use them, but otherwise they are a serious memory leakage hazard. Last but not least there's the problem that Javascript is the VisualBasic of the web: Everybody and their mother pretends to know how to code with it. When real data is involved, it's definitely going to get ugly.

Re:God no!

[Anonymous Coward]

A good programmer can do good things with any language - That doesn't mean that the language itself is any better than the dung scraped from the bottom of a septic tank

Re:God no!

[larry bagina]

don't forget people who confuse DOM and Event compatibility with the javascript language.

Re:God no!

[andy19]

Why take the worst of the web and bring it to the desktop?

You must not have read the article. This is about JavaScript, not Flash.

Usual Gnome/GTK wheel reinvention

[TopSpin]

Gnome guys; don't consider extending or improving XUL. That javascript+gtk widgets model hasn't managed to produce anything worthwhile, now has it? Obviously, you can do it better! Probably 3-4 times over the next 15 years. Good luck!

Re:Usual Gnome/GTK wheel reinvention

[Anonymous Coward]

I wish I had mod points.

Re:Usual Gnome/GTK wheel reinvention

[caseih]

How would XUL help build and extend Gnome applications? It just doesn't apply here. We're not talking about building rich web-based applications like XUL is for. We're talking scripting and extending Gnome binary applications that are already based on a nice API. Embedding gecko in every gnome app is silly. Having a way of embedding Javascript, or Lua, or Python in an app, and allow such scripting languages to access the core objects of the app and extend functionality is a very appropriate and very necessary. You wouldn't suggest that WoW programmers use XUL would you? Yet they have embedded Lua.

I think you're being led astray by the article building a complete little app as a demonstration. In reality this is not likely to be the case. Instead you'd have the bulk of the app written in, say, C, C++ or Python, and then have seed embedded to allow plugins and little custom, end-user scripts written in Javascript.

For an example of how this is going to work, take a look at what Epiphany is doing. Their core code is written in C I think, but you can write plugins in Python or C, and soon Javascript. By plugins I mean quick and dirty little things create smart bookmarks (just an example), or modify the behaviour of aspect of the UI. For example, I wrote a 10-line python script to clear the google search box every time you submit it. Thanks to exposing their objects through python, I could locate the widget in question, attach a handler to it to trap the "activate" signal, and then after letting the normal handlers do their work, I simply told the widget to clear its contents. Other things you can do include add menu items and toolbar items, remove elements of the UI (think kiosk mode), etc. Sure this is a browser and sure you can use XUL (and javascript only) to do that to firefox. That's not the point. The point is think about doing this to any gnome-based app. One other very important thing that will happen (and KDE has had it for years) will be the ability to, through the introspection API, dynamically drive an application through scripts, even though they are gui apps. Javascript would lend itself well to this.

Re:Usual Gnome/GTK wheel reinvention

[Anonymous Coward]

The only problem with XUL is that it's completely inappropriate. It was designed to look like DHTML (or whatever you call it these days) to make a web browser UI in a way that leverages code for rendering DHTML. Mozilla is pretty excited about making a UI in XUL and binding Javascript to it, just like designing a UI in glade, which gets written out in XML, parsed by libglade, and usable in any language GNOME supports from C to python to, now, Javascript.

GTK+ is a far more complete desktop widget set, and that's only the UI of the Gnome desktop platform, so of course you want to use Gnome instead of Mozilla to make desktop applications instead of websites.

This is what the Gnome developers are famous for: reinventing the wheel, and doing it right, in a C library that you can use with any programming language.

Could this become as popular as AppleScript?

[strangeattraction]

I can't tell you how many user are just chomping at the bit waiting for this development.

Re:Could this become as popular as AppleScript?

[the eric conspiracy]

Not me. I HATE Javascript. It is a hideous programming language. Yeech.

Re:Could this become as popular as AppleScript?

[sigzero]

None?

Convoluted how?

[weston]

I'd actually say it's one of the cleaner of the C-syntax'd languages, and it's certainly less convoluted than, say, Perl....

Re:Convoluted how?

[Sancho]

Javascript gets a bad rap for a lot of reasons. Most notably is the fact that Javascript and the DOM are conflated in most people's minds, despite the fact that the DOM is not a part of the Javascript specifications--in fact, while Javascript can manipulate the DOM, it's the browser which provides the bindings. It's not Javascript causing the incompatibility, it's the browser. An analogue might be having incompatible implementations of libc--you wouldn't blame the C compiler for the problem, would you?

There's also a developer problem. People see the C-like syntax and start coding as they would in C. Javascript is functional language, and it makes use of that in significant ways. Worse, the expected semantics of block-level scope differ from C, and that's a very big gotcha for a new programmer.

That's not to say that Javascript is without problems. There are numerous quirks which I consider errors in the specification. Nonetheless, it's really quite an elegant language for the most part, and it's certainly possible to develop libraries to handle the quirky cases.

Re:Convoluted how?

[Anonymous Coward]

Javascript is functional language

That's a bit of a stretch. It has functional features, like many modern languages. That doesn't make it so special.

Re:Convoluted how?

[SCHecklerX]

I dunno. (it's been awhile since I've done any javascript, so forgive me if this has been fixed):

javascript uses the same operator for numeric addition and string concatenation. Pretty bad in a loosely-typed language, don't you think?

a=1
b=1
a+b could be either 11 or 2. Who knows? This one got me when it would always be the former. At least perl uses '.' for strings and '+' for numbers to figure out how to interpret what you're trying to do.

Re:Convoluted how?

[weston]

a=1
b=1
a+b could be either 11 or 2. Who knows?

If the type of either variable is a string, the result is a string. If both are numeric, then the result is numeric. In each case, the interpreter simply does what's required for the operation to make any sense. So:

a=1, b=1, a+b yields 2.
a='1', b=1, a+b yields 11.

The key here is that the variables are indeed typed, and you can run tests on them yielding type information:
a='1', typeof a yields string.
b=1, typeof b yields number.

Javascript is more dynamically typed than weakly typed.

Re:God no!

[ianare]

Too many exceptions and too vague. No reliable standard implementation.
Semicolons as line endings, for example - in C++/php/perl you need them always, in python you don't. In javascript, sometimes you need them, sometimes you don't.
I really tried to give JS a shot, but when you have the guy that created it saying this or that part of it is a hack, it kinda dims your confidence.
Many programmers I have met, myself included, will pick up php, python, even perl or C++ faster and easier than JS. And it was created for the web, so if web developers have a hard time with it, it kind of defeats the purpose, don't you think?

The problem is... GTK isn't portable !

[Anonymous Coward]

The problem with Javascript + GTK is that it isn't portable to other platforms, like Windows. At least that I am aware of. We shouldn't be writing applications that run on Linux alone. Its a multi platform world out there. I need to write a small application that runs on Linux, Windows and Mac. I was looking at Javascript and GTK just today. I also looked at Java + Swing and Java + SWT. I think I am going to end up using Python + Qt, although I think one can use Python with SWT or Swing via Jython. In any event while I applaud the use of Javascript, GTK is the last library I use, simply because of its portability.

Re:The problem is... GTK isn't portable !

[SanityInAnarchy]

The problem with Javascript + GTK is that it isn't portable to other platforms, like Windows. At least that I am aware of.

GTK+ is. Webkit certainly is (see Chrome -- webkit-based, Windows-only browser -- or Safari, which runs on Windows, OS X, the iPhone...) I can't confirm right now whether seed itself has been ported, but I see no reason why it wouldn't be.

Is Qt currently more portable? Maybe -- last I checked, Gimp, at least, was shipping with a GTK+ for OS X which required X11, while Qt has a native Mac GUI. But to say that either one "isn't portable to other platforms" is just willful ignorance.

Oh the Horror ...

[ianare]

The Horror.

Re:God no!

[Nerdfest]

Lack of type safety?

You-know-what.

[john.picard]

Someone should write a JavaScript interpreter in Python and then port Bochs to JavaScript so we can emulate a virtual machine's instruction set in an interpreted environment running inside an interpreted environment. Then install Linux with GNOME on a 386, run Windows 3.1 in this environment, and note how much faster it is than you-know-what, when you-know-what is running on the biggest, baddest, the shit, fastest box there is around.

Re:God no!

[Anonymous Coward]

Semicolons as line endings, for example - in C++/php/perl you need them always, in python you don't. In javascript, sometimes you need them, sometimes you don't.

So, as a best practice, you always use them.

Just as with HTML4, sometimes you need closing tags, sometimes you don't. So, best practice is to develop mostly XHTML which is backwards-compatible with HTML4 -- and thus, to always close your tags.

I really tried to give JS a shot, but when you have the guy that created it saying this or that part of it is a hack, it kinda dims your confidence.

That's actually true of many good languages, and of many good systems. Carmack's Reverse is a brilliant hack, for example.

Many programmers I have met, myself included, will pick up php, python, even perl or C++ faster and easier than JS.

Odd -- I learned JS before any of those except C++. It seems as easy as any of the above -- perhaps easier, because if you already know HTML, you already have a GUI to play with, and things like Firebug.

My experience has been that the basics of Javascript are very easy to learn -- much easier than C++, for instance. The more advanced stuff may be hard, but I would argue that it's not hard to know Javascript thoroughly, whereas it is very hard to know C++ thoroughly.

Do you have any specific examples you'd like to talk about?

Re:God no!

[SanityInAnarchy]

That's a feature, not a bug, certainly in a language designed for the Web.

Why the negative tags?

[Anonymous Coward]

I don't understand the "deargodno" and "deargodwhy" tags; forgive me if I'm having an epic sense of humour fail though! I use JavaScript to prototype stuff all the time; you can even use it for animation in the browser (I prototype games and simulations with it, mostly, but see Doug Crockford for more useful programs - the example that readily springs to mind is his symbol table based top down parser which appears in Beautful Code).

At the end of the day it's just another language, albeit one with a familiar (C-descendant) syntax, object orientation, first class functions and (as of 1.7) generators and iterators.

Note that Python (and I do love a bit of Python) supports lambdas but not closures, thus limiting the flexibility of anonymous functions in the language. Javascript in the browser does not support (currently in all implementations AFAIK) tail recursion optimization, although this does not preclude non-browser-sandbox based interpreters from supporting this feature.

Due to the prototype-based nature of its object orientation mechanism (as has already been mentioned) it also allows some interesting opportunities for experimenting with purely behavioural inheritance, something that is occasionally required but not really possible to achieve in any sane fashion in Java (for example; I'm a Java programmer for a living). I'm thinking along the lines of:

var self = this;
this.prototype.behaviour = function(){
BehaviouralObject.prototype.behaviour.call(self);
}

sort of thing. I appreciate this code may be unnecessarily verbose, but I think would illustrate my point at least. There's a lot more that I like about the language, but I feel I've probably gone on far too long by this point.

(Apologies for the AC; it was late, I was tired, and I can't remember whether I have a Slashdot account.)

Re:God no!

[SanityInAnarchy]

Javascript lacks a clear way of enforcing interfaces. Any part of the program can extend or modify the prototype of any other object on the fly...

Many of us would consider that a feature, not a bug. But, actually, you can enforce interfaces fairly easily with closures, if you really need them.

More importantly:

invalidating reasonable assumptions which other programmers had about that object.

If you're making assumptions you want others to be aware of, the right place to do so is in documentation. Otherwise, you've got the unsolvable problem of idiot-proofing your code -- they will always build a better idiot.

If people are deliberately breaking the rules you've laid out, you're going to have problems anyway. No language can actually enforce interfaces -- it's always possible for people to go edit that source (or the binary, if they have to), perform reflection (with or without a debugger), or just scribble all over your application's address space.

Javascript also lacks multithreading support (no way to synchronize in the language itself).

Threads are evil.

More relevantly, this actually isn't much of an issue for most real applications of Javascript. I'm sorry, but when was the last time an AJAX application needed to use more than two cores?

Closures are nice if you know how to use them, but otherwise they are a serious memory leakage hazard.

...so learn how to use them.

Citation needed on the memory leakage, also.

Everybody and their mother pretends to know how to code with it.

This is true regardless of language.

Any language can be used to write horrible code. Any language can be used to write decent code. The real question is, how much work does it take to write decent code in one language versus another?

Re:God no!

[Sancho]

This is a design choice. You're trading flexibility for correctness if you implement type checking.

Security risks

[bradbury]

Any individual who enables the untrusted execution of javascript on their computer is crazy (IMO). If the direction of development (Gnome, etc.) is in this direction it is similarly crazy. Unless Javascript is executing in a completely secure virtual machine (read a completely different VM, e.g. enabled by Xen, VMWare, etc.), anyone who uses it is vulnerable.

You have to make a critical distinction between programs that run on your machine (which is what Javascript is) and programs which draw on your display (which was what HTML was designed to do (back in the "early days")). Any program which runs on your machine is vulnerable to the security flaws of said program. In contrast a program which only directs your program to draw on the display can only mess up ones display.

There is a critical lack of distinction between these two circumstances. And if I would make a recommendation to the incoming presidential staff it would be that Javascript should be shut down on all governmental computers!

Re:Security risks

[ChrisXS]

Are you nuts? You obviously don't understand how this framework is designed. This isn't even about web apps. Where is there any hint that this will run untrusted? Since when does anything in Linux run untrusted? Silverlight for great justice?

Re:God no!

[SanityInAnarchy]

No, the way you measure that is how much effort it takes for a good programmer to do good things with it.

Re:God no!

[Aladrin]

"So javascript init scripts are now yours to have."

I actually screamed a little bit. -sigh-

Re:God no!

[Sancho]

Let's get pedantic for a bit.

You don't need semi-colons at the end of lines--you need them at the end of statements. And in Javascript, they're always required for the end of statements. What happens is that if the Javascript interpreter encounters an error condition in the parsing of the code, it will go in and see if adding a semi-colon would make the error go away. If so, it will automatically add the semi-colon for you.

This was a design decision that was implemented to make Javascript easier to use. It was also, by most accounts, a mistake. But then, when Javascript was created, I doubt that anyone ever expected huge libraries and programming tasks to be implemented with it.

Palm WebOS

[ChrisXS]

Isn't this the sort of thing Palm encouraging on their new Web OS SDK? Sadly, I do not believe there is a current option to write binary compiled code on that platform even if you wanted to. I'm happy with Maemo for now.

No it isn't.

[Anonymous Coward]

The javascript core mechanisms are fairly clean, but the language syntax is a horrible mess (but it would be, since they were mimicing C/C++/Java). There is also no need for constructors, or new() or for .. in (with all its caveats). In other words, it isn't that bad, but you really need quite a lot of extra code to make it work effectively and cleanly, and even then it remains mostly ugly to look at.

Google desktop already allows apps...

[Anonymous Coward]

to bewritten in javascript and run on the desktop...

Qt did it!

[scorp1us]

The Qt API has QtScript, an ECMA scripting engine. While by default Qt isn't fully scriptable, there is a "bindings generator" that makes the whole Qt API available to the scripting engine.

Re:God no!

[ianare]

True enough, and I have since gotten in the habit of always ending lines/statements with semicolons. But it's certainly confusing for no real advantage.

Re:God no!

[citizenr]

Javascript is actually a nice and clean language.

The reason why it has a bad reputation is because of "web developers" writing generally horrible hacks with it. Nothing to do with the language.

and now those "web developers" will write horrible hacks for Gnome

Re:God no!

[Anonymous Coward]

I really tried to give JS a shot, but when you have the guy that created it saying this or that part of it is a hack, it kinda dims your confidence.

Many programmers I have met, myself included, will pick up php, python, even perl or C++ faster and easier than JS. And it was created for the web, so if web developers have a hard time with it, it kind of defeats the purpose, don't you think?

There is nothing intrinsically difficult about Javascript. It is much simpler to understand than Perl for example. Since all the other languages you listed cannot be used to interact with the DOM on the client-side, I would guess that your difficulty actually was with picking up HTML DOM and event driven / multithreaded coding vs server-side page generation. No one would really argue against the former being harder than the latter, but that doesn't mean you shouldn't use it.

tl;dr PHP coders can't do multithreaded, have to let Apache sort it out for them.

No Sir, I don't think I like it

[nickdwaters]

I file this under the "Golly Gee Whiz" category. Just because you can do it, doesn't mean its a good idea. Why? Any truly demanding application must interact closer to the metal. What's next? An ECMAScript JIT native compiler with optimization for the next wave of CPUs? Why not just write an entire OS with ECMAScript. I just plain don't like it. Here is another reason. How do you demonstrate and establish trust with a site that delivers this type of script? If in the long run only certain authorities are distributing "trustworthy" code, then we may end up with another Microsoft style hegemony.

Re:God no!

[Anonymous Coward]

Besides, unless you're using a stone-age JavaScript interpreter (like Internet Explorer's), you can actually define the types of variables. It's optional though, and nowhere near as strict as most statically typed programming languages.

None of which should matter worth a damn for building GUI code.

And CSS too...

[TheModelEskimo]

Jakub Steiner has recently been wanting access to a CSS-type method of styling GTK apps rather than using the traditional widget-mangling stuff. I totally agree...in fact, look at some of the web apps out there that have already far eclipsed desktop applications in visual design, usability, and just overall experience.

If the desktop is going to make a comeback, things like this JavaScript effort and ideas that have their roots in web-team-on-a-deadline-style efficiency are going to have to be ported over to toolkits like GTK.

I guess Adobe Air and whatnot are trying to enter this arena, but I'd like to see other toolkits that are more widely used gain these capabilities.

BTW, I'm not talking about making every desktop app look different from another. I'm talking about coming up with a "look" to apply consistently - just one that actually looks good.

Re:And CSS too...

[IBBoard]

The problem with all of those web apps that have "already far eclipsed desktop applications in visual design, usability, and just overall experience" is that they haven't.

Install five GTK apps and what do you get? Generally it's five apps that look and behave fairly similarly. Go to five different web apps and what do you get? Five different looks, five different interaction methods, some using Ajax and some not, some using proper links and post-backs but some replacing every link with JavaScript so you can't middle-click.

Consistency is part of usability. Changing icon sets I can see the point of because some apps can't just pick up existing icons or they can't guarantee that there's a matching icon, so to get consistent icons you need icon sets. Anything beyond that in terms of styling (the oddities of Trillian's interface when I used it on Windows, the uglyness of Opera in Gnome no matter what theme, etc) breaks any level of consistency you might have had.

Re:And CSS too...

[TheModelEskimo]

So...what about my post said that the apps resulting from an easier way to tweak widgets would have to be inconsistent? For every five GTK apps that are wonderfully consistent, I can find you at least one stinker, one horrific mess up that should go back to the drawing board.

But so what? That doesn't say anything bad about GTK regardless. A toolkit is just a toolkit, and it can't enforce interface guidelines. The GNOME people have a good set of guidelines, and the only thing some new features would bring is the need to adjust guidelines to make sure they're up to date. In other words, no news here.

And I don't see you saying that because Trillian sucks, people shouldn't be allowed to use C++.

Or, because some choose to paint their house in garish colors, should we stop selling so many paints? No.We just establish reasonable guidelines for the neighborhood.

Anyway, back to Google Reader, which is far better than any RSS desktop client I've yet used...

Re:And CSS too...

[IBBoard]

Okay, maybe "breaks any level of consistency you might have had" was a bit too much. "tends to break any level of consistency you might have had" might be a bit more accurate.

You're right, it's not the toolkits per se, but if you give people a toolkit that lets them restyle anything (including anything that lets people put arbitrary imagery or even gradients in there) then you're bound to get otherwise good apps that are completely hideous or inconsistent.

I've got nothing against Google Reader and the like for what they are, but consistent is one thing they most certainly aren't.

Re:And CSS too...

[badkarmadayaccount]

It can't enforce interface guidelines? WTF? It's the thing that draws stuff on screen, right? It's the ONLY thing that can enforce interface guidelines. Reference: Cocoa API by Apple. Now don't get me wrong, I realize that some really convulted code can come up with a crappy GUI no matter the toolkit, but if it takes some serious conscious effort, then the toolkit designer has done his job well.

Re:And CSS too...

[Anonymous Coward]

So are you saying that Cocoa will keep me from violating Apple's interface guidelines? Interesting position. You should play around with a GUI design tool for a while and see the possibilities.
 
Regardless of how much "serious conscious effort" goes into *any* design related software, from Adobe Illustrator to 3DS Max to the Apple GUI tools, the user can create terrible work. I teach students who do that with these tools every day. Apple cannot decide where you can and cannot put a button. They can try, but a determined idiot can always get around that.

Re:And CSS too...

[badkarmadayaccount]

Keyword: 'determined'

Most idiots aren't like that, or at least most of them don't last long in programming. (Barring the ME team, of course.)

Think so, huh?

[Anonymous Coward]

"will enable users to add lots of rich new functionality"

That's why Linux still hasn't beaten Windows or Mac. You people have to stop this thinking that all computer users are nerds with no lives. Windows itself proves that no matter how crappy software is people will buy it if it just works.

Runtime options? I don't want no steenking runtime options.

Convoluted?

[Nicolas MONNET]

WTF are you talking about? There's nothing convoluted about it. It's quite simple & straightforward actually.
Did you know that much of the code of Firefox is already JavaScript?

Everybody knows some JavaScript

[Nicolas MONNET]

Much of Firefox is done in JS, and it works very well. But more specifically it has managed to spawn an extension ecosystem that they'd want to reproduce.

IMO this is missing just one thing, XUL.

JavaScript lacks a coffee grinder

[Nicolas MONNET]

Javascript lacks a clear way of enforcing interfaces. Any part of the program can extend or modify the prototype of any other object on the fly and wreak havoc by invalidating reasonable assumptions which other programmers had about that object.

There's a reason it's called "JavaScript" and not just "Java", you know ...

Re:JavaScript lacks a coffee grinder

[Anonymous Coward]

Would that be the same reason why it shouldn't be used as a language for whole applications?

Imagine if they wrote FIREFOX in it

[Nicolas MONNET]

Oh wait ... they did!

Ignoramus ...

Tool Control Language

[jmorris42]

[sarcasm]
Oh I dunno. Showhorning JavaScript into everything because... well because why exactly? That the Gnomes are doing it somehow doesn't suprise me in the least. Nothing invented in the UNIX world has ever interested those guys in the slightest.

Sounds like we need a new language just for this, ya know, a language optimised to be a scripting language to easily embed into other programs and thus avoid reinventing the wheel over and over.
[/sarcasm]

Gnome's reply

[garphik]

Is this OSS's reply to Windows XAML? This could be a nice alternative.

Dear Gnome

[stoicio]

Dear Gnome project. I am a long term linux user and
also a long term gnome user.

Let me make this perfectly clear. If you script things on my desktop
with either javascript or scheme I will wipe my hard disk and install
Microsoft Windows.

Ps.

I program in both scheme and javascript.

PPs.
You're morons.

JavaScript will stick over Vala or C

[icepick72]

JavaScript could be used as high-level glue for user interface manipulation and rapid prototyping while Vala or C are used for performance-sensitive tasks.'"

What performance-sensitive tasks require Vala or C? Existing performance-sensitive apps already have a web/JavaScript front-end like bank transactions, number crunchers, stock trades, complex domain logic for any businesses -- and all in a multi-user environment, I don't think Vala or C needs to be implemented to achieve performance in most scenarios when it exists in the front end. It's what's at the back-end that counts like locking and synchronization, concurrency checks, thread management, etc. Unless the application is for the buzzers on Jeopardy or a fighter pilot joystick, I think most developers will be able to leave the JavaScript "prototype" as is ... just like with web apps.

Re:why even use gnome?

[timmarhy]

yeah right i mention kde and the gnome zealots mod me flamebait.

Already possilbe with Appcelerator: Titanium

[TrumpetX]

http://titaniumapp.com/

This goes further than just Javascript apps, this combines CSS, HTML, etc for use in building desktop applications for Linux (coming soon), Win32 and MacOSX

Re:God no!

[H0p313ss]

I refuse to get into what bad programmers can do.

To be fair, bad programmers can write crap in any language.

eval(function(p,a,c,k,e,d){...})

[tepples]

Since javascript is interpreted code and you need the source to actually run it.

Copyright licenses used for computer programs tend to define "source code" as the preferred form of a work for making modifications. Interpreted code need not be source code; just look at any function that has been p,a,c,k,e,d.

Re:God no!

[zobier]

They're already writing extensions to Firefox and I like Firefox extensions enough that I won't consider using another browser for my primary use.

Re:God no!

[The End Of Days]

Bad programming is not a function of the language or platform used, and believing otherwise is indicative of prejudice, not intelligence.

Some people are missing the point

[Xabraxas]

Embedded scripting isn't anything new even in the GNOME environment. Scheme is the scripting interface generally available for GNOME applications. This development just allows javascript to be embedded in applications. I think this is a good thing. First, javascript is a very good language. Most problems people associate with javascript have to do with the browser and NOT javascript. Second, javascript is known by a lot more people than scheme. It's probably the most well known and used scripting languages in existance. Combine that with the fact that we now have three high performance javascript implementations that are still improving and I think you have a pretty good case for javascript on the desktop. This will only make extending GNOME applications easier. I think GNOME is in good hands if development focuses on Vala/Javascript application programming.

Re:Some people are missing the point

[jonaskoelker]

It's probably the most well known and used scripting languages in existance.

It's probably the most well known scripting language.

Whether it's the most well used scripting language is an open question.

</snark>

Uh.

[Anonymous Coward]

See Boost::Python. You just need to know what the hell you're doing in order to bridge C++ and Python properly.

Re:God no!

[jonaskoelker]

The fact that you can write entire applications with it is just a (disturbing) side-effect.

This is what I've been saying all along. Side-effects are bad. Switch to a functional programming language, such as javascript, today.

Uhh... what were we talking about again? ;)

Isn't this idea was for years around?

[hotfireball]

Folks, isn't this idea was for years around? It is called Rhino (http://www.mozilla.org/rhino/) and it is a JavaScript for Java... As a developer, I am quite pretty puzzled why would someone use this Gnome-only thing, instead to use same approach, yet to do cross-platform stuff?

Yes, I know about GTK is sort of ported everywhere, but I'd prefer Java Swing instead, since it is much better acquires native look and feel. For example, GTK for Mac requires X11 and is like an alien. Even alpha-fragile-sort-of-native-for-mac GTK that does not requires X11 and even has menu on top, still looks different and behaves different (means, no good).

Interesting to hear your opinion here...

SpiderMonkey Progresses

[caspy7]

It's worth noting that Gjs may not be running with SpiderMonkey's most recent performance improvements.
There have been continued improvements on the engine in recent times as engineers analyze ways for JIT compiling to make the code execution faster.

Re:God no!

[IBBoard]

The reason why it has a bad reputation is because of "people-who-call-themselves-web-developers-who-don't-really-know-what-they're-doing" writing generally horrible hacks with it.

There, fixed that for you.

(I was going to say "graphics designers who became 'developers'", but there are probably some of those who actually do a good job)

Sash for windows did this in 1999

[Anonymous Coward]

IBM project that was available for public download IIRC. The idea was to allow the rush of new website developers to produce desktop apps with their existing skillset.

If this is going to be capable of running any of the web2.0 frameworks and associated junk then the same premise applies.

Don't know why sash didn't take off, might be worth looking into if any of the dev team care why an identical past project didn't get sufficient uptake.

Ever looked at Firefox's source?

[Nicolas MONNET]

You might be in for a little surprise.

OMG, no!

[TheDarkMaster]

Dear God, PLEASE, do no let a interpreted language, full of bugs, full of inconsistences, to use into a DESKTOP, LOCAL application. I do not like the need to use 20~60MB of RAM to use a simple calc program.

jsext: C + javascript - glue code

[sveinb]

This is good news, since JavaScript is a good language. I've been working on a pet project for a while, which could perhaps be combined with this, to simplify the inclusion of snippets of C code where performance is an issue. Have a look at http://jsext.sourceforge.net/Including%20C%20functions.html

Re:jsext: C + javascript - glue code

[multipartmixed]

Interestingly enough, I was just looking at your work last night.

What would be *really* nice is if you, me, these GNOME guys, whitebeam, jslibs, and other folks could come up with a standardized way of sharing JS classes and objects at the source code level.

(I have done some work in this regard, and will be trying to pull your JSEXT1 object in this week)

Re:God no!

[oliderid]

yes and it lacks strong type, static, abstract Or quite useful things like enum.

You need to hack and to reinvent the wheel to achieve what is merely a line of code in any decent object oriented language.

JavaScript is a great language but I prefer to use it inside its eco-system: the web.

Nice idea, but. . .

[Anonymous Coward]

OK, having read through the article, it looks remarkably like what ARexx did on the Amiga.

This was a good idea then, and it's still a good idea now, my only concern with this is the implementation:

Another interesting bit that you might have noticed is that the program uses "forEach" in one case and "foreach" in another. This is because JavaScript's array object uses forEach but GTK+ container objects use foreach. It's kind of tricky and you have to be really mindful of those subtle differences in API conventions.

+1 on the idea, -1 on implementation

[Anonymous Coward]

I like javascript and I would use it to write Gtk apps. The problem I have is that Tamarin, SquirrelFish and V8 are written in C++ when there's plenty of alternative embeddable VM's (lua, nekovm... parrot) in C that would be a better match for Gtk / Gnome.

The better solution would be a javascript compiler with a small runtime, something like Genie. ECMAScript 4 would have made that easier but even now it's a possible and perhaps preferable solution. A register based VM and tracing JIT, written in Vala/C wouldn't be beyond the bounds of reason either.

Scriptable automation and plugins

[the_arrow]

I didn't read the whole article, but after the first paragraph on Shuttleworths keynote presentation all I could think was "He's talking about ARexx."
It's a version of REXX made for the Amiga for things just like scripts, automation, plugins and to act as a glue between applications.

You misspelled Tcl/Tk

[argent]

In some ways, it's an evolution of the strategy that was pioneered long ago by GNU with embedded Scheme.

Guile was developed as a deliberate response to the early success of Tcl and Tk as an embeddable desktop application language.

Crediting Guile as a "pioneer" is, well, odd.

What you oppose?

[Frozen Void]

Another language which is in widespread use gets (specific) linux support. Why you complain?
Is linux suppose to be scripted via "pure" languages only? No alternatives?

snake on the plane

[sluuuurp]

Why not Python?????

Re:Convoluted how? -- libraries

[maraist]

I would argue that the two reasons to choose a language these days are A) Syntax B) Libraries. If the syntax frustrates you, is bloated, makes it difficult to write large apps (VB, COBOL, XML-languages, etc), you'll demonize it. However, even if you have a clean syntax, if there are insufficient libraries (that are practically trusted across different platforms), then you can't do much more then trivial hello-world apps, or bind tightly to a handful of platforms.

The fact that you can't reliably say, I'm at least version X, and thus I can make use of this suite of features is extremely disappointing in this day and age.. The XML processing library (which is a large part of data-exchange these days, like it or not), the insecurity of using the much cleaner data-exchange format of JSON. The nightmare that is the javascript event model (elegant on a handful of browsers, but nearly impractical in the open-wild).

Argue all you want about how the 'language' transcends these web-centric features - how do you initialize an app? How do you chain-load 'includes', how do you perform IPC, how do you push data-streams into and out of the VM, how do you access files, how do you handle threading (inside or outside the VM), how do you deal with syntax errors (abort, roll back before processing the new script, or skip the lines that failed - possibly to the end of the file (like browsers do)), how do you deal with unicode, how do you deal with date formating (yes there are some primitive routines build in), how do you deal with regular expressions (there is a built-in routine but it has browser differences - which one do you choose).

Ignoring the fact that the stock toolkit is a mixed bread mutt, is like handing off C with no reliable standard header files.. fopen works differently on different UNICIES.. shudder...

That being said, I think javascript is more than adequate for a given plugin.. I use grovy, beanshell,velocity for simple DB-stored/dynamically-modified scripts; no reason to not use javscript there as well.. But these scripting languages are assumed to be relearned from scratch every time they're put into use, because different microversions might have dramatically different ways of interfacing with them. More importantly, your container treats the script like a leperous child.. You carefully massage it's context both before and after execution (fearing memory leaks). It's easier to inject objects with callbacks into the native language than to trust most of it's built-in data processing capabilities.. God help us if they treat dates or matching expressions in an unexpected way. Easier to code something complex into a 'helper' object.

As for most known language 'javascript', I would argue that most people (myself included) do 90% of their javascript coding in copy/paste mode, or have only deeply memorized/internalized trivial onEvent='return myfunc();' where myfunc may be a thin wrapper around someone else's library. So I would hardly say there's a large 'expert' javascript community.

Javascript has a good C/Java base syntax, morphed into dynamic scripting. Has some more modern foreach syntax, but it would be nice to incorporate some ruby concepts.

My main point is that you can't really transfer javascript programming knowledge from the web over to system-programming. You're pretty much starting from scratch. So Javascript doesn't provide any advantage over other existing scripting languages.

Java?

[drolli]

WTF. If i accept the disadvantages of a scripting implementation, how about something java based? There are jython, groovy and jruby.

Missed the point?

[pjr.cc]

I think alot of people have missed the point as to what seed is trying to achieve.

Consider firefox addon's as a good example of what seed is trying to accomplish.

Having done "addon" functionality in a number of places its actually quite a limiting experience, people mention perl, php, c++ and c while talking about bindings... sorry, your missing the purpose. Perl is very bad as an language devoted to creating addon's as is php, while c++ and c are completely out (unless you want to write a c++ or c runtime interpreter... no? well, it has been done, but thats beside the point).

One of the tricky things with righting "addon" features is passing data to and from while retaining control in the original program. Now, you can write something in C and execute perl from there, but you cant easily pass between the two as you would with addon's. C++ and C (compiled to a shared object) it is highly possible, but obviously very limiting. Same with php, you can execute php from within an application (as apache does), but not pass data between the two in a meaningful way. The point is, dont confuse language bindings (i.e. the ability to "create" a gtk gui from perl, pyhthon, php, and the rest) with the ability to embed the language.

The second thing is, people talk about "well, if its JS, it'll have to be opensource!". Again wrong, there are quite a number of things out there (though crackable) that allow you to protect php, perl, python, etc from being "read" (be they byte-code compilers or whatever). I cant see that being such a big problem for JS either.

Personally, I would love to see a more generic approach in the form of "extend mysql functionality with JS plugins" and so forth (insert any application - server or gui or whatever), which i dont see seed being capable of providing.

Re:Convoluted how? -- libraries

[aztracker1]

I'm not sure how much I agree with many parts of your post. I would say that JS does have a lot of quirks, but many of the enhancements to, for example, Spidermonkey 1.6+, the language gets pretty compelling. It's already used in a number of desktop gadget/widget systems already. The language version in Flash is similar. There are some differences, and you are correct that a lot of the code is around wrapper libraries. But, I would expect the same to be true for a JavaScript implementation geared towards desktop use as well. People don't write raw X11 calls, they use SDL, GTK+, Qt etc. There's nothing wrong with that. I for one, very much welcome this option. When I first started playing with .Net, it was with JScript, though I quickly switched to C# as the documentation for JS in .Net was severely lacking.

I just hope that it is well implemented, and well supported. I think that C# (mono) resolves a lot of issues with certain types of development, especially custom/enterprise applications on gnome. I find that Python + GTK works pretty well, but a lot of people don't like Python, or know it. I think giving another functional environment like JavaScript can only be a boon. I just fear the hundreds of crappy applets that will likely come out in place of the few gems, which is the case with Konfabulator (Yahoo Widgets), and with the Windows sidebar/gadgets, and other JS based widget engines. I already use a few applications that JS is the scripting engine, and have played with widget engines, so this will be interesting to me.

Inheritance and Overloading Overhead in C++

[hdon]

As for "extreme speed", C++ will almost always be at least slightly slower than C, if nothing else because of data being copied whenever there's an inheritance or overloading

Neither inheritance nor overloading adds more data copying. What are you talking about? C++ function overloading is accomplished by transforming function identifiers to incorporate their argument signatures, thus making two functions with apparently the same name but different arguments actually have unique names. There is no runtime difference at all. Inheritance doesn't involve extra copying either. Are you just making this stuff up? Another poster totally debunked your cache issue, too.

Javascript: A *Good* Language

[hdon]

But javascript is an awfully convoluted language. Why does it become easy when you put a language like that into the equation?

To put it bluntly: "Because a lot of people already know it." ... The problem with attracting developers is that so many of them these days have went on to develop web applications with awful scripting languages like Javascript...

You know what I don't think this is accurate at all. Javascript is actually a very elegant language, what is convoluted is the "web" platform.

XUL

[hdon]

XUL applications are, in my experience, a lot slower than PyGTK apps running on CPython. Spidermonkey has come a long way, but XUL GUIs are *still* quite a lot slower than PyGTK GUIs. I've been excited about Seed for quite a while, but I hope they'll consider using Spidermonkey. If not, I just might have to create my own GTK+ bindings for it...

Qt did it! Qt did it!

[scorp1us]

Not only does Qt already do JS

But Qt also uses CSS for widget styling.

C/C++ code annotation is the most important part

[bensch128]

I see that GObject annotation is done through comment formatting.
This seems a bit weird to me because I've always felt that comments shouldn't mean anything.
Eg. You should be able to obfuscate the code (strip all of the comments and change the function/method/class/variable names) and it should still work the same.

Qt's system of using macros to provide annotation seems a lot more sane to me.
It's also more similar to how Java and C# annotations work.

Cheers
Ben

sigh...

[jonasj]

This is about building GNOME applications with JavaScript, and GNOME runs on many different platforms, of which Linux is one, so why in the world is the headline Building Linux Applications With JavaScript?

Oh, kdawson. Explains it.

Re:God no!

[badkarmadayaccount]

With the possible exception of Ada. I'd kill for some crappy code in Ada. ;)