I've gotten several emails over the past few weeks, asking if I could post the source code to the programs I've written in a zip file format, since blogspot tends to mess up the ampersands, greater, and less than signs in my Arduino sketches when I just copy and paste. Despite my attempts to try to fix each snippet I post, some inevitably mess up, so I decided to take a whirl at learning Ruby on Rails and made an open source "app store" (sort of like Apple, but 100% not really). All the app source code snippets I've posted ever are GNU licensed open source, and are now zipped into little packages over here. I'll try to do this from now on, too! Anyway, doing this made me learn a lot about the language underpinnings of Rails.
It was an odd juxtaposition: I had a chance to write Ruby code for the website, and in between functions I'd make some more progress on my Processing on Arduino app. Flipping back and forth between Rails and Arduino Processing was actually harder than I thought...
What is Ruby on Rails?
- A script-based, runtime compiled, object oriented language called Ruby extended with a development framework called Rails
- It's used for a lot of websites these days because of how easy it is to manage prototype, deploy, manage backend changes, etc.
- It's lead users are all those spritely web coders running all over the place these days (and since everyone kept making such a big deal about it, I figured I'd try to learn it)
- A narrow subset of Java (close to C and C++) called Processing compiled to bytecode to run on an embedded machine, within a development framework called "Arduino"
- It's used for teaching electronics, creating art, making open gadgets and electronics
- It's lead users are all those guys that post furiously over at arduino.cc (and a bunch of fellow Italian guys!)
So, onto the list of similarities:
5) Isolation - Both languages and environments operate on the principle of isolation. That is, complexity in other parts of the environment are obscured when you're coding. In Rails, when you're writing a database model for one feature, you don't really care about or see the code for other database models. You just build the functionality you want there on the spot. In Arduino, you don't have to wrestle the complexity of the Atmega CPU, you just focus on the C functionality and hit compile.
4) Portability - Sketches written in Arduino Processing are typically just a single file, and only the most complex ones will be several files. That means that sharing code is as simple as a little copy and paste (though not onto a blog on blogspot, apparently). There's almost no configuration or customization necessary to go from one platform or computer to the next (only what serial port are you using). On Rails, pretty much the only thing you have to configure when porting an app from one computer to the next is the database.yml file (the one that stores your local database username and password). After that, it pretty much runs as configured, which is amazing considering all those sad, long nights in PHP world that I'll never get back :(
3) Universality - A few simple functions work everywhere, on anything. Arduino's print functions almost mirror the simplicity of the to_s() and related typecasters in Ruby. That way, you don't have to spend all your time worrying about data types and formats (yeck)
2) Code compression - On the Arduino, a 5 line program will get you up and running, blinking an LED, and that's it. On Rails, a 5 line edit to a data model could mean adding validations to every form on your entire website. So both languages are made to compress a lot of meaning into short syntax.
1) "Lite" programming - Previous languages and development environments seemed focused on exposing all the bells and whistles to the programmer. That meant huge learning curves too, as every developer was forced to learn huge lists of functions before writing useful code. This is a lot like my experience with old school Code Warrior from Metrowerks on the Mac (and some Programming the Macintosh Pascal books). Both Ruby/Rails and Arduino operate on a completely different principle, almost like "light" programming. You're given a few constructs first, into which you can make small tweaks that have significant affects on the behavior of the program, and only later - as you learn more - are you encouraged to learn more complex functions.
And now the differences:
5) Object orientation - This one's obvious, so I'll start out with it. Arduino Processing is based on Java, so it could use the object oriented methods like ::, embedded functions, objects, etc. But in general, those are confusing to learn for programming beginners, so it doesn't force them on you. Instead, it's based primarily on a linear functional programming style with functions calling other functions directly, not through objects. Ruby and Rails, on the other hand, is completely object oriented. So much so that at times it feels like it's getting a little carried away (maybe that's because I still miss the goto function from my BASIC days - ha).
4) Longevity - Ruby on Rails programs are forever (don't sue me, please, diamond company that rhymes with "endears"). Rails programs always run, and are meant to sit on servers somewhere churning away like workhorses. Arduino programs are more fleeting. Even the name, "sketch" implies a quickly written thingy that runs lightly, does one thing, for a period of time, and then gets replaced with another sketch. Arduino sketches are a bit like constantly evolving, dynamic modules.
3) Learning curves - On the Arduino, the learning curve is tightly managed by the Arduino founders. David Mellis and Tom Igoe frequently debate on the mailing lists and forums whether certain functions are worthy additions to the Arduino core language. The argument typically says (and I agree) that you leave the core language simple, strong, and generalizable. Then as guys master the base language, they can expand as they grow. So the first activity you do when you get an Arduino is download code and make LEDs blink. By comparison, on Rails, the API and programming metaphor *is* the language, and so you have to learn it first. Otherwise, you don't know where files are, where functions are supposed to go (is the function a data manipulation, data extraction, or visual presentation function?), or where to find things. While learning Rails, I spent 75% of my time just opening and closing files, saying to myself, "nope that function isn't in there, is in there, nope, oh there it is." So the first activity you do when you get Rails running is reading... books ... full of functions and block charts ... to understand where things are.
2) Programming path - The tech guys would call this "tool chain" but I always tend to think power tools, and that can be intimidating so I avoid anything that's named a tool chain (and instead opt for something like a beginners package). Arduino has a simple programming path; write code, click verify (compile or spit out errors), click download, done, led blinks, yey. By comparison, Ruby on Rails feels like a zoo. Gems, plugins, and migrations sometimes seem to fight with each other for metaphorical dominance during programming. Which ones are right? Which ones are primary? Script server to run but script generate to build? It's all very close together and tightly knit, so it can get a bit confusing.
1) Hardware / software stack - Rails is purely a web construct. It's 100% software that runs on other software, that sits in generic computer boxes. It's born as information, and remains information based for the rest of its useful life. By comparison, Arduino starts out as software, but then makes a jump to hardware. This allows physical computing to happen, because source code bits can now change real life physical stuff. To me, that's what makes Arduino so much more fulfilling, line-for-line, than Ruby on Rails.
So there you have it, my little reflection on 3 weeks of intense Ruby on Rails and Arduino Processing coding!