One of the rather unique features of the Fortress1 programming language is that it has builtin support for Unicode operators. For example, instead of using “==” you would use U+2261. After reading the spec, and a recent thread on ruby-core, I’ve been wondering something . Are language designers too limited in their decisions about syntax because of the limitations of the QWERTY2 keyboard?
Though I’m typing this from a Mac right now, I’m hardly a fan boy. I spend a little less than half of my time on OS X, the rest spent on cheap PC hardware and ArchLinux, and honestly, I’m happy with both (each for different reasons)
Still, Apple definitely got some things right, and not the least of which was hiring Laurent Sansonetti. He’s the guy who’s been working on cool projects such as RubyCocoa and RubyOSA, and now has just released MacRuby.
MacRuby sounds cool:
MacRuby is a version of Ruby that runs on top of Objective-C. More precisely, MacRuby is currently a port of the Ruby 1.9 implementation for the Objective-C runtime and garbage collector.
Though I’m not actively doing Mac specific Ruby development, that doesn’t mean I can’t extend thanks to a very cool hacker who has been dropping cool free software projects on our community like it was his job…. oh wait… it is. :)
Thanks Laurent for your contributions! You’re one of the reasons why the Ruby community rocks.
UPDATE: Okay kids, now it’s 50% fantasy. It’s up to you to cover the other 50% by donating and spreading the word, after reading my proposal. Here’s hoping for the best!
UPDATE: Though my original post was 95% a fantasy, I’ve received some funding offers that have brought it down to 75% fantasy. I will be documenting any planning I’m doing towards via a wiki called RubyMendicant. If you’d like to follow this on the bleeding edge, keep an eye out on that wiki. Otherwise, if you hear an official announcement within the next few weeks, you’ll know I decided to take the plunge, and if you don’t, then it’s safe to assume this idea went the way of the dodo. If you like this idea, please spread the word through the usual means of the intertubes by sharing this post and the wiki link with others.
Here’s a crazy idea I just had, and I’m wondering what folks think about it.
People do open source for a lot of reasons, ranging from pragmatic to idealistic. Some write a patch every six months or so, others do what they can to dedicate their life to it. Though I try to have a life outside of software, I’m definitely more on the obsessed end of the spectrum when it comes to contributing to open source software.
I find myself in a rather unique situation: Single, living alone in a small studio apartment, only taking a class or two here and there, and basically living off of small contracts. It’s not that I’m not offered big gigs, or that I couldn’t go back to school full time if I really wanted to, I just find I enjoy living a simple lifestyle that lets me spend a lot of time on community oriented projects, especially Ruby stuff.
Right now, I need to do some work each month to pay the rent, and slowly save up to make sure I don’t get evicted during a slow work month. Between BTree and Madriska, I could say that I have two of the most open source friendly commercial relationships I’ve ever seen. Though I’m working on real projects with them, things that have to actually fit some sort of business need, they give me a lot of leeway to improve open source software while working on them, Ruport is pushed along heavily by this.
I could see myself doing that for a while. Working with a few different clients I trust, who in turn hook me up with interesting projects for a variety of companies in various different domains. A lot of it might be Rails work, but not all of it is. Still, in a moment of idealistic fantasy, I thought of another idea:
What if I could just do open source for a while, non-commercially?
How much would it cost for me to do at least 80 hours a month of development on software projects such as PDF::Writer, Ruport, and some other projects I wish I had the time to get my hands on?
I did the math, and the number came out low (subjective). I could meet all my expenses and save some money for about $2000 a month. Basically, if 200 people donated $60 right now, I could take 6 months off and do nearly 500 hours of work, and that’s only if I didn’t find myself obsessed with and doing extra hours on a project. I could more-or-less maintain my lifestyle that I have now, but not take on contracting projects that are either too big or too small out of necessity. Sure, this works out to be a lot lower than my contracting rate, but I could hack entirely on open source projects, maybe write some documentation and articles, and still be able to afford a class or two a semester. Sounds beautiful to me, though I’m sure it’s just a fantasy.
Indulging me for the moment, how would I remain accountable to anyone who supported such a venture? I’d make it transparent as possible. I’d record public hours, with links to changesets, tickets, blog posts, whatever. Though people would have to accept good faith (with at least a roughly outlined plan) as to ‘where I direct the time’, they’d get to see every bit of ‘where the hours went’.
What prevents this from being a total scam? You do. Though I don’t have some A-List reputation, I still make my living based on my reputation as a developer and a contractor. If I somehow totally screwed people who supported such an effort, all it would take would be enough negative feedback from the community to prevent me from getting away with dishonesty.
What would indicate a great success? If after 6 months, this all worked out, and I was interested in doing it for another 6 months, if people funded it, we’d know they actually liked what I did the first time around.
Finally, this doesn’t have to be me. It could be any old hacker you choose, someone you trust that’s working on things you’re interested in. They’d tell you how much it’d cost to have them quit their day job for 6 months, and hopefully people could pool resources. Though the open source community is kept alive by small day to day contributions, we all know the power of having someone dedicated to a project with copious free time.
I’m talking in theory, because obviously there are some complications. If I personally were to do this, I’d need to cycle out of some projects, and figure out to what extent it’d piss of the people I work with. Still, I am sort of curious, is this an idea that belongs in the trashbin, or should I open up a pledgie account for donations? :)
Maybe this is something that could be done on a trial basis, such as ‘40 hrs over 1 month’. This is something I could do without putting a close to all my work. Given that, based on my needs (not my billable rate), that’d be um… 10 dollars from 100 people?
On the one hand, this seems almost like a joke to me, a sort of ‘wouldn’t it be nice if…’. Still, if some respected Rubyist wanted to steal this idea, undercut me on the price, and ask people to start donating, would I be among them? You bet ya.
Let me know what you think. I’ve tried so hard over the last few years to find ethical and practical ways to work in open source development, and they pretty much work. But because of that, I’ve mostly ignored the idealistic ones, and this is just a shot in the dark at one of those.
I find Ruby’s current warning system, if you can call it that, lacking. Warnings are controlled by the -W flag on the command line, and are generated via the Kernel#warn method within code. There are a host of problems with this approach to warnings.
Interesting:
I asked a question on Phlip’s last post about whether assert { 2.0 } was really necessary, given that it’s mostly just assert_block from Test::Unit. I noticed this question disappeared from the post, because I guess it was offensive somehow.
Though it made it through the second time around and Phlip answered reasonably, he sent me a private email explaining that he had censored me because I apparently don’t “get” assert { 2.0 }.
Not to pick a fight, but I personally believe that blog posts that have comments turned on should only be moderated for spam and/or abuse, which my comment was neither of. If you’ve got some questions about assert { 2.0 } that you’d like to see stay online without silent censorship, feel free to post them here.
This hopefully serves as a simple reminder that we should keep up with the ‘open’ in open source, and not silence technical questions randomly.
The title of this post is the title of a talk I’ll be giving at NYC Ruby on February 12th.
Aside from blatent self promotion, I’m actually posting in search of opinions and thoughts to incorporate into this discussion, so that I can give a little more of a balanced account beyond my own crazy ideas.
Here’s my short and rather vague description of what I’ll be talking about:
Lots of people come to Ruby or stick with it because of the community, but what does that mean? In this short talk, we’ll take a look at what the Ruby community has meant over time, what it means now, why it’s dead, and why that’s not a bad thing. Not quite as depressing as it sounds, this talk will focus on how specialized groups such as local Ruby communities, regional conferences, and individual projects have developed their own distinct culture while still being impacted by the Ruby community of old.
What I’d like to know is what readers here have experienced with both “The Ruby Community” as well as Ruby communities in general. This could range anywhere from describing the general feel of your local Ruby users group to picking a bone with some of the ‘untouchable’ aspects of Ruby culture.
I’ve been trying to make my talks a bit more interactive in a sense, hoping to simply set up a discussion rather than pontificate, so having hearing your opinions will help me do that. In return, I promise to write another post titled “Why the Ruby community matters, and why it doesn’t” which will summarize any thoughts people have shared as well as the content of next week’s talk.
Anyway, looking forward to your thoughts. Feel free to be as bold as you’d like, and if you don’t want to be credited for your words, just post anonymously.
When I first got involved in free software development, I didn’t really know why I was doing it. It just seemed reasonably fun and challenging, which was enough to let it steal up every spare minute of my time in the form of a not-so-mini obsession. I didn’t so much think in terms of community, or how whether of my work would be useful to people, I was mostly just hacking for hack’s sake.
Eventually, I came to realize what fueled my work in open source, and that was the ability to learn from some truly amazing people, and later, return the favor by doing the same for others. If you like any of the work I’ve done in Ruby, you have exactly one person to thank for getting me started (James Edward Gray II), but hundreds to thank for keeping me going.
Here I’d like to talk a bit about my experience with the Ruby community and how it compares to something completely different, the community surrounding the board game Go. As I played in this past weekend’s North American Oza tournament, the idea for this article came to mind, and hopefully it doesn’t sound much worse in type than it did in my head. I must warn you, if you’re looking for technical depth, you’re not going to find it here, this is mostly just wishy-washy feelings and general observations that’ll only be interesting for those that have an obsession with community dynamics.
If that doesn’t scare you away, feel free to read on.
If you don’t mind ‘bad’ language and a little bit of hate, go check out Zed Shaw’s rant,Rails is a Ghetto.
I’m not quite sure what his intent was with the article, I’m not sure that even matters. What I know is that it has shock value, it made me laugh, and that a number of things in it ring true with me, even if a bit magnified.
Zed and I have had at least a couple conversations about the Ruby / Rails communities before, and I’d say philosophically, we’re mostly on the same page. The key difference is that Zed is… umm… Zed.
One thing that he pointed out as a difference between us is that I don’t really challenge the status quo. This is true, I prefer to slowly bend the rules rather than shatter them, and see where that takes me. My response though was that I like to challenge the folks who try to suppress those who would challenge the status quo.
So here’s my challenge at a few responses, because everyone loves to stir things up!
However, such a hate-filled nasty person should not be allowed to terrorize the nice, pleasant, and generous Ruby community. Sure there are bad guys out there, there are in any community, but this type of rant is pure crap. Such arrogance and hate are self-destructive. I hope Zed’s self-destruction happens far away from my world, but I wish it would hurry up so the rest of us can get back to enjoying writing code.
Wait a second. Zed is getting in the way of you enjoying writing code? Is Zed Shaw standing there threatening Roundhouse kicks to the head while you try to type in some Ruby code?
Or is Zed distracting you because you’re reading his blog and getting offended? If so… it seems that the solution is the same as if you don’t like something on TV. Change the channel. Go outside and take a walk.
Wear some garlic, I heard Zed hates garlic. Something about how it steals his magic powers.
On a serious note though, saying that hating on people in public is self destructive is like saying that smoking crack is self-destructive. If you think that Zed doesn’t know what he’s doing, you’ve been duped.
I was going to go on and challenge a few more of Zed’s haters. But you know what, I haven’t found any. The closest thing is Giles Bowkett being concerned about how anger is bad for Zed’s heart. There was also something from a consulting company which mostly agreed with Zed’s points, with only minor disagreements.
I’m not defending Zed. As you can see from the posts, he’ll physically defend himself if need be, so he doesn’t need that. I’m also not much of a fanboy, I like mongrel but I can remember when it was just something we were chatting about and playing with at NYC.rb. Still, the real thing that I’d like to confirm here is that he has a point.
If the Ruby community starts to get up in arms when they see rants like this, that’s even more of an indication of the fact that the lines between the Ruby and Rails communities have blurred, and that we’re going to increasingly turn away our best hackers who are interested in real community, beginning a slow slip all the way to JavaOne.
The good news of course is that Technorati lists a number of links to Zed’s rant with comments like “entertaining”, “hilarious”, and other such praises. Every strong community needs heroes and anti-heroes. My question is only who will replace Zed.
Some of you may know that I’ve been working on The Ruport Book, a free-content book about Ruby Reports. Mike Milner and I have really learned through trial by fire some of the pros and cons of DIY technical publishing in the last few months. I’d like to share some of my thoughts here in a mini-ramble in hopes of stirring up conversation and ideas.
Got a favorite gem you want to tell the world about? Or one you want to warn other people about? You can do both with Gemtacular!
Gemtacular (http://www.gemtacular.com) is a place to rate and review Ruby gems. It’s a great place to not only find opinions on various gems, but also to see the most recent gem uploads, find the most highly rated gems, or just search for existing gems.
Some quick guidelines:
* Gemtacular is not a place to report bugs. Use the project page for that.
* Be nice. If you have a problem with a particular gem, please explain why without getting nasty.
* Don’t be lame and rate your own gems.1
1I already have a feature request in to try and prevent this at http://rubyforge.org/tracker/index.php?func=detail&aid=10063&group_id=2863&atid=11067
The most important thing I’ve picked up with each RubyConf I’ve attended is a new outlook on my work. Each year the talks invite people to have their minds bent a bit, both technically and philosophically. Though I didn’t take notes and my attention span is usually too low to keep a full talk in my head, the following discussion is largely based on ideas from various talks I attended, especially from Nathaniel Talbott, Eric Hodel, Ryan Davis and Evan Phoenix. It also has some sprinklings from the hallway track, as well as some delusions from the back of my mind. Sorting all that out is up to you.
So what is real productivity? Maybe we can look at it as the coding nirvana that we’re all striving for, but I think it’s even more simple than that. True productivity just involves eliminating apathy from your life, leaving you with nothing left but things you care about, and no choice but to take care of them. What follows is a simple extension of that general idea into software practices.
Anyone else think that Godwin’s Law should be amended to include Rails?
Just a thought.
UPDATE (2007.09.27): Several have pointed out that Godwin’s Law isn’t the precise thing that should be updated. Really it’s Case’s Corollary that needs to be changed, thanks for helping me realize this.
SUMMARY: I spent two years trying to make Rails do something it wasn’t meant to do, then realized my old abandoned language (PHP, in my case) would do just fine if approached with my new Rails-gained wisdom.
INTRO / BACKGROUND:
Back in January 2005, I announced on the O’Reilly blog that I was going to completely scrap over 100,000 lines of messy PHP code in my existing CD Baby (cdbaby.com) website, and rewrite the entire thing in Rails, from scratch.
I hired one of the best Rails programmers in the world (Jeremy Kemper aka bitsweat), and we set off on this huge task with intensity. The first few months showed good progress, and Jeremy could not have been more amazing, twisting the deep inner guts of Rails to make it do things it was never intended to do.
But at every step, it seemed our needs clashed with Rails’ preferences. (Like trying to turn a train into a boat. It’s do-able with a lot of glue. But it’s damn hard. And certainly makes you ask why you’re really doing this.)
Two years (!) later, after various setbacks, we were less than halfway done.* (To be fair to Jeremy’s mad skillz: many setbacks were because of tech emergencies that pulled our attention to other internal projects that were not the rewrite itself.) The entire music distribution world had changed, and we were still working on the same goddamn rewrite. I said fuckit, and we abandoned the Rails rewrite. Jeremy took a job with 37 Signals, and that was that.
I didn’t abandon the rewrite IDEA, though. I just asked myself one important question:
“Is there anything Rails can do, that PHP CAN’T do?”
The answer is no.
I threw away 2 years of Rails code, and opened a new empty Subversion respository.
Then in a mere TWO MONTHS, by myself, not even telling anyone I was doing this, using nothing but vi, and no frameworks, I rewrote CD Baby from scratch in PHP. Done! Launched! And it works amazingly well.
It’s the most beautiful PHP I’ve ever written, all wonderfully MVC and DRY, and and I owe it all to Rails.
Inspired by Rails:
*- all logic is coming from the models, one per database table, like Martin Fowler’s Active Record pattern.
*- no requires or includes needed, thanks to __autoload.
*- real MVC separation: controllers have no HTML or business-logic, and only use REST-approved HTTP. (GET is only get. Any destructive actions require POST.)
*- all HTML coming from a cute and powerful templating system I whipped up in 80 lines, all multi-lingual and caching and everything
*- … and much more. In only 12,000 lines of code, including HTML templates. (Down from 90,000, before.)
Though I’m not saying other people should do what I’ve done, I thought I should share my reasons and lessons-learned, here:
SEVEN REASONS I SWITCHED BACK TO PHP AFTER 2 YEARS ON RAILS:
#1 - “IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN’T DO? … (thinking)… NO.”
For 2 years, I thought Rails is genius, PHP is shit. Rails is powerful, PHP is crap.
I was nearly killing my company in the name of blindly insisting Rails was the answer to all questions, timeframes be damned.
But when I took a real emotionless non-prejudiced look at it, I realized the language didn’t matter that much.
Ruby is prettier. Rails has nice shortcuts. But no big shortcuts I can’t code-up myself in a day if needed.
Looked at from a real practical point of view, I could do anything in PHP, and there were many business reasons to do so.
#2 - OUR ENTIRE COMPANY’S STUFF WAS IN PHP: DON’T UNDERESTIMATE INTEGRATION
By the old plan (ditching all PHP and doing it all in Rails), there was going to be this One Big Day, where our entire Intranet, Storefront, Members’ Login Area, and dozens of cron shell scripts were ALL going to have to change. 85 employees re-trained. All customers and clients calling up furious that One Big Day, with questions about the new system.
Instead, I was able to slowly gut the ugly PHP and replace it with beautiful PHP. Launch in stages. No big re-training.
#3 - DON’T WANT WHAT I DON’T NEED
I admire the hell out of the Rails core gang that actually understand every line inside Rails itself. But I don’t. And I’m sure I will never use 90% of it.
With my little self-made system, every line is only what’s absolutely necessary. That makes me extremely happy and comfortable.
#4 - IT’S SMALL AND FAST
One little 2U LAMP server is serving up a ton of cdbaby.com traffic damn fast with hardly any load.
#5 - IT’S BUILT TO MY TASTES
I don’t need to adapt my ways to Rails. I tell PHP exactly what I want to do, the way I want to do it, and it doesn’t complain.
I was having to hack-up Rails with all kinds of plugins and mods to get it to be the multi-lingual integration to our existing 95-table database.
My new code was made just for me. The most efficient possible code to work with our exact needs.
#6 - I LOVE SQL
Speaking of tastes: tiny but important thing : I love SQL. I dream in queries. I think in tables.
I was always fighting against Rails and its migrations hiding my beloved SQL from me.
#7 - PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER
Rails was an amazing teacher. I loved it’s “do exactly as I say” paint-by-numbers framework that taught me some great guidelines.
I love Ruby for making me really understand OOP. God, Ruby is so beautiful. I love you, Ruby.
But the main reason that any programmer learning any new language thinks the new language is SO much better than the old one is because he’s a better programmer now! You look back at your old ugly PHP code, compared to your new beautiful Ruby code, and think, “God that PHP is ugly!” But don’t forget you wrote that PHP years ago and are unfairly discriminating against it now.
It’s not the language (entirely). It’s you, dude. You’re better now. Give yourself some credit.
Ok. All that being said, I’m looking forward to using Rails some day when I start a brand new project from scratch, with Rails in mind from the beginning.
But I hope that this reaches someone somewhere thinking, “God our old code is ugly. If we only threw it all away and did it all over in Rails, it’d be so much easier!”
It’s often been said that Perl’s greatest strength is CPAN, Perl’s vast collection of free libraries contributed by developers from around the world. Recently I started to wonder about RubyForge and how RubyForge stacks up against CPAN in general.1
Consider this fact: Multi-core CPUs are not only the future, they’re the only way CPUs can continue to grow at their current pace. It’s also a hotly debated subject in the software world. Multi-threaded programming is different and not seen as often as procedural programming, and therefore it’s not yet as well understood. So the question is, how can programming languages (and Ruby in particular) make it easier to harness these systems?
As Ruby struggles to graduate from its current implementation into something more powerful, we’ve already seen several projects attempt to update Ruby to help developers cope. Those who’ve been working with Ruby for awhile may remember YARV, which promises to provide more threading support. JRuby offers all the power of Java’s threads to Ruby, if it can harness it. And Evan Phoenix’s small but rapidly growing project Rubinius is attempting to be the next big contender.
No matter what implementation becomes the next de-facto Ruby platform, one thing is clear: People are interested in taking advantage of their newer, more powerful multi-core systems (as the recent surge in interest in Erlang in recent RailsConf and RubyConfs has shown). As Ruby becomes increasingly part of solutions that deal in high volumes of data processing, this demand can only increase.
That’s why it’s so very surprising to see David Heinemeier Hansson dismiss the whole notion out of hand regarding Rails. His argument seems to be that Rails already scales to multiple cores in the same way it scales to multiple machines, via UNIX process distribution. After all, isn’t this the very crux of “Share Nothing?”
Here’s an open question that I’m hoping will get some interesting discussion going:
Why are there so few Ruby jobs out there?
Those of you who have been to RubyConf in recent years have been asked the question “How many people get paid to write Ruby?”, and you’d see that in the last year or two, the number of people who raise their hand has absolutely skyrocketed.
However, at Gotham Ruby Conference, someone asked “How many people are paid to write plain Ruby, no Rails”. I think like 3 hands went up, and I was one of them, out of 120 or so people. It’s possible that we just have a lot of Rails work in NYC, but I think the issue might be deeper than that.
I’ve seen so many of my friends say “Oh, I’d rather be writing pure Ruby, but at least working in Rails gets me close to that, and it’s better than working in <insert_language_here>”.
Is Ruby really only viable for database driven web applications? I doubt it. I think it can stand its ground anywhere Perl or Python could. So why is it that most job postings you see are for some sort of “Web Rockstar”, and not like, a sysadmin with scripting experience, or an internal applications developer?
I guess it could be a lot of things, any of the below or a combination might be to blame:
I don’t really know what it is. I understand when corporate politics get involved, all things go out the window, but I think that Ruby’s success as a commercially viable language outside of Rails is less than what it should be at this point. Do other people feel the same way?
UPDATE: Buried deep within the mixed replies to this post is a great writeup by Andy Peters which states more assertively what I was implying here…
With the decent success of the last post, why not throw another opinion into the mix?
This is something that comes up every now and again on RubyTalk and other community forums, but it always starts something like this: “Wouldn’t it be great if we could start teaching Ruby in schools instead of C/C++/Java/Forth/Lisp/Fortan/COBOL/BASIC/Brainf*ck?”
I usually try to shy away from opinion posts (on this blog and elsewhere). When I do make them, I usually ask a few people if they think I’m asking for trouble.
This post: I don’t care if I am (but I hope I’m not).
We’ve put some effort into increasing the signal on this blog over the last week or so.
I personally am super happy with the new content up here. But it’d be interesting to see what folks think about our progress as a whole.
So like a truck driver with a “How’s My Driving” sign on his big rig, I’ve created a Jyte claim.
It’s simply, “The O’Reilly Ruby Blog has improved since 2007.03.21″
Anyone with an OpenID can come support or bury this claim, and let us know if we’re truckin’ fine or veering off the mountain.
I’ll try to stop with the meta-posting… expect a Digging Deep article soon!
Here is a nice looking javascript date widget that you can embed in your RoR application. Instructions on installing the widget into your Rails applications is provided on the home page.
I’ll definitely be giving it a whirl.
This blog has some of the best Ruby talent floating around on it.
Problem is, it seems like many folks are too busy, too tied up with other blogs, or too (something) to post here.
Some of us want to turn that around. I’ve been talking community for the last week or so, and I’d like to start eating my own dog food right here at home.
We’ve already started discussions on the internal mailing list, I’m willing to open Pandora’s box and ask you readers what you are looking for. What things do you like and want to see more of? What things do you dislike and want to see banned from ORA and possible chased by an army of undead pirates?
If you go back and look at the list of authors we have here, there is serious potential for a cool ruby resource. Problem is, no one knows quite what to do anymore, since the overall feel over here is a little fragile.
I was pretty excited when O’Reilly set up a Ruby blog. I’d like to see that excitement restored among the bloggers here. So, readers, what can we do to make you happy?
If it involves Chunky Bacon, so be it!
Rails for All is a RoR web site, which is interested in promoting RoR as the platform of choice for user centric, database-backed web application. The site allows you to promote your Ruby or RoR users group and also register yourself or your company as RoR developers.
RoR content portals are springing up all over the place.
There has been more talk on top RoR blogs on the the ror-talk mailing list this week. Here are five blogs i subscribe too.
It’s old news now that Aptana has picked up the RadRails development effort and you’d probably notices that the radrails.org domain no longer exists. The new domain is radrails.net. Aptana has already introduced nightly builds and are working towards a 0.8 release, although I couldn’t find any information on time lines.
This is all good news for Eclipse users like myself. Currently, I am getting by with the 0.7.2 and the command line but ‘chafing at the bit’ for Aptana’s first release.
Reports of the death of Ruby Code & Style have been greatly exaggerated.
I’ve been the Editor-in-Chief of Artima’s Ruby Code & Style for somewhat over a year now. For various reasons, I am stepping down.
Just to be clear, I’ve had nothing but good experiences helping get the ‘zine up and out the door, and have endless appreciation for all those who pitched in and made things happen. It’s mainly a matter of time; I cannot give it the attention it deserves.
I expect a formal announcement on this to appear on the RC&S site before long, so I’ll the details to that. But I want to at least assure people that that the ‘zine has not simply up and died. It continues.
So there is at least one Ruby magazine (albeit online-only) that is around. But people should appreciate that organizing and maintaining a good publication is non-trivial.
Getting and preparing a steady flow of high-quality material is not easy. It’s a job. The goal for RC&S was to publish content a cut above what one typically finds in, say, Linux Journal or on most blogs.
That’s not meant as knock on those sources, just that there is zero reason to publish one more “How To Write a Blog in Rails” article.
I recently replied to an email on the ror-talk mailing list about resources on agile methodology and RoR. Here are four non-RoR specific resources that i have used during the past 12 months
I’d like to hear what resources other people are using?
It looks like development for the RadRails plugin for Eclipse has stalled and the key contributors are flat out working on a startup venture. Who can blame them we all need to eat. So the search for an alternative Windows Ruby\RailsIDE has started. I’ve read a log about textmate/, the mac os editor and was curious why they never offered a Linux/Windows version. Well the power of textmate has come to windows with .e-texteditor.
I just downloaded it the demo version and first impressions are very positive indeed. Not enough there yet to move me from Eclipse but it is getting there.
You should take a look at it.
(correction): fixed Upton Sinclair quote it is ’salary’ not ‘job’ (thanks for the correction)
Even with all the buzz, it is still a tough sell. If you’ve suggested Rails as an alternative to (Java|.NET) at work, you’ve probably experienced some reactionary pushback. Convincing a set of established “Enterprisy” engineers that Rails is worth paying attention to it is like convincing a Texas oil baron that he should purchase a Subcompact hybrid vehicle and become a Vegan. Why is convincing a highly paid (Java|.NET) programmer to look at Rails that difficult? I’ll steal a quote from Al Gore’s Inconvenient Truth that he, in turn, stole from Upton Sinclair:
“It is difficult to get a man to understand something when his salary depends on not understanding it.” - Upton Sinclair (1878 - 1968)
In an effort to convince, you may have sent people to some of the good Ruby on Rails blogs. This might have escalated the resistance. Asking your fellow enterprise developers to read DHH’s loudthinking.com, is like asking (the other) O’Reilly to sit down with Colbert - Mr. Enterprise isn’t going to appreciate the message because he’ll be focused on the ridicule. Rails, rightly so, is positioned as the challenger, and it makes good use of hyperbolic ridicule to gain converts. This works for most of us, but I’ve also seen it push some entrenched Java developers further away.
So, you are in “The Big Planning” meeting, and your boss says something like, “There is no time to finish this project, we’re going to have to tell the customer we won’t meet the deadline.” You wearily offer up the suggestion: “We might be able to deliver something on time if we used Rails to implement the web application”. And, an entire room full of Java programmers is now trying to tell you every reason from here to the North Pole why your suggestion is naïve. Here are some of the common responses:
Let’s take each one individually…read on…
A comparison between the #5 language (ranked popularity by Tiobe on Jan/07) and the #1 framework (ranked lovability by me!).
My hometown, St. Louis, is hardly one of the great meccas of the computing world. Places like San Francisco, Seattle, and New York were the first to have local training available. Yet, even here in St. Louis, if you want Ruby on Rails training you now have more than one choice (competition is good). Last year OCI unveiled local RoR training, and now Inspired Horizons is doing the same. I’d be willing to bet that this is quietly happening all over.
Help prove me right. Do you live in a place that is not considered one of the computing hot spots, yet you still have local Ruby or Ruby on Rails training available? If so, post a comment and tell us about it!
Sometimes I feel like a slacker. I don’t subscribe to Ruby-Talk or any of the official Rails mailing lists. I just don’t have time to read 500 messages a day!
I do lurk on several local Ruby mailing lists. The traffic is usually smaller and the content is top notch.
Here are a few that I enjoy reading…
NOTE: If you choose to subscribe, be courteous. Lurk for a few weeks and get an idea for the content that is posted before starting a new thread.
One common criticism of the RubyQuiz is that the quizzes are ‘too hard’.
I don’t think this is necessarily true. It’s more likely that the difficulty comes from the RubyQuiz being so diverse in the topics it covers.
It might be easier if we could sort through and find the quiz topics we’re interested in.
Using del.icio.us, we can easily tag the quizzes with the tag rubyquiz and then a series of topics for each quiz.
Then, when people visit quizzes, they can look up the tags for the page to see at a glance what the quiz covers.
We can also go to the rubyquiz tag to see a list of related topics, and then see just the quizzes that fall under topics we’re interested in.
If the idea catches on, maybe JEG2 would include some sort of handy way to view these tags right alongside quiz summaries. Even without it, this would still be helpful for anyone using del.icio.us that likes the RubyQuiz.
I’m going to spend some time today tagging, and I’m hoping others do the same. Let’s help make RubyQuiz even better by making it even easier to reference the many cool topics it covers!
I love the fact that RubyForge is available for us. It’s one resource that almost every Ruby developer working on free software is bound to need. One thing that I don’t like is how we pull in the GForge juggernaut for projects that often consist of one or two files.
If you look around RubyForge, you’ll notice that many projects have 10 tabs on their project page: Summary, Forums, Tracker, Lists, Tasks, Docs, Surveys, News, SCM and Files. While in theory this is a great idea, it’s rare for a developer to want to use GForge for all 10 of those things. Today I finally decided to poke through the admin interface and find the “Public Information” section. All of these things can easily be hidden.
As I poke around RubyForge, I do see I might be a little late to the cleanup party. The Rails project on rubyforge is blissfully barren, and many other popular libraries have done this as well. But as a word to those who are still showing ten tabs and using two, tweak your UI. It’s better to have a user email you and ask you where your mailing list is than it is for them to post on a forum that you never knew existed and not get an answer.
Just hoping to bring a little zen to RubyForge, and to never see this message again:
“This project has no visible documents”
The Google Summer of Code program is winding down now, and it’s finally time to take a deep breath and look around a bit. I’d like to try to share with the readers of this blog my experiences with the Summer of Code program, and also offer a little bit of insight for those who are interested in how the whole thing came together, from the beginning to now.
Though the program doesn’t officially end until the 21st, I leave on vacation tomorrow, so this will serve as my end of program reflection. This article is rather long, so for those uninterested in SoC, you may wanna mosey on along now. ;)
I just finished reading through a thread on the ruby-talk mailing list that was titled Is a block converted to a Proc object before yield? and it reminded me of one of the non-technical reasons that I love the Ruby programming language: the community!
First of all, in how many language communities will you find the creator of the language personally answering questions like this? Its not unheard of, but its not common either. Sam, the poster of the question, responded with heartfelt appreciation:
Yukihiro Matsumoto wrote:
> |Is a block still converted to a Proc object implicitly?
>
> Not under the current implementation.
>
> matz.
I'm pretty sure that this is a very official answer...:-)
Matz, I want to take this opportunity to thank you for making me a happy
programmer with Ruby.
Sam
Secondly, the Ruby community has always been a friendly place, relatively free of rude behavior. It is pretty much populated by real people with a sense of cooperation and helpfulness. Sam’s thank you prompted another thank you followed by another reply by Matz that earned my odd looks from my coworkers when I started laughing out loud:
DEBAUN, STEVE Thu, Jun 29, 2006 at 1:28 PM Can I second that motion?!?!? I was a programming burn-out. I was broken by a lifetime of shitty projects and shitty languages. One too many for-loops had left me a hollow shell of a man. I was ready to quit 'the biz' entirely. I yearned for a job that involved things that did not require debugging. Like... tiles. Aren't tiles nice? Wouldn't it be fun to run a tile business? Then I discovered ruby. Clouds parted, rays of light streaming down, the host of heaven singing their angelic choirs. Now, once again, I love what I do. Thanks Matz!!!11!!!111oneone!11one1 That is one man I will definitely buy a beer for. Sd Yukihiro Matsumoto Fri, Jun 30, 2006 at 7:21 AM Tiles are nice. My father used to sell tiles before his retirement. I am not sure if it's fun though. matz.
Over the years we’ve had a few challenges to the keep-it-civil meme that permeates the Ruby culture. But the community’s response has usually been to just ignore the flame-monger, who eventually gets bored from the lack of response and simply goes away.
We all know that technical excellence alone does not make for success, but when you combine that with our killer community, it almost seems inevitable!
I’ve been reading the post RailsConf chatter. Its uniformaly enthusiastic.
_why provided a link to some Rails-themed t-shirts that are hilarious that you just have to check it out.
A lot of people took pictures at RailsConf and posted them to Flickr here. But, if you want to see the best ones (professional quality), look at the ones that Dave Thomas took. If you saw his camera you’d know why they came out so good.
So, I recently added Agile Web Development with Rails, Second Edition to my wish list. I have to admit though, I almost pulled it right off when I saw the new cover art. I mean, I suppose the rock-star coder marketing has been instrumental in fueling the hype wild success of Rails, but now, I think the line has been crossed.
Of course, I say this partly in jest but I really do think that the framework has always been able to stand on it’s own merits without having to typecast itself as being the ‘cool’ choice for ‘hip’ programmers.
On a tangental note, I met a guy last night at a friends house who thought Ruby consisted entirely of Rails views. He said, “I don’t really like tag based languages”. Sigh.
Note: If you are about to leave a comment saying. But it’s a grind rail! Don’t. Many people already have and I was aware of this when I first posted this.
Over the last month and a half I have been hearing a number of things regarding the treatment given to one speaker in particular of the Canada on Rails conference, and would really like to offer the community some truth to what you may have or have not yet heard. I had originally hoped those who heard the rumors would be able to see through them, or at least query me to shed some light before making any assumptions, or even wiser, dismiss them as just that, a rumor.
In any event, I am going to attempt to bring some clarity, and filter through some of the confusion one man has generated.
I want to be able to read the documentation, that’s what.
I can never make heads or tails of a module until I get past the title and summary and into the actual documentation. That’s where you learn that the ’simple to use framework for foo’ is only 5% completed or that the code was written for your peers on Mars, or, sometimes, that you’ve found that rare piece of software that’s going to make your life easier.
So I created GemJack.com, a site with rdoc documentation for every ruby gems. Itch scratched.
I’d like to do more, like real search (CTRL-F for now), comments, RSS, and download stats. What would you want to see?
Hello, Rubyists! I’m Geoffrey Grosenbach and I’ll be posting here from time to time. You might remember me from the Ruby on Rails Podcast or from my graphing library, Gruff.
I’ll be in New York and San Francisco in a few weeks teaching Rails workshops for Carson Workshops and hope to meet up with local Rubyists (check my blog in a few days for the details).
A few years ago I was a devout Perl hobbyist. I was programming in Java fulltime but appreciated the quirkiness of Perl and hoped to get a job using it. Eventually I signed on with a software company and led a successful rewrite of an internal statistics engine. Together with two other developers, I rewrote the system and reduced many unmaintainable scripts to a handful of short ones. Unfortunately, we ended up leaving the company after the project was completed but still keep in touch today.
Many Rubyists are in the same situation and are ready to step out and work fulltime with a language they love. Fortunately there are many more opportunities to work professionally with Ruby now. At the same time, a certain set of skills is required and things might be different from the environment you are familiar with.
On Saturday, May 6, the Phoenix area will be having its first Code Camp . Code Camp follows a few simple guidelines, and I’m happy to be one of three people presenting on Ruby. It’s free, they’ll be a wide range of presentations, and I encourage everyone in the Phoenix area to come by.
I’ll be offering an introduction to Ruby . I’ve given Ruby intro talks before, and quickly decided that there was little point in giving a rundown of syntax, semantics, and bulleted lists of features.
Nor was there real value in emphasizing how Ruby compares to one or another language.
It’s not that these things are aren’t important, they’re just not the best topics to cover in a one-hour talk. If you are presenting to a group of geeks, they’ll generally believe you if you assure them that, much like other languages, Ruby lets you add numbers, manipulate strings, write to files, and handle myriad other fundamental programming tasks. Now, anyone who decides to go use Ruby will of course have to learn the little details, but they don’t need them in next 60 minutes. What they need is a reason to go learn them once you’ve stopped talking.
Similarly, knowing how Ruby compares to say, Java or PHP, may be important to a Java or PHP coder looking to give Ruby a shot, but the things that make Ruby most interesting won’t be grasped from a PowerPoint chart. Simply asserting things doesn’t cut it.
So, rather than trying to explain a bunch of abstractions, I prefer to show code. Build an app, go over what what the options are as the code grows, show how Ruby makes it easy to go from simple procedural scripts, to well-order classes and objects, to domain-specific abstractions that enable natural expression of application logic. If all goes well, I’ll be able to walk through the design and coding of a simple but useful Web tool that just so happens to make use of blocks, iterators, classes, modules, unit testing, duck typing, method_missing, dynamic class loading, and runtime method creation; all the little things that make Ruby both fun and productive.
I don’t expect people to remember the details, but that isn’t the goal. What I’m aiming for is interest, excitement, and the motivation to go learn more. I don’t care so much that a single person remembers one line of code; the code and slides are going to be available on-line anyway. But if one or two people leave the room thinking, “Wow, Ruby looks really sweet,” and go grab some tutorials off ruby-doc or hop down to the nearest B&N to buy the Pickaxe, then that’s a big win. These people will take the time needed to learn some proper Ruby, get hooked, and then go pester their friends and coworkers about Ruby’s coolness. Mission accomplished.
At the same time, though, I now make a point of avoiding any explicit Ruby advocacy. Sure, if someone asks, “Should I use Ruby?”, I’ll say Yes, but it’s rarely that simple. The question more typically comes framed in some larger description of a complex project, or wrapped in a (not always) subtle challenge to “prove” how Ruby is so much better then @some_language at @some_task.
It’s not that I don’t think these sorts of arguments can be made (though the devil is in the details), it’s just that I’m usually not the guy to make them. Truth is, while I try to keep on top of all ways Ruby can be used for a growing variety of software tasks, I’m generally not interested in tracking the details for any length of time. My brain is too small; I’m much more suited to knowing where to find information should I need it (and, hopefully, recognizing when I need it) than storing stuff in cache memory. I’ve made enough critical evaluations regarding Ruby for the common tasks I face, found Ruby eminently suitable for what I need, and simple see no value in persuading arbitrary strangers that I’ve made the right choice.
Fact is, I really don’t care whether or not you think my language is cooler than your language. I have my gripes with Java, PHP, and, well, every language I’ve used, but getting into some schoolyard pissing contest (and there will be people looking for just that sort of thing) over LOC or configuration files or scalability or which language is more agiley is remarkably unrewarding. “Does Ruby scale?” Scales for me. “Is is more expressive than Blub?” It’s expressive enough for me. “Why should I pick Ruby over [Python|Perl|Java]?” I have no idea. I picked Ruby.
I’d be remiss if I didn’t provide, as part of my final slides and code, references for people who want actual details on those areas, but I can’t think of a more persuasive tool for Ruby advocacy than simple showing off Ruby itself and getting out of the way.
Aaron Seigo, a noted developer for the KDE project, recently blogged about a case for python. The gist is that he feels that python is a suitable language for people to just get into (think VBScript).
This lead to a couple of responses from other KDE developers on the merits of Ruby.
Which came back to Aaron and his response that he in fact hearts Ruby too, though he thinks it doesn’t have the same selling power as python to the VB crowd.
Aaron’s point (at least as I understand it) is that he thinks that the open source desktop communities should try and center around one main scripting language to support, and he think that python has the gravitas to be that language. He even states the case that he prefers Ruby and would personally like to use it instead.
While I think Aaron’s python stoicism is well intentioned, it doesn’t seem necessary. If the history of the open source desktop shows us anything, it’s that that having multiple choices seems to be way preferred way of business. Look at the Ubuntu project, which targeted creating a Linux distribution that set everything up for the end user in one certain way. Oh, there were choices, but the default system was predefined so as to make it quote-unquote-easier for the end user.
For Ubuntu, the preferred desktop was Gnome. It wasn’t long after that Kubuntu was released - a KDE based Ubuntu distribution.
The point is that if the desktop communities unite around python, it won’t take long for a group of rubyists to create a project that does the same thing. Similarly, if the desktop communities unite around ruby, a python project will most likely get started.
The KDE and Gnome projects are already used to this. They have a combined goal, but competing methodologies.
In the language issue, you should just choose whatever works best for you. After all, you’ve already done the same for your desktop.
(Reposted from my blog, at Steve Mallet’s request)
I was IMing with a friend today, and asked him if he was paying attention to the Coverity scan. He told me he wasn’t, and I jokingly commented that it had the potential to be as addictive as fantasy baseball.
Recently, there’s been an outbreak of regularly scheduled hacking
nights within Ruby Brigades. As far as I know, this started a couple
of years ago with the Seattle.rb (and they’re still going strong).
The general idea is that if you hold your meetings on a regular night
(say the 4th Tuesday of the month), then interested Rubyists could
gather on the same weeknight during the non-meeting weeks (so every
Tuesday except the 4th in our example) to hack on Ruby projects.
Now that Ruby’s begun its march towards global domination, it’s appearing on increasing numbers of resumes. That puts most tech companies (including yours, I’d venture to guess) in a weird position, because they don’t know how to evaluate Ruby programmers. Not yet, anyway.
We’ve been here before, haven’t we? Remember back when CGI appeared on the scene, followed almost instantly by CGI.pm, and suddenly every company wanted people who knew Perl? Same thing with C++, Java, C#… a good litmus test for programming-language popularity is whether people bother putting it on their resumes. And for a while after a new one shows up, nobody can tell the wizards from the poseurs.
This is a key juncture for Ruby. If companies start hiring people with “Ruby” smeared all over their resumes, and those people go on to produce brilliant software and generally kick ass, then Ruby gets modded way up. If said Rubyists turn out to be (on average) a bunch of do-nothing kneebiters, Ruby loses big. Rubyists are out there right now, getting set up on blind dates with tech companies, and these first impressions don’t just matter for them; they matter for all of us.
What’s the worst-case scenario? Well, I used to have this friend who worked at a tech company we’ll call “FooCorp”. This is a true story: at FooCorp, the HR department decided to hire a lone cowboy programmer to write a new performance-evaluation tool for the company. The programmer they hired — who had no interaction with the rest of engineering — went ahead and decided to write it in Ruby. With much ado and fanfare, they rolled it out, and with even more ado, a thousand people spent hours entering in their performance reviews. And then, with a truly enormous amount of ado — I mean enough ado to fill several football stadiums — the shiny new Ruby-based perf tool went on a rampage and ate up everyone’s performance reviews. Forever.
Was that Ruby’s fault? Of course not. In fact I, er, that is, my friend met with the cowboy afterwards to figure out whether the disaster could be undone, and the cowboy announced: “WELL, YOU KNOW, WHEN THE SYSTEM GETS ENUFF CHAOS GOIN’ IN THERE, PRETTY MUCH ANYTHING COULD GO WRONG.” And I can’t say he was wrong, either.
Needless to say, Ruby got a bad rap at FooCorp for a little while.
I’d like the Ruby community to start thinking proactively about this problem. I don’t think I’ll come even close to solving it in this blog. Ruby is exceptionally easy to learn — far more so than Perl, C++, C#, Java, or even PHP. Oh hell, I’ll just say it: it’s easier to learn than Python. And that’s quite a feat. It means Ruby’s inevitably going to become a magnet for people who can’t program any other way. Tech companies need our help here. Let’s figure out some ways to differentiate the good eggs from the bad ones.
I’ll offer a few of my own ideas here, but obviously I can only barely scratch the surface in a single blog. I’ll start with some approaches that should work regardless of the language you’re testing for, and then talk about some Ruby-specific tests.
I keep hearing people say they couldn’t possibly use Ruby because it lacks automatic refactoring tools. And although it will eventually have some of them, there’s a class of automated refactorings that are automatable in Java but not in Ruby. This, people say, is a show-stopper.
I wonder.
What exactly is refactoring? I mean, it’s not a word in the dictionary.
Fowler tells us that it’s the art and science of turning smelly code into good code, in small, incremental steps. Provably correct, by construction. Algorithms for giving your code a makeover without breaking it in the process.
He gives us a nice taxonomy. He presents some good techniques, especially geared for Java programmers. Some are things we had already figured out and are habitual, and some of them are new.
Some of these “refactoring” techniques are automatable. And many of them are useful in languages other than Java. It seems Fowler and friends have stumbled on something real, something as big as OOP, almost. Or at least they were the first to market it and package it properly. Either way, we know about it now. Thank you, Fowler and friends!
Refactoring is one of the first programming books I’ve seen that talks about the almost mystical act of writing code. It takes the process, exposes all the insides, revels in it, walks you line by line through oh so many little decisions that affect code quality. These are things most people never talk about. They take them for granted. Most people talk about “architecture”. Refactoring talks about the idioms in the code we write every day. Real now-code, not planned someday-code.
It’s remarkable, really, that nobody talks about this. They leave all the so-called style choices to the programmer. Refactoring rubs our noses in the implications of our line-by-line style choices. Beautiful.
Discovering Refactoring
Refactoring caught my eye in the bookstore one day in 2002, years after it was published. I hadn’t read it because it was published by those UML weenies. I’ve just never been a fan. It has its uses in database modeling (maybe), but I’ve never found it useful in class modeling. And I’ve never cared for the Booch/Jacobsen/etc. crowd’s books.
Refactoring is right there, smack in the middle of that weenie series. Every time I see it, my eyes sweep across the cover without a second glance. You know the old saying!
But one wintery day in 2002, I’m in the bookstore, and I pick it up. No real reason. I’m curious. Don’t know why. Maybe I’d finally heard the word “refactoring” somewhere. What did it mean? It’s not a word in the dictionary.
“Factoring”, sure, that’s a dictionary word. You can factor numbers, or polynomials. Factoring I know. Don’t know why you’d re-do it, though. What’s “re”-factoring?
I open the book. It says local variables are the root of all evil. Perhaps not exactly those words, but it’s the first discussion I stumble across. Local variables!? I plop down in a squashy armchair, outraged, to read more. I want to know if this guy is actually insane, or merely an idiot.
Ruby Brigades are one of the best things to happen to Ruby; they move Ruby into local communities in a way that nothing else can, they create a comraderie and focus for local Rubyists, and they provide an easy on-ramp for people who are just starting to explore Ruby. Perhaps the best part about Ruby Brigades is that, unlike books and tutorials, we can all get involved in making them happen in our own back yards — not only can we, but we should. Let me tell you why.
One thing that has really surprised me has been the consistently high readership of my Rolling with Ruby on Rails tutorials that were published at ONLamp.com over a year ago. Every week the O’Reilly Network Newsletter has a list of the top five articles for the past week, and Rolling with Ruby on Rails has been in the top five list every single week since it was published. Of course, this is really a testament to the strength and popularity of Rails, and not my skills as a writer. I was just fortunate enough to have good timing.
As Steve Mallett wrote a few days ago, Bill Walton has taken this tutorial and updated it for Instant Rails. This is very cool! Thanks, Bill for taking the time to do this.
Last week, 30 Second Rule was asked to speak at a conference of Arizona educators. I. along with Aaron Post and Dan Ritz, spoke on current Web development trends to an audience of about 35 High School teachers who are trying to teach their students Web design and development.
I consider myself fortunate the get the ear of such influential people. Long story short, I talked about (among other things) Ruby and agile development, and had a chance to explain their benefits.
Ruby wasn’t the only language I suggested students use; I was more interested in making an important general point than dogmatically pushing a particular preference.
But I do think there is a reasonable chance that Ruby could find its way into High School curricula (even if informally), along with agile techniques in general and an appreciation of open, rapid, lightweight tools.
It can’t happen too soon; one teacher told me he’s using Visual Basic.
And here I thought there were laws about contributing to the delinquency of minors.
The ruby-doc.org Web site has undergone a transformation. Accolades have been pouring in for the new look, for which all credit must go Dan Ritz, one of my cohorts at 30 Second Rule.
There are still some rough edges. Ruby-doc began life as a blog-based news site that hosted the core API pages and a handful of other docs and tutorials. Over time the number of pages and resources have grown. It no longer makes sense to try to track and announce every new Ruby resource; the Web is awash in them. Instead, the focus needs to shift to making available a robust set of documents and tutorials, and helping people find the information they need to make the most of Ruby.
The growth of the site was somewhat haphazard, making the upgrade more of problem than it really should have been. There may still be some broken or misdirected links, so please bear with me, but feel free to drop me a line (jbritt AT ruby-doc DOT org ) if you find something amiss.
To alleviate such problems in the future, I’ve changed the site to run under Ruby’s wonderful Nitro Web framework, which I encourage others to investigate. Nitro greatly eases the development and maintenance of dynamic Web sites.
And I want to repeat my thanks to those people taking the time and trouble to write Ruby documentation. You folks are life-savers.
I see that Agile Web Development with Rails , and the Rails 1.0 Web application framework, are finalists in the Software Development Jolt Product Excellence Awards.
Congratulations to Dave Thomas and all those busy Rails developers.
And my apologies for the corny title. Hard to resist.
Over on the consistently good Lambda the Ultimate is a discussion prompted by Tim Bray’s posting, Don’t Invent XML Languages.
Somewhere in the LtU thread is a comment from Kay Schluehr::
A family of operators is not a language, not even a dialect. It is at most a jargon ( or gibberish ;)
Ruby is very good for creating DSLs (domain-specific languages), and this comment made me wonder:
Note, Jan 10th 2005 — I’ve turned this and the “anti-anti-hype” post back on. Please see the note at the top of anti-anti-hype. -steve
Gregory wrote:
> Steve, I’m just suggesting not putting fuel on a fire most Rubyists
> never intended to start in the first place.
>
> There is no need for a crusade or jihad here, on either side of the fence.
>
> This post just seems to be painfully biased with the expressed intent
> of bashing Python. That’s just not cool.
>
> Pythonistas are not all tax collectors.
Yes, yes, I know how my “anti-anti-hype” post must have felt. Given that I’m like 600 dog-years old, I sometimes forget the context is missing when I post. I’m going to try once more to explain where I was coming from in that post. If this attempt fails, it’s really no big deal — I can certainly stick to technical blogs.
Incidentally, I’m going to talk about several languages, and eventually make my way back to Ruby at the end. Hang in there.
I think there are some issues we don’t often talk about that have a direct impact on our lives as programmers. Like politics, they’re tricky to talk about without arousing great, fiery passions. I’ll be talking about some of them today. Why would I do that?
Well, first of all, let’s get my agenda out in the open. I’m a programmer, and like you, I love building things. And ideally I’d like to build things in my favorite programming language, which happens to be Ruby — but only by a slim margin, because I love several other languages too, including Python, Scheme, Lisp, the “D” language, C (but not C++), and various others. I like a lot of languages a little bit, and there are only a few languages that I don’t like very much.
As it happens, Python is my second-favorite language.
Yup, that’s right. You heard me properly. I love Python and I think Guido is brilliant. Matz, too. Those guys are just amazing.
My agenda is really simple: I would like to write the majority of my code, at home and at work, in a great programming language.
Well, it’s simple to state. It’s not simple to *do*, for lots of complex and rather painful reasons that should be non-issues, but they’re not. Let’s look at them briefly, and hopefully it will shed a little light on my “uncool” post.
I wasn’t particularly invested in Smalltalk at the time, but I had done some programming in it. Smalltalk was (and still is) a superb programming language. And it died after I learned it.
There are some Smalltalk enthusiasts out there who will point to Squeak and other Smalltalk enclaves, and claim it’s not dead. This is an important point. Chances are, you don’t take Smalltalk very seriously. It’s not on your radar. You don’t think you’ll ever need to learn it. So when I say “I watched Smalltalk die”, to you it sounds like ancient history.
To lots of people, though, especially the ones who loved Smalltalk deeply and whose very livelihoods depended on its commercial success, the failure of Smalltalk is a very painful subject. It’s not boring ancient history. It still hurts them, deeply, and they even maintain hope that it may someday experience a glorious return to popularity.
This pain they feel, which you probably do not, is really close to the heart of our discussion. Hurt feelings are why these issues are so hard to talk about. It’s very easy for you to say something insensitive about Smalltalk, *especially* if you don’t know the language. You can take one look at it and say: “looks dumb”, and you’ve just made someone mad.
What’s really hard is that some people are just mad about Smalltalk in general. You can say anything at all about it, and simply bringing the subject up will have made them angry.
Regardless of whether Smalltalk is really dead, or merely a wounded bear in deep hibernation, I think it’s clear that Smalltalk is not having a direct impact on the programming world today.
Smalltalk has lots of indirect impact, of course — for instance, Ruby inherits a great deal from Smalltalk; all OO languages do to some extent, but Ruby more than many. But you can’t walk into an ordinary computer bookseller and expect to find more than a couple of Smalltalk books. And if you want to get a job as a Smalltalk programmer, you will probably have to travel far, and you likely won’t have much say in the kind of work you get to do. Smalltalk has retreated into a relatively small set of domains, at least for now.
What killed Smalltalk, anyway? I’ve read lots of analyses, and talked at length with some of the key players. The consensus seems to be that Java killed Smalltalk. And it did so rather decisively. Have you ever watched the short animated film “Bambi Meets Godzilla”? That’s pretty much what it feels like now, although it actually happened over a period of several years.
There were certainly other factors involved. Smalltalk had an unusual all-in-one image model, where it acted like your OS, hosting the language, IDE, and application environment all in one binary. That is widely considered unpopular in retrospect, but the irony is that it’s not really much different from the JVM. Smalltalk was commercial, and required user licenses; Java was commercial, but gave end-user licenses away for free. They were really pretty similar, and one wound up being far and away more popular than the other.
You can argue that Smalltalk would have failed fair and square, without Java, but I think most people agree that Java had a LOT to do with Smalltalk’s failure. And it wasn’t a quiet thing, either. Millions of dollars were at stake. There were two large commercial Smalltalk vendors, and a bunch of unhappy about-to-be-ex-Smalltalk programmers, and hallways echoed with roars of protest at how Java, an “obviously” inferior language, had unfairly stolen a market that rightfully belonged to Smalltalk.
It all quieted down eventually, and to a lot of you, Smalltalk probably feels like a niche academic language that never had any real popularity.
I think Java coming along and smooshing Smalltalk had a lot to do with marketing. It’s not the only factor, of course. Timing was a factor in various ways. Syntax and static typing were both factors, because Java deliberately went after disenchanted C++ programmers, which wasn’t a bad strategy at all. And Java had some genuine innovations that helped, too.
But it was marketing that tied all these things together and helped Sun build a worldwide community of millions of Java programmers.
Java wasn’t really offering anything that Smalltalk hadn’t already been doing for years. (Where have we heard that argument before?)
It seems to me that there are two major contributors to language flamewars.
The first is that most programmers don’t like to learn new languages. I don’t know why, but true polyglots like me seem to be comparatively rare, maybe 5%-10% of the programmer population. Most folks apparently prefer to master one language and stick with it for life.
The second is economics. Money motivates most decisions in the end. Companies need to make money, programmers need to get paid. You know all the old sayings: time is money, business is war, money (or love) makes the world go ’round, all’s fair in love and war.
Programmers fall in love with their languages, so you’ve got two of the biggest forces in the world at play here: love and money, mixed with either fear or laziness. Is it any wonder people fight over languages?
Well… sort of. It seems like people should be able to use whatever language makes them most happy. But in practice, you can only use your favorite language if it happens to be C++, Java, Perl, or whatever language(s) your employer has decided are the “official” languages. Most technical employers have a relatively small set of official languages, and you’re forbidden from using any others. There are a few odd things about this situation.
One is that most companies couldn’t care less about programming languages — all they want is to get their products built. It’s always the engineers who impose the language restrictions. They’re not restricting themselves, of course; it’s a situation where engineers are governing other engineers by decree, within the same company. I’ve heard all the reasoning, and it still seems a little odd to me.
Another other odd thing is that most companies are using anywhere from 15 to 40 programming languages, but they only officially recognize two or three of them. They’ll claim they’re a Java/C++ shop, but have huge gobs of shell-script, awk, PHP, Perl, JavaScript, Tcl, emacs-lisp, vim-script, excel macros, pl*sql, and other languages threaded through their tools, databases, build systems, and so on. Maybe this is less true at Windows-based development shops.
And one last odd thing is that programmers often have to learn at least one new language when they arrive at a new job, but they never have any trouble. Programmers only think learning a new language is hard. When it’s a job requirement, it happens amazingly fast. Programmers are pretty smart people, you know.
So why do they fear languages so much? You’d be amazed at how much resistance the “old guard” of a company will offer if you try to use your favorite language, and it’s not on the approved-list. The “old guard” could even be 23-year-old CS grads that have just made a successful startup. “Old” here just means “first”.
I’ve heard their arguments for 20 years. Don’t use C++, it’s slow (my first company). Don’t use Java, it’s slow (my second and third.) Don’t use Python, it’s slow and has that whitespace thing. (All but my most recent.) Don’t use Ruby, it’s weird (90% of all companies). Language diversity is bad. What if someone has to debug your code in the middle of the night and they don’t know that language? (every company, even those that don’t work in the middle of the night) Don’t use other languages; we don’t hire for those skills. We don’t trust those languages. We’ve invested in Fortran or Cobol or C++ or Java or whatever. No, no, no.
“No” always comes from engineers. You build something cool and popular, and your CEO will love you for it. She won’t care if it’s written in Intercal, as long as it works and your team can keep it working. So why do the engineers care so much? Who knows. I think it’s often ego — they think of themselves as a great Java programmer, or an important Perl luminary, or a famous Python person, and they let their perceived self-image influence other peoples’ technical decisions. Whatever the reason, it’s a very real force in the workplace, one that plays a large role in the language wars we see on the internet.
Because, hey, if enough companies are *already* using your favorite language, then the problem still exists — but not for you!
I programmed in assembly language for 5 years at Geoworks; maybe that’s why I love all languages a little. Then C/C++ for a while, and then a long 7-year stint with Java.
After 2 or 3 years with Java, I discovered Jython, which is pretty nifty port of Python to the JVM. I’d been doing a lot of my scripting and auxiliary work in Perl. This is before it had ever occurred to me, still being pretty new, that one language could actually be suitable for most programming tasks. Java’s not very good at many things Perl is good at, and vice-versa, so I had a big mixture of Java and Perl.
I talked in my anti-anti-hype blog a little about Perl’s marketing. It was world-class, and for a while I even thought I liked Perl. The marketing was so powerful that I just took it for granted that I liked Perl.
Jython was a breath of fresh air, and I started wishing I could replace all my Java *and* Perl with it. Development had stopped on it, though, so it naturally led me to Python. For at least three years, Python was my favorite language, but I was heavily invested in the JVM, so I had to settle for Jython most of the time. It sure was fun, even though it was an old, relatively unsupported version of Python.
During those years, I wondered why Python wasn’t as popular as Perl. It seemed like a much stronger language than Perl. That’s just my opinion, of course, and there were certainly things I missed from Perl, so I’m not claiming that Python is the be-all, end-all of language design. But it seemed like the best thing out there.
Why wasn’t it more popular? It seemed to be getting crushed by marketing forces — by fiery-eyed Perl zealots who went around and gained converts, one at a time. Perl was acting like a virus, and spreading rapidly, while Python sort of limped along, growing much more slowly. Richard Gabriel, of course, had already pointed out that C and Unix were virus-like in his famous short essay, The Rise of “Worse is Better'’.
Let’s be careful here: I believe Python has failed so far, and lots of people have jumped to say that Python “beat” Perl. Sure it did, in lots of quality-related ways. But the most immediately relevant metric to me is popular success in the commercial marketplace, because (remember my agenda?) I want to write my day-to-day code in a great language. I can’t just tromp into most companies and announce I’m going to be writing in Python; they’d lynch me. So to this extent, Python has failed. And I really, REALLY wish it hadn’t. Because unlike when it happened with Smalltalk, I was invested this time around.
Because Python was my favorite language, I read lots of Python books, and wrote lots of Python code, and lurked on Python newsgroups, and basically soaked up the culture. And over a few years, I developed my own pet theory as to why Python has (so far) failed commercially.
I know you’re gonna hate this part, but I’m going to talk a little about culture. Culture is very real. It matters every bit as much as love or money.
French waiters in Paris, on average, behave very, very differently from Japanese waiters in Tokyo. It is absolutely undeniable, and the difference is striking. I’ve spent plenty of time and eaten at plenty of restaurants in both places.
Once I was dining with a friend, and he whispered across the table: “I’d ask for some salt, but I think our waiter would kill us.” Which country do you think was I in?
French waiters are not good or bad people, nor are Japanese waiters. They’re just doing what’s acceptable in their culture. But their cultures are very, VERY different. Waiting tables usually has a distinct subculture in any country, so I’m really just comparing the subcultures of French waiters in Paris and Japanese waiters in Tokyo.
I’m going to go out on a limb here, and say that I found French waiters in Paris almost terrifying. They huffed and puffed and stomped and glared and slammed the food down and were so comically over-the-top rude that it *had* to be an act, since my friends and I never did anything but politely sit down and point tentatively at menu items.
In contrast, I’ve seen Japanese waiters go to almost comical lengths to try to accommodate the requests of drunken people on business trips, to the point where I started feeling really un-proud to be an American. Japanese customer service practically defines world-class.
OK, I hope we’ve established that cultures differ, and they have an enormous impact on your experience with people in that culture.
I think it should be obvious to you that programming languages have subcultures, too. The Perl culture is very different from the Python culture, and both are very different from Ruby culture.
The Python culture has a lot going for it. I was pretty immersed in it. But over time, as I wondered why Python wasn’t becoming an overnight phenomenon, I started noticing some cultural behaviors in the Python community that I feel may be partly responsible. This is, of course, just my own opinion, endorsed by nobody.
I pointed out some of these behaviors in my anti-anti-hype blog, and of course some people (Rubyists, Pythonistas, innocent bystanders) assumed I was Python-bashing, because they didn’t watch Smalltalk die, and they didn’t have the context I’m giving you now.
In reality, I’m actually just flat-out disappointed that Python never captured Perl-like marketplace success — and if you’ve been with me so far, you’ll know this has real economic ramifications in terms of ability to write Python code in the workplace. And worse, it appears to be an avoidable problem: I think there are certain accepted practices in the Python world that are materially harming Python’s adoption in the commercial marketplace.
I could spend a long time justifying each of my claims from “anti-anti-hype”, but let’s just focus on one of them: the tendency to label people as “incorrect”. It’s just an annoying habit, but one that can easily drive a potential new user away. It’s a cultural habit, just like stomping and glaring and saying “psh!” loudly is a cultural habit among waiters in small restaurants in the Quartier Latin district of Paris.
The fact is, it doesn’t take very much searching to find examples of this labeling. For instance, Recipe 1.7 of the Python Cookbook ends with a discussion around attributes versus items, and claims that many newcomers to Python “desire confusion”, especially if they’ve come from a JavaScript background.
That seems kinda mean to me. If a programmer is genuinely confused, then fine, they’re confused, although there’s no need to harp on it. But if lots of programmers are asking for a way to solve problems in a way they’re used to, then labeling them as “confused” (a word that dictionaries varyingly define as baffled, perplexed, or unable to think with clarity or act intelligently) seems kinda harsh. Doesn’t it?
Similarly, in Chapter 5 of the “Jython Essentials” book, during a discussion of Python’s class system, it says: “Sometimes people erroneously see the need to explicitly specify the instance in the method argument list as evidence that object-oriented programming is somehow ‘tacked on’ to Python.”
“Erroneously”? Gosh, this issue seems like a matter of pure opinion, not a fact that one can be either correct or incorrect about. How can an opinion be erroneous? Well, it’s a cultural thing. If you have a culture of labeling differing opinions as incorrect, then an opinion can easily be considered erroneous.
There used to be an entry in the Python FAQ, which they removed a year or two ago, that said something along the lines of “Am I allowed to suggest changes to the language?” and the answer was a terse: “No.” I can’t remember the exact wording, but I found it pretty jarring, and it was there for years before getting cleaned up.
These little things add up, and there are lots to be found. You may not notice them at all when reading Python discussions or documentation. I noticed because I was actively looking for people who had tried Python and decided not to use it, and reading their write-ups and opinions. Often as not, they said they felt rebuffed, or felt the community wasn’t welcoming them, or some other touchy-feely type thing that didn’t seem like it should have mattered at all. But there it was: a pattern had emerged.
Are all Python folks to blame for this? Of course not. Most Pythonistas people are really nice, warm, genuine, honest, smart people.
But a culture is a culture, and it has a big impact, like it or not. If the initial experience results in frequent enough culture-shock, it’ll drive a lot of potential new users away.
Feel free to draw your own conclusions about why you use can Perl at most companies, but Python at relatively few. I’ve given you my take on it, and even if it’s not the whole story, I honestly think it’s a factor. There’s more to marketing than glossy banners and shapeless cartoon mascots. Marketing can work all the way down to the level of individuals in one-on-one interactions.
In 10 years, I really don’t want to be able to say: “I watched Python die”. There’s plenty of room for maybe 5 to 8 really huge languages in the marketplace. I think Ruby’s going to be up there soon, and frankly I’d more than welcome Python up there too.
In the meantime, though, I’ve been half-assuming that you can’t change a culture — that once it’s set, it’s set. I hope I’m wrong. But my assumption is one of the biggest reasons that I finally switched to Ruby, just recently, over the summer, and committed to it for the forseeable future. (I’m guessing 5 to 10 years.)
The worldwide Ruby culture is the warmest and friendliest I’ve seen in my long history with programming languages. And Ruby is a sweet language. Other people seem to agree, and are taking steps to market it, which is getting them labeled — rather rudely, it would seem to me — as “hyper-enthusiasts”. As far as I can tell, Ruby is doing what I wanted Python to do a few years ago, so I’ve finally learned Ruby and have switched most of my development over to it.
Both languages have a long way to go before they catch up with Java in terms of tools, IDEs, books, performance, threading stability, and tons of other stuff. I wanted to make a reasonably educated bet, and choose the language I think is going to be bigger, so it’ll work well for me, and so I won’t have to fight so hard to use it in my job.
It wasn’t hard to learn Ruby. In fact after a few days with it, Ruby felt as comfortable as languages I’d been using for years. I’ve really been enjoying it. It has a few warts; all languages do. No biggie. It looks as if Matz is intent on fixing them in Rite.
I don’t know if I like it more than Python and Scheme. I like it at least as much as those languages, certainly. But Ruby’s my favorite (as in “preferred”) language now because I can see the trajectory it’s on, especially now with Rails, and I believe it’s going to be the Next Big Thing — a Java-like phenomenon. So did Bruce Tate when he wrote “Beyond Java”. So do James Duncan Davidson, Dave Thomas, Martin Fowler, and many other people who are a heck of a lot smarter than me. You’d think they’re on to something big, wouldn’t you? I do.
Java-like worldwide adoption really matters. Without that level of mass-market adoption, Ruby won’t get the tools, stability, and CPAN-like library selection that it needs in order to compete with Java and Perl. It’s a chicken-and-egg problem that all languages face, and Ruby stands a chance of succeeding where Smalltalk, Python, and other great languages have (to date) failed.
I see a lot of Rubyists worrying that Rails is stealing the show. Geez, folks, LET it steal the show. Talk about a free ticket for Ruby success. Java Applets were a way to get Java in front of a million or so programmers, ultimately allowing the Java platform to succeed in all sorts of domains that it might never have seen without the initial “killer app” of Applets.
We live in a world where culture matters, economics matter, and marketing hype matters. They are very real forces that directly affect our quality of life as programmers. You ignore them at your peril, a lesson learned by so many almost-forgotten languages that were stomped by marketing hurricanes like Java and Perl.
I really wanted Python to succeed, and I still wish them the best, but I think they’re ignoring marketing. I really want Ruby to succeed, so I get a bit miffed when I hear famous people like Bruce Eckel making uninformed generalizations about both Ruby and the folks who are working hard to make it successful. I think Pythonistas should be focusing on doing the same — working to make Python successful. I do think it will take a minor cultural adjustment on their part. And they need to start accepting hype as a natural part of the world we live in, a requirement for cutting through the noise. But I think they can do it.
With this context, does my “anti-anti-hype” post start to make a bit more sense? Try re-reading it and see.
If not, well, you can’t please everyone. I’m old enough not to mind.
Note, Jan 10th 2005 — I removed this post after receiving enough angry letters about it to make me feel bad for having written it. In the 10 days or so since then, I’ve received angry letters telling me that I’m rewriting history by turning it off, and so on. It’s a lose-lose situation for me. At the risk of becoming the most hated person in blogdom, I’m turning it back on. Please make sure to read the follow-up, “Bambi Meets Godzilla”, before sending me your angry flames. Thanks. -steve
Everyone’s buzzing about Bruce Eckel’s “anti-hype” article. I hope the irony isn’t lost on him.
The thrust of Eckel’s article appears to be that hyper-enthusiasm is diminishing the Ruby camp’s message, and it’s spoiling a good gentleman’s argument. Those darn hyper-enthusiasts are focusing relentlessly on how cool Ruby is and how much they like it, when what’s really needed here is a balanced, objective, neutral, moderated, standards-based, point-by-point, academic discussion of Python vs. Ruby, in which we can all make well-informed decisions, and may the best language win, as long as it’s Python.
Python folks never really did understand marketing.
I’m surprised we need a history lesson here; we’ve all been through this so many times before. But let’s look once again at the basics of language adoption.
First, inferior languages and technologies are just as likely to win. Maybe even more likely, since it takes less time to get them right. Java beat Smalltalk; C++ beat Objective-C; Perl beat Python; VHS beat Beta; the list goes on. Technologies, especially programming languages, do not win on merit. They win on marketing. Begging for fair, unbiased debate is going to get your language left in the dust.
You can market a language by pumping money into a hype machine, the way Sun and IBM did with Java, or Borland did back with Turbo Pascal. It’s pretty effective, but prohibitively expensive for most. More commonly, languages are marketed by a small group of influential writers, and the word-of-mouth hyping extends heirarchically down into the workplace, where a bunch of downtrodden programmers wishing they were having more fun stage a coup and start using a new “forbidden” language on the job. Before long, hiring managers start looking for this new language on resumes, which drives book sales, and the reactor suddenly goes supercritical.
Perl’s a good example: how did it beat Python? They were around at more or less the same time. Perl might predate Python by a few years, but not enough for it to matter much. Perl captured roughly ten times as many users as Python, and has kept that lead for a decade. How? Perl’s success is the result of Larry Wall’s brilliant marketing, combined with the backing of a strong publisher in O’Reilly.
“Programming Perl” was a landmark language book: it was chatty, it made you feel welcome, it was funny, and you felt as if Perl had been around forever when you read it; you were just looking at the latest incarnation. Double marketing points there: Perl was hyped as a trustworthy, mature brand name (like Barnes and Noble showing up overnight and claiming they’d been around since 1897 or whatever), combined with that feeling of being new and special. Larry continued his campaigning for years. Perl’s ugly deficiencies and confusing complexities were marketed as charming quirks. Perl surrounded you with slogans, jargon, hip stories, big personalities, and most of all, fun. Perl was marketed as fun.
What about Python? Is Python hip, funny, and fun? Not really. The community is serious, earnest, mature, and professional, but they’re about as fun as a bunch of tax collectors.
One could write a fat book about this, but just to give you the flavor, consider what happens when you type “python” at a command prompt. It fires up a little interactive interpreter. At the prompt, if you type “quit”, it responds with ‘Use Ctrl-D (i.e. EOF) to exit.’
Well that’s not very nice, is it? It *knows* you want to quit, even going so far as to call you an EOF, whatever that means. (Yes, you and I both know, but is it really the right thing to show to a beginner? Hardly.) Why didn’t it just quit, then?
If you were to bring this issue up on a Python newsgroup at any time in the past 10 years, someone would tersely have instructed you to go look at the FAQ. Or they’d have explained that having ‘quit’ quit would be a strict violation of the semantics of the REPL, which has no a priori knowledge of English, and as Ctrl-D is universally recognized as the EOF char on most terminal emulators, excepting of course broken ones on win32 and VAX platforms, and the interactive shell’s clean design allows the interpreter to treat the input as if it were coming from a file or similar stream, blah Blah BLAH, ergo, the current behavior is correct, quod erat demonstrandum.
Never mind that it’s patently obvious that “quit” should just quit the frigging shell, semantics be damned. They don’t care a whit, because they’re focused on the “right thing” at the expense of the user experience. There’s an old adage for this; it’s called “missing the forest for the trees.”
Of course it’s just as difficult to figure out how to exit the Perl shell, if not more so. But if you were to bring it up on a mailing list or newsgroup, some nice Perl person would come along, eager to show you how to add one more snippet of job security to your lineup of Perl folklore, and would spend an hour explaining how cool it is that you can quit the shell with a single keystroke, one that works in other Unix commands as well, and then maybe show you how to hack the Perl binary so that “quit” also exits the shell for you. The difference is huge: both shells have that crappy misfeature, but Python folks will bore you with justifications while the Perl folks excite you with marketing.
Pedantry: it’s just how things work in the Python world. The status quo is always correct by definition. If you don’t like something, you are incorrect. If you want to suggest a change, put in a PEP, Python’s equivalent of Java’s equally glacial JSR process. The Python FAQ goes to great lengths to rationalize a bunch of broken language features. They’re obviously broken if they’re frequently asked questions, but rather than ‘fessing up and saying “we’re planning on fixing this”, they rationalize that the rest of the world just isn’t thinking about the problem correctly. Every once in a while some broken feature is actually fixed (e.g. lexical scoping), and they say they changed it because people were “confused”. Note that Python is never to blame.
In contrast, Matz is possibly Ruby’s harshest critic; his presentation “How Ruby Sucks” exposes so many problems with his language that it made my blood run a bit cold. But let’s face it: all languages have problems. I much prefer the Ruby crowd’s honesty to Python’s blaming, hedging and overt rationalization.
As for features, Perl had a very different philosophy from Python: Larry would add in just about any feature anyone asked for. Over time, the Perl language has evolved from a mere kitchen sink into a vast landfill of flotsam and jetsam from other languages. But they never told anyone: “Sorry, you can’t do that in Perl.” That would have been bad for marketing.
Today, sure, Perl’s ugly; it’s got generations of cruft, and they’ve admitted defeat by turning their focus to Perl 6, a complete rewrite. If Perl had started off with a foundation as clean as Ruby’s, it wouldn’t have had to mutate so horribly to accommodate all its marketing promises, and it’d still be a strong contender today. But now it’s finally running out of steam. Larry’s magical marketing vapor is wearing off, and people are realizing that Perl’s useless toys (references, contexts, typeglobs, ties, etc.) were only fun back when Perl was the fastest way to get things done. In retrospect, the fun part was getting the job done and showing your friends your cool software; only half of Perl’s wacky features were helping with that.
So now we have a void. Perl’s running out of steam for having too many features; Java’s running out of steam for being too bureaucratic. Both are widely beginning to be perceived as offering too much resistance to getting cool software built. This void will be filled by… you guessed it: marketing. Pretty soon everyone (including hiring managers) will see which way the wind is blowing, and one of Malcolm Gladwell’s tipping points will happen.
We’re in the middle of this tipping-point situation right now. In fact it may have already tipped, with Ruby headed to become the winner, a programming-language force as prominent on resumes and bookshelves as Java is today. This was the entire point of Bruce Tate’s book. You can choose to quibble over the details, as Eckel has done, or you can go figure out which language you think is going to be the winner, and get behind marketing it, rather than complaining that other language enthusiasts aren’t being fair.
Could Python be the next mega-language? Maybe. It’s a pretty good language (not that this really matters much). To succeed, they’d have to get their act together today. Not in a year, or a few months, but today — and they’d have to realize they’re behind already. Ruby’s a fine language, sure, but now it has a killer app. Rails has been a huge driving and rallying force behind Ruby adoption. The battleground is the web framework space, and Python’s screwing it up badly. There are at least five major Python frameworks that claim to be competing with Rails: Pylons, Django, TurboGears, Zope, and Subway. That’s at least three (maybe four) too many. From a marketing perspective, it doesn’t actually matter which one is the best, as long as the Python community gets behind one of them and starts hyping it exclusively. If they don’t, each one will get 20% of the developers, and none will be able to keep pace with the innovation in Rails.
The current battle may be over web frameworks, but the war is broader than that. Python will have to get serious about marketing, which means finding some influential writers to crank out some hype books in a hurry. Needless to say, they also have to abandon their anti-hype position, or it’s a lost cause. Sorry, Bruce. Academic discussions won’t get you a million new users. You need faith-based arguments. People have to watch you having fun, and envy you.
My guess is that the Python and Java loyalists will once again miss the forest for the trees. They’ll debate my points one by one, and declare victory when they’ve proven beyond a doubt that I’m mistaken: that marketing doesn’t really matter. Or they’ll say “gosh, it’s not really a war; there’s room for all of us”, and they’ll continue to wonder why the bookshelves at Barnes are filling up with Ruby books.
I won’t be paying much attention though, ‘cuz Ruby is soooo cool. Did I mention that “quit” exits the shell in Ruby? It does, and so does Ctrl-D. Ruby’s da bomb. And Rails? Seriously, you don’t know what you’re missing. It’s awesome. Ruby’s dad could totally beat up Python’s dad. Check out Why’s Poignant Guide if you don’t b’lieve me. Ruby’s WAY fun — it’s like the only language I want to use these days. It’s so easy to learn, too. Not that I’m hyping it or anything. You just can’t fake being cool.
It appears that Microsoft is looking for people to work on IronPython and dynamic language support for the CLR.
Having Ruby apps run as native .Net code would be quite nice.
Found via Bill de hÓra
I wrote a couple of entries in this fancy new O’Reilly Ruby blog, and placed them in the “Opinion” category, which I evidently completely misunderstood to mean that it was for posting opinions.
Silly me. After this little follow-up, I’ll endeavor never post an actual opinion to a public forum again.
It turns out that the little “Opinion” label is far more widely construed to mean either “Universally True Factual Statements” or “Lies”, either of which appears to be grounds for getting Really Mad. It seems MovableType ought to have a little dropdown list for labeling your comments, providing convenient label options such as “Revenge”, “Retaliation”, “Retribution”, “Flame Strike”, and “Long List of Corrections”. Ideally it would allow you to select multiple comment categories.
Note: I will receive angry comments for that previous sentence, and also for this one, and for everything else I write for the rest of my life that makes it online, advertently or not. So will you, if you ever make the profound mistake of choosing that “Opinion” category in a blog post. You’ll also be quoted out of context all over the web, because apparently by choosing “Opinion”, you are also claiming that you are a Leading Expert at whatever random thing you’re talking about.
I’ve been a huge fan of Dave Barry’s writing for almost 20 years, but as of last week I have newfound respect for the man. He often points out that Alert Readers regularly send him angry factual corrections and even hate mail about his humor columns. How did he put up with it for his whole career? I’ll never know.
I’ve learned a few things in the past week. They are Universally True Facts! Ignore them at your own risk!
One is that if you ever opinionatedly claim that a specific group of people tends to be pedantic, something interesting happens: a whole bunch of people will pedantically inform you that you are incorrect. But they’re not just from the group you mentioned; they’re from everywhere. Pedants will materialize from every dimension to correct you. The corrections vary, of course. Some folks will just be negating what you said, occasionally colorfully. Some will announce that the *other* group (there’s always another group; people love taking sides) is even *more* pedantic. A few will announce that I’ve slightly misused the term “pedantic”, thus invalidating my entire article.
I’ll vouch one of my last-ever opinions: namely, that “correcting” someone’s opinion is automatically pedantic. Corrections inevitably overlook the basic problem that all communication is intrinsically ambiguous. Also, the shorter a statement is, the less universally true it becomes. So if you narrow in on any statement that someone makes, ignoring the surrounding context and failing to give some benefit of the doubt, you’ll always be able to find things to correct. But chances are good that you’ll also have missed their point.
Anyway, I’ve since realized that my opinionated claim wasn’t broad enough. Almost any arbitrary grouping of people connected to the web will have a tendency to appear pedantic, because the most pedantic people are very eager to post corrections (by definition), giving them a more vocal presence than their less pedantic and more forgiving peers. Plus, almost everyone is pedantic once in a while, depending on their mood that day.
By dropping just one word from the first of my two most infamous claims, I arrive at the slightly less incorrect opinion: “Pedantry: it’s just how things work in the world.” In the written, online world, anyway. Useful to know!
In an effort to partly forestall a flood of amusing corrections from pedants on the sharp lookout (a.k.a. “skimming”) for errors here that they can denounce, I’ll make the following statements of True Fact:
- I am a poorly-educated yokel, and I’m not an expert at anything.
- I speak only for myself.
- My opinions change daily, and I articulate them poorly.
- Everything I write is a baldfaced lie, except for the stuff you agree with.
- You’re right.
Feel free to quote me directly on any of those statements, by the way.
The other big thing I learned, related to my second infamous claim, is that people evidently *really* detest tax collectors, more so than I’d ever have guessed. Politicians, take note.
OK then! No more opinions from me, ever again. And I hereby revoke all previous opinions that I’ve ever stated or held at any time, however briefly. And as a nice catch-all algorithm, let’s agree that if I ever again accidentally voice something resembling an opinion or a possible factual error, whether you agree with it or not, then we’ll just assume I’m wrong and you’re right.
I suppose I should say something about Ruby, in keeping with the theme of this blog:
I like Ruby, but I miss list comprehensions from Python.1
However, some quick searches seem to indicate that someone somewhere has implemented them for Ruby, somehow. I guess I’ll go take a look!
<forever>
</opinion>
</forever>
[1] attention, pedants: I also miss them from Haskell.
I will try not to turn this entry into a rant, because we’ve seen plenty of that as of late.
However, I would like to share my experience regarding Ruby and the communities I’ve encountered in order to represent a sort of difference between the enthusiast and the hyper-enthusiast.
I will not make comparisons to other languages, because frankly, they aren’t relevant. I will however mention that I first played with Python 6 years ago and after about a year of tinkering went straight to Perl and stayed there until a little less than two years ago.
Upon finding Ruby, I was amazed by the language, but even more so by the community. A year and half ago or so when I started playing with it, I had never heard of DHH or 37 Signals or Rails or anything like that. I was enticed by my friend James Edward Gray II to learn the language, and soon thereafter began lurking about RubyTalk.
Soon I saw some names coming up a lot, both in conversations and in posts by the individuals themselves, such as David A. Black, Hal Fulton, Curt Hibbs, Chad Fowler, Jim Weirich, James Britt, and of course _why. This is just a random list of people who I noticed quite rapidly, but basically, these were people who came to Ruby before the Rails explosion, and they all have made significant contributions to the Ruby community.
There are hundreds of people I’ve spoken to in this community who have made some wonderful contributions to Ruby. Many of them are regulars on RubyTalk, some I’ve met at Ruby Users Groups (Such as new_haven.rb or NYC.rb), some I met at the RubyConf this past fall. These folks are what forms the core of the Ruby community.
In the last 3 to 6 months, there has been an incredible amount of buzz regarding Rails. It seems now, that the number of people who are interested in Rails moreso than Ruby, or those who are interested in Ruby because of Rails outnumbers the smaller core of those who just love Ruby. That doesn’t bother me one bit.
Part of growth is accepting the changing face of a community. As our userbase changes, the needs, interests, opinions and desires are sure to change as well. The only issue is that of identity, of reputation. I do not want to be lumped in with the hyper-enthusiast, if the meaning of the word is faith based decisions.
I also don’t want everyone who knows I’m into ruby to assume I’ve mastered Rails and that I love it as much as they do. I haven’t and I don’t. Rails is very nice, and I’m at the beginning of a rather large scale project in it, but to me, it’s just another impressive piece of Ruby software. No amount of marketing or hyper-enthusiasm is going to change my opinion on this. Maybe when I’m done with my project, I’ll have some substantial experience based opinion on it, but as for now, I’ll leave the defining word on Rails to those who know it and use it best.
The core issue here is that the level of noise is rising and rising in the communities. Or at least, some of us percieve it as noise. Do we really need to sell ruby? Do we really need to focus on standardization and point for point comparisions between language Foo and Bar? In my experience, Ruby sells itself. If you want to impress a potential employer, show them some software written in it, show them some things you’ve done. Prototype something quickly and cleanly and let them see it up front.
All this time that some very vocal members of the community spend ‘defending’ ruby or preaching it’s wonders from the mountaintops, myself and many others spend doing ruby. To me, that’s worth a lot more. To others, maybe it’s not. I have no problem with this difference in opinion. I just need to make it clear that I came to Ruby before it was cool, and even if people were calling me a tax collector, or even comparing me to a COBOL programmer, I’d still love it.
If you want to support Ruby, let it speak for itself in beautiful code. That is far louder (and far more useful) than faith based words. So this might have turned into a bit of a rant after all, but I just needed to speak up a bit for the Old School Rubyist, who doesn’t give a damn about what loud people on either side of the fence are saying.
No doubt Rails is becoming popular - just looking at the number of folks joining the ruby-talk mailing list and asking Rails specific questions. It’s happening very frequently now - I think mainly because of the confusion between what is Ruby and what is Ruby on Rails. For the most part, they are kindly directed over to the Rails mailing list for better help with their questions. However, the frequency of this question and reply session is picking up dramatically. Thus, it seems like the most natural solution is to rename either Ruby or Ruby on Rails to something that helps differentiate between the two.
I’m just kidding about renaming the projects. But the comment board is open - hit us up with some of your (humorous) thoughts.
Tonight, the Utah Ruby Users Group had its monthly meeting. We’ve been hovering aroung 20 attendees for several months now, with a traditional presentation format. This month seemed like a good time to do something different, so we decided to try a more hands-on meeting.
Jamis Buck (of Net::SSH, Needle, and Rails fame) put together several ‘topics’ that we could pair up and hack on. The idea was to let people pair up and work on things that were interesting and skill level appropriate, and at the end of the night compare notes on how pair programming and strict test first programming worked for people.
I don’t know if it was the meeting plan, or the proximity to the holidays, but things didn’t work out like we’d hoped. Only about 6 people showed up, and the hacking topics didn’t really appeal to us. One of the attendees had a question about getting AJAX working in a little Rails app he’d been working on though, so Jamis led an impromptu 90 minute session on using AJAX in Rails. (I guess that’s what being agile is all about.)
For January, we’re going back to our old format. I understand the presentation will be about Ruby/Cocoa. Whatever it is, I plan on being there. With this group, missing a meeting means you’re really missing out.
Are you involved in your local Ruby Brigade? If not, do you know what you’re missing?
A few nights ago I had the good fortune of leading the first Phoenix Ruby Users Group meeting in many months, and the difference between this one and the previous meeting were amazing. Expecting to see maybe eight or ten people, a fairly sizable training room (graciously provided by Cyclone Commerce) was completely filled. By rough estimate there were 25 to 30 people. Were in the world did they come from?
A bit of history: I came to Ruby sometime in 2000 or 2001. It was probably Dave Thomas’ article in Dr. Dobbs that piqued my interest. I remember browsing through a copy of the first edition of Programming Ruby at a local Barnes & Noble, and being put off by some of the syntax, but, for reasons now unknown, I gave Ruby another shot. Part of learning Ruby was getting active in the Ruby community, which meant lurking, then participating, on the ruby-talk mailing list, and learning about the main Ruby Web sites, such as Ruby Central and Ruby Garden.
Some time early on, interested in meeting other Rubyists, I added my name to the Ruby Garden wiki page for the Phoenix Ruby Users Group. There were, I think, two names already there. I may have tried sending E-mail to these people, but nothing ever came about. It wasn’t until early 2005 that, hearing that people were doing well using (then free) Meetup.com to organize user groups that I did actually attend my first Phoenix meeting. On the up side, I met great people (in fact, it led to my joining them in the Web design and development company, 30 Second Rule ). However, over the course of three or four meetings, it was always the same three people, and the user group, as such, just dissolved. Though the Rails Summer of Hype meant Ruby was getting routine attention on various Web sites (such as Slashdot, and here on O’Reilly), it seemed as though Phoenix was just never going to be a hotbed of Ruby activity.
However, a few months ago, a few folks from some local companies began to realize that indeed there were a number of interesting people and companies here in the Valley of the Sun , but for the most part they were operating in complete ignorance of one other. Copping a tune from Refresh Dallas, Refresh Phoenix was born, with the goal of bringing together Web developers and designers in a relaxed social environment so we could meet, get acquainted, learn new things, and share ideas and experiences.
The first meeting in November went great. Our fears of pitiful turnout were completely unfounded; there were probably 25 to 30 people there. It turned out that many people were thinking the same thing, and were eager to get out of their cubicles and actually talk with people, face-to-face.
The big surprise for me, though, came as we asked everyone gathered to say a bit about themselves, what they do, and what things were they interesting in. Probably half a dozen people mentioned Ruby or Ruby and Rails, saying either they were just getting started or looking learn.
At the second Refresh Phoenix meeting I announced that I was looking to revive the Phoenix Ruby group; before I left I collected a dozen names. Shortly afterward I made plans for our first meeting, expecting perhaps eight or ten of those on my list to show up, as well as a few folks from Cyclone Commerce. I was mistaken.
The meeting was scheduled to begin at 6:00 PM, and by 6:15 PM nearly every seat in the good-sized training room was taken. Wow.
Since this was largely a Get Acquainted and Figure Stuff Out meeting, I asked if each person could say who they were, how much Ruby they knew, and what they hoped to get from the group. The responses were somewhat surprising. Most people had taken a stab at Ruby coding, but were just getting started. That made some intuitive sense. I was really expecting to hear a room full of people telling me they all wanted to learn Rails. But, while that did get some mention, most people expressed a primary interest in learning Ruby itself, in expanding their general programming skill set. Some wanted to get away from Java, some wanted a better understanding of meta-programing with a dynamic language. But the interest was in Ruby itself, not some particular framework or application.
Since so many were new to Ruby, I offered up some resources. By a show of hands, though, most of the room seemed unfamiliar with the ruby-talk mailing list (home to the world’s friendliest developer community) and most of what I consider the better known Ruby Web sites. So here was a room full of people, many of whom were already somewhat familiar with Ruby, many of whom had taken steps to learn Ruby, yet were not even lurking on ruby-talk or surfing the Ruby Garden wiki. (Thankfully, at least some folks already knew about ruby-doc.org.)
The meeting went great, and I’m looking forward to the next one, in January. It’s really nice to be around so many people so interested in expanding their horizons.
I think one tends to get the impression that the discussions on ruby-talk, or on Slashdot or O’Reilly, or on the many Ruby blogs, somehow represent the “Ruby community”, but the reality is that there are good numbers of people actively interested in Ruby, but unaware or indifferent to certain public forums and currents. This suggests that while activity on the main outlets correctly indicate a growing interesting in Ruby, the real numbers are much larger than may be readily apparent. And the comments from people I spoke with suggest that while certain topics and tool sets get a fair amount of public buzz, there is tremendous interest in all the myriad aspects of Ruby.
If you are a publisher, you may want to rethink jumping on whatever is the current bandwagon for your next Ruby book. People want to know all about all of Ruby. And if you are part of a company looking for developers, thinking that Ruby may give you an edge, but concerned about finding people, know this: There are far more Rubyists than you know.
I thought that “Hello World” would be very appropriate for my first post to O’Reilly’s new Ruby blog.
What got me thinking about this was a very funny article I just read that showed how the form of a Hello World program changes as the developer progresses in his career. Here are a few excerpts:
High School/Jr.High
10 PRINT "HELLO WORLD"
20 END
First year in College
program Hello(input, output)
begin
writeln('Hello World')
end.
Senior year in College
(defun hello
(print
(cons 'Hello (list 'World))))
New professional
#include
void main(void)
{
char *message[] = {"Hello ", "World"};
int i;
for(i = 0; i < 2; ++i)
printf("%s", message[i]);
printf("n");
}
After this they get too long to post here, but its really hilarious. I especially liked the "Master Programmer" example which was an MS COM/C++ program (which brings back painful memories).
As these Hello World programs got progressively more complex, it made me think about how the Ruby version returns to utter simplicity:
puts 'Hello World!'
Which is much better than the Java version (my previous language of choice):
// Must be stored in a file called "hello.java"
public class hello {
static public void main(String[] argv) {
System.out.println("Hello world!");
}
}
Even in Ruby, a Hello World program can be educational, judiciously showing off some of the language features. My favorite such Hello World program in Ruby is:
# The Greeter class
class Greeter
def initialize(name)
@name = name.capitalize
end
def salute
puts "Hello #{@name}!"
end
end
# Create a new object
g = Greeter.new("world")
# Output "Hello World!"
g.salute
That nice little piece of Ruby code was written by either John Long, Ben Giddings, or Michel Martins — I can’t remember which one, so I mention all three.
Anyway, go read the Hello World Programs page and have a little chuckle!
Bruce Eckel really doesn’t like Ruby. I don’t know why he doesn’t; I know he’s explained it in the past. Yes, there’s a lot of enthusiasm around Ruby and Ruby on Rails lately: this group blog has certainly been created because of this enthusiasm. But the enthusiasts and the detractors both distract from the larger reality that there’s never going to be a single programming language that is best suited for all projects.
The problem is that some people—this includes some Rubyists—who think that Ruby is in a language war with Python (or Java or…) and that “there can be only one.” Unlike Highlander, this isn’t a zero-sum game. While the Rails crew can be extremely enthusiastic about Rails and Ruby, few of them pretend that Rails is a silver bullet for every problem. Rails is a targeted application framework that takes advantage of—and perhaps even extends—the opinionated and expressive nature of Ruby.
As I work on PDF::Writer, I freely admit that its origin came from the R&OS cPDF library written in gasp! PHP. I’ve taken it far beyond cPDF, and I have looked at Perl’s PDF::API2, Python’s ReportLab, Java’s iText (and the C# port iTextSharp), and will be looking at CL-PDF for Common Lisp (if anyone has other open source libraries that are worth studying, please let me know) as I formulate both the implementation and the API of PDF::Writer and its future companion projects (PDF::Core and PDF::Reader).
I believe that I work smarter in Ruby than in any other language I’ve used so far, and it makes me happy. That doesn’t mean that everyone will work smarter in Ruby or that it will make them happy. I personally don’t want Bruce to use Ruby—why would you use something that doesn’t make you happy? If Ruby didn’t exist, I would be a bitter Python developer. There are things about the Python language (whitespace scoping) and the Python community (there’s only one “right” way to do it) that made me turn away from Python as soon as I saw that there was a viable alternative (modulo libraries, of course, but that also meant that I was able to jump right in and start offering libraries to the community). Would Bruce want me to be part of the Python community if I were bitter about Python’s warts? Somehow, I doubt it.
I think that the strength of the Ruby community is that it (mostly) recognises that it isn’t a zero-sum game. We’ve been around the block, most of us, and don’t think that there’s a single answer. We just know what makes us happy right now.
A few weeks ago Martin Fowler started a miniature firestorm by putting an entry in his bliki about Humane Interfaces. The irony was that the negative opinions it generated were not so much about humane versus minimal interfaces, but about the fact that Ruby’s Array class has 78 methods versus the 25 declared in Java’s java.util.List class.
The main critic of Ruby’s Array class was Elliotte Harold, who among other things called it “about three times as bad as a 25 method List class.” The thing is, as a Java programmer I can understand Mr. Harold’s arguments, and I think they might be valid in Java. But they are not valid in Ruby. You see programming in Ruby is a completely different experience to programming in Java. I should know, as I like to say I was “born and raised” on Java (it was my first major programming language), yet I’ve also been programming Ruby since 2001.
One of the biggest differences between the two languages is Java’s static versus Ruby’s dynamic typing. This is also one of the biggest reasons a 78 method Ruby class is perfectly fine in Ruby (I would go so far as to say wonderful) whereas the same in Java might be a nightmare. Let’s take a look at a code example (from IRB, aka Interactive Ruby):
irb(main):001:0> list = []
=> []
irb(main):002:0> list << 1
=> [1]
irb(main):003:0> list << "two"
=> [1, "two"]
irb(main):004:0> list[0]
=> 1
irb(main):005:0> list.last
=> "two"
irb(main):006:0> stack = []
=> []
irb(main):007:0> stack.push "a"
=> ["a"]
irb(main):008:0> stack.push "b"
=> ["a", "b"]
irb(main):009:0> stack.pop
=> "b"
irb(main):010:0> queue = []
=> []
irb(main):011:0> queue.unshift 1
=> [1]
irb(main):012:0> queue.unshift 2
=> [2, 1]
irb(main):013:0> queue.shift
=> 2
Here I have list, stack and queue data structures. Yet they are all really Ruby Arrays. Nowhere above do I need or care about what actual class these objects are, I just call the methods I expect and things just work. This is frequently called “duck typing” in the Ruby community (and I’m sure other places), because as long as it quacks and walks like a duck, we are happy. In other words, an object only need respond properly to a given set of methods to satisfy the programmer’s requirements. Whether it is an Array or a QuizzleBick under the scenes is irrelevant.
This is where Mr. Harold’s Java prejudices show most obviously, and also it is clear as crystal that he is not a Ruby programmer, and he just cannot “get” what it means to be one. He is so upset by Ruby’s Array class behaving like a List and Stack and Queue that he fails to see how perfectly this idea fits in with Ruby and the way it is programmed.
In the same way that learning new programming languages can open one’s mind, it seems using one for too long can close your mind as well.
© 2013, O'Reilly Media, Inc. (707) 827-7000 / (800) 998-9938 All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners. |
