Reitter: Answering the question: "How do I develop an app for GNOME?"

Please don't troll.

When you say "since otherwise it is a poor language" you are just injecting your own opinion. As was explicitly stated, every language has its issues, and anyone can grandstand that their pet peeve issue is the most important one.

There can be endless debate over which language is better. It's never going to end. And you certainly aren't doing yourself any favor by just throwing out unsubstantiated opinions.

The stated intention was to pick a language with traction that they could stick with, one that is already familiar to people and doesn't need a sales pitch or a learning curve, not pick an obscure upstart "perfect" language that dies on the vine.

That has been tried and while HTML+JS makes for a good rapid app development environment, especially when the back end of the app is a remote service, for more complex local apps developers and users prefer a native widget toolkit. HTML is a little clunky, native widgets have more rich interfaces, lower latency and better integration with system services.

> I mean, the only reason to adopt JavaScript is that it is popular due to the web, since it is otherwise a poor language

Rubbish! JavaScript suffers from a few questionable design decisions, but it's surprisingly good considering the speed at which it was created. It's delightfully eclectic, with its non-constructor based objects. And it has anonymous functions and closures, so it's a little bit lispy too.

I think a lot of people who pan JavaScript are really criticizing the HTML DOM (or the web browser application development environment (which is a lot better than it used to be)) without realizing it.

Because by the time you finish writing your QT5 program they will be on QT7 and you will have to rewrite it from scratch again using Ruby or some such thing.

Why bother ask such a question?

It's curious that both Qt and Gnome decided that JavaScript is the way to go. I wonder who influenced whom. Qt 5 was out first, but the Gnome project has been talking about this since 2009, if memory serves.

The decision was made during the GNOME developer experience hackfest. I'm pretty sure that this was documented. During the hackfest people committed to making things happen, plus they actually did a lot of work.

So it was not made in a meeting, everyone who wanted to join could've, the hackfest was pretty widely announced, you could get sponsored to go to the hackfest, people with intimate knowledge about various languages attended (incl Python for instance).

Seems you like Python. Cool. You might want to read Planet GNOME. For instance this blog post by one of the people who worked on the Python bindings: http://www.j5live.com/2013/02/04/gnome-and-languages/

The people that supported the Gnome bindings for various languages will continue to support them as they see fit. Nothing has changed. People programming 'system libraries' (ie: anything meant to be used by multiple programs) will want to continue to program in C.

They really want to make one a first class 'this is what you use' language for Gnome so they can concentrate on improving the stuff that matters... development tools, test cases, documentation, etc etc.

Javascript is just about the most commonly used and understood programming language on Earth right now. GJS is based on SeaMonkey so that it's fast, well supported, mature, and modern garbage collected language, and other happy stuff. Apparently the bindings are good even though it's relatively new for Gnome. Makes sense to pick it despite the natural snobbery you see from language lawyers you'd expect to see. :P

"dynamic languages make lazy programmers"

They also make programs that are easier to maintain by other developers because they are not overburdened with type information that is either redundant or irrelevant.

Have you ever worked in QA? Do you know where bugs come from? Many many bugs come from statically typed languages when square pegs are pushed into round holes by implied casts. You can say "experienced developers should not fall for this" but the simple fact is that even the most experienced developers create far more bugs per LOC in static languages than they do in dynamic ones.

I feel your pain and of course I would like to set up some Inquisition where programmers are tortured until they carefully handle and document every error case and return condition in every line of their program. However, I think you are being unfair in attributing this to dynamic languages. There is a huge amount of C code which doesn't handle error cases well, resulting in your application going kaboom when using network shares and so on. C++ and Java give you a richer toolset for handling error conditions but they still can't force programmers to use it sanely; and again, there is plenty of code in those languages with terrible error handling.

Kids these days, huh?

Amen. Javascript is a great language if you:

1) Hate doing math with anything other than floats, that can overflow or truncate silently. Even though everything is an object, why would we want a numeric tower in the first place?

2) Hate modularity. Luckily in one of his responses the Gnome dev said that they are targeting apps the same size as you might find on your smartphone.

3) Related to 2, apparently enjoy the idea of using apps that are small due to screen and power constraints as your model for desktop apps. Angry Birds Gnome here we come, LibreOffice get lost. Why should any app be greater than 10,000 LOC? Luckily with javascript you'll have a hard time getting there anyway.

4) Hate using a language that allows a program to pay for only what it needs. Tree-shaking is impossible so even if you aren't using it, you'll bring it along anyway. Luckily you can minimize and gzip your libraries just like in web development! Also, this way you can spend your development time deciding if the convenience function you want to add provides more utility than it costs in library size and start-up time. What else are you going to spend your time doing?

5) Hate apps that start-up quickly. Luckily in Javascript you have to parse and run the code that creates your structures and functions, because Javascript mutates your environment state as you parse it! Declarative definitions be-gone! This is also super helpful if you hate the ability to provide tooling for your environment, because you only know what code does once you run it with the full state of the program and run-time behind it!

6) Hate sensible lexical scope. No big deal, it's only been 50+ years since Algol introduced it, why would we need it in 2013? For loops should always be confusing to deal with.

7) Hate languages that are responsive to user complaints. Javascript has managed to go ~13 years since it had any substantive changes made to it, and the committee is working as hard as it can to ignore user input for at least another year or two. Luckily, even if they are forced to put out a new standard, it will still be years before you can expect widespread adoption. If I play my cards right I can probably go another decade before being able to count on ints and lexical scoping.

In summary, this seems to be another attempt by Gnome to chase after the mythical "mainstream" although this time it's mainstream developers they're chasing and not users. I can't see any sort of technical grounds on which this decision could have been made, so it must be another popularity contest that the Gnome devs have decided to wade into. I wish them luck, and I can't wait for the hundreds of todo apps, and pomodoro timers this decision will surely lead to.

Not yet, AFAIK. That's what they are supposed to be doing from now on. We can only hope that they dog-feed themselves, and try to develop the development tools in JS.

gnome-shell (ins't really an application in the classical sense). gnome-documents would be the other one.

>What level of language compatibility can be expected? JavaScript is a dangerous minefield of incompatible implementations.

I've only really come across complaint from people talking about the DOM, not the language itself.

Are there deeper implementation incompatibilities that I'm not aware of?

var object = {
  attr1: 'cheese',
  attr2: 'runny',
}

With a name like *that*, I think we can say this is obviously a trurl account.

(sorry sorry the devil made me say it, and if you don't get it google either Trurl or Klapaucius...)