You are here

My ideal mobile mad scientist language

Submitted by Roland on Tue, 2009-11-24 22:35

After some digging and research around the web, my ideal mobile mad scientist programming language would:

  • have the 2D and 3D graphic manipulation power of Processing, Nodebox and Shoes
  • be cross platform mac, windows, linux, maemo on mobile, iPhone, android
  • be 'web native' i.e. REST, JSON, XML and all the other web API stuff built in and not bolted on like it is Processing, trying to use the flickr api from Processing is shall we say kludge-o-rama (awesome code from bryan chung but indicative of the unnecessary struggle one is forced to engage with in Processing and other non web native languages)
  • not use a Java-like syntax, death to curly braces and wasted semi-colons
  • be dynamic, death to the Java/C++ cargo cult of typing for no reason 
  • be easily adaptable to new APIs and new sensors through the ability to create a domain specific language and/or easy to use and beautiful foreign function interface
  • be open source, sorry but for my mobile art,  i can't use programming environments and languages that are not open source
  • support the REAL loop, I don't want to spawn threads for the sake of questionable 'concurrency' like I am forced to with OSGI and the Bug Labs Bug

IF I were an idealist that pretty much rules out everything :-)

Fortunately I am a pragamatist. So I will continue my experiments in:

  • Nodebox & Python on the Mac
  • Cocoa Touch and Objective C on the iPhone

What about Processing? Sorry can't handle the Java syntax and the pain of doing XML and JSON and REST programming and the kludge-o-matic way to access Java libraries. processing.js? too early and too much impedance mismatch to use all the lovely JS libraries out there. And Shoes is promising especially if it were improved so you could easily use normal Ruby gems but given its current "hibernation" "post-Why" not sure it will continue to be improved.

What should I use on Maemo if/when I get an N900? Ruby plus SWIG or some such foreign function kludge er interface :-) to access the sensor APIs which I assume are only available in C and C++ ?

What should I use on Android if/when I get an Android device?

What should I use on Windows? Not that I really care :-) But it would be lovely to have Windows people join in my fun without having to do anyting. Eines Tages!

Somehow I think the "mainstream" world is moving towards my ideal solution and the mainstream solution for what I want will look more like processing.js and ruby-processing or smalltalk i.e. scratch then it will look like Processing, Nodebox or CocoaTouch

Comments