How do people decide what language, platform, engine, etc. to use these days? It's articles like this that make me want to give up tech and start working as a musician or artist.
You're stuck in the echo-chamber. I tweeted[1] two ideas earlier that you might find relevant:
"developers need a driving principle, a prime directive: to serve, and enable human creativity, to make tools for domain specialists"
Take a step back and be the computing ambassador for a neglected community. If I had the time, I would pen an open letter to all university professors and TAs asking them to tell us about any unsupported software they still use. There is a bucket-load of DOS and Unix software that is no longer maintained, but heavily depended on by academics, researchers, and small businesses. I wish I had the time to port those stuff to modern machines, or at least organize CS department students to write them. There needs to be more cooperation between CS and other departments, specially humanities. We can be their tool-smiths, and they would happily give us insights into other fields of study and other industries.
The other tweet is more juvenile, but you will appreciate the sentiment:
"Programmers will never have the luxury of collaborating with their idols, or pay homage to them like artists do. Programming != art :-("
P.S. If you just want to escape computing and take a few weeks off, get yourself a book called "Musimathics" and meditate ..
But is there money in that market? My previous (limited) experience with the academic work showed that there is hardly any money to be made. At least not enough to live off.
As far as getting insights goes, the academics that I worked with had no idea about the industry or even how it works. So any insight coming from them is one better ignored.
There is absolutely no money, but it also costs very little to eye-ball an ancient app, and write a spec for it for ungrads to implement.
The universities usually have all the technical know-how they need to sustain themselves, they just need to talk amongst themselves (department to department, campus to campus, or uni to uni.) If CS students were told to make software for other departments; architecture students were told to design study halls, stages and learning areas; art students were told to beautify school buildings, hold performances, educate, entertain, enlighten, etc. All the university would need is just someone to facilitate the interactions, introduce people to each other, and the rest can be done via Redmine or Basecamp.
Some of the projects are insanely interesting. In Australia, I was offered a non-pay gig to work with sensors in the field, traveling to beautiful beach areas and hacking x86 assembly. Universities can afford room and board, but not much else, sadly.
"Programmers will never have the luxury of collaborating with their idols, or pay homage to them like artists do. Programming != art"
Copying == art? Then I know a few very, very artistic Java programmers. They even pay homage to their own packages. (Which, excuse the pun, might even qualify them for "rock star programmer" status)
> Programmers will never have the luxury of collaborating with their idols
I have to strongly disagree with that. Collaboration is different among programmers as we can share our ideas with a much broader audience than most musicians. Many tools you use are the result of the collaboration of thousands of people. To say nobody is collaborating with their idols is a risky supposition.
The only part I agree is that Java (or C#) programming may be art, but not to my taste.
Given all the different instruments - and all the many types and varieties of each instrument - how could you possibly decide which to learn and play? Not to mention all the different styles of music!
How does that work when you decide for the tools to use in a teamproject?
Technical choices should always be rational based on a wide set of criteria. One of them is surely existing knowledge of the team, but not the only one.
Several paragraphs in the article read like they were written by a 2nd grader:
"Conversely, Adobe AIR and Silverlight allow Web-style applications to run on the desktop. Android, Adobe AIR, Google Chrome, Safari, and iPhone all use WebKit for rendering. One problem with GWT is that it does not allow you to write applications that run as desktop applications (even though GWT's development toolset for rendering is based on WebKit)."
And:
"When you're ready to deploy your application to the Web, you need to be a bit more careful about what library you include. It is common to use JavaScript Object Notation (JSON)-RPC services from a Pyjamas application running in the browser."
I'd give a blog post a pass, but this is a web property that I assume has an editor and pays authors for their submissions.
Also, pyjamas confuses me because two of GWT's rationales for existence are:
1. Using static analysis of your code to heavily optimize the resulting Javascript.
2. Using static language tools (Eclipse, etc.) to maintain order in large codebases
For 1), at Java->Javascript compile time, GWT will inline code, prune dead code, make calls un-polymorphic, and other fancy optimizations driven by the static typing. The goal is to make your Javascript as fast, or likely faster, than it'd be if written by hand.
Similar optimizations can be done these days at runtime by good VMs, e.g. the JVM and V8 (probably?), but the point with GWT is that crappy browsers (IE6-8) don't optimize at runtime, so GWT helps them out and does it at compile time.
For 2), whether or not you buy the assertion that IDEs/static typing make larger codebases easier to maintain, that is nonetheless the GWT team's assertion and something people using GWT generally agree with.
So, if you forgo static typing, and so give up static analysis, and a static tool chain/IDE, why are you not just using Javascript itself?
The sound is the only thing that wasn't written completely in Python. It's flash, and it also seems to have broken in my browser since the last time I loaded it. The rest of it still works fine.
I've been building GWT projects like http://beste.st/ entirely in Java, so I can share models between my client side code and server side code.
While this way of working is elegant and very powerful, especially when you have lots of shared state and complex server-client interactions, writing everything in Java is quite frankly, a bit of a pain.
This might be a great excuse to finally stop using Java for these sorts of applications and switch to Python.
GWT in Scala has made some good progress recently, with parts of the GWT Showcase successfully ported. Unfortunately, the primary developer behind the project is returning to academia, and will have limited time.
Hopefully Google GWT devs can get behind this initiative and make Scala a first class citizen. GWT has gone from being a Java to JavaScript compiler and widget set, to a genuine app framework with the 2.1 release. Having Scala as an alternative to Java would go a long way towards attracting new developers to the Google platform.
In the future, other JVM language may acquire JRibble backends which would theoretically allow you to write GWT apps in any JVM language. Personally I'm very excited about the prospect of one day writing my GWT apps in JRuby or even Clojure!
Though that'd also require someone coming along and building a great IDE for stab.
As far as writing Javascript apps in JRuby/Clojure via GWT...why use GWT? It's so heavily focused on Java/static type analysis, I'd think you'd be able to make a better/easier Ruby->Javascript translation by just starting anew.
The JRuby runtime itself uses reflection/some-day-invokedynamic to shoehorn a dynamic language into a static VM. Besides the fact the JRuby runtime would never get through GWT's no-reflection/nothing-fancy compiler, you're going from ruby dynamic semantics -> Java static semantics -> Javascript dynamic semantics.
Seems simpler to skip the static part. Some sort of Ruby's meta class semantics implemented via Javascript's prototype semantics.
I imagine the same thing applies with clojure, but I don't know as much about it.
As far as I can tell, the advantages of using a RIA (rich internet application) toolkit are:
* easier to develop desktop-like web applications
* more straightforward to avoid duplicating client-side and server-side logic
and the disadvantages are
* your page tends to load significantly slower
* your page isn't accessible to people browsing without javascript or disabled folks
* you'll still have to generate html for googlebot, etc.
Things I'm not sure about:
* difference in development time
* whether it's equally easy to integrate real-time functionality when you're using a RIA toolkit
What did I miss?
(other examples of RIA toolkits are http://www.sproutcore.com/ and http://cappuccino.org/. SproutCore is notable for supporting mobile devices unusually well, so I guess that might be a point in its favor?)
* page loads are slower: in a web 2.0 app they're also a one-off, and if you want to you can do dynamic loading of modules. it's not that bad, due to HTTP GZ compression.
* pyjamas-web is an experiment to do pure-html, executing the exact same python pyjamas app SERVER-SIDE. disabled folk: wrong. look at GWT accessibility.
* googlebot: not entiiirely correct. look up the (rather stupid "!" referral system that google "invented") - and again, look up "pyjamas-web" experiment.
I wrote a JSON-RPC controller base class a while ago for Pylons in the hopes it would be added to the core.
Good articles like this give me the fuel to go ahead and crack out that paster template I've been meaning to develop to integrate Pyjamas into Pylons projects.
Although, is it just me or does non-PEP 8 code look funny?
Sorry for the meta nature of this comment, but Pyjamas have been in my bookmarks for so long and I never really got the gist of it. With the first paragraph in this article, I finally "got it". This is the kind of golden stuff I love to see in HN, so please keep 'em coming!
