::Straight talk about rails:: [/tech/ruby] (17:27)

I'm not ashamed to say that I'm not a fan of Ruby on Rails. I think it's a step backwards in web framework design, but the thing that's turned my off the most is the unapologetic fanboyism around it that seems to inhibit critical thinking skills in otherwise bright developers.

However, I've always maintained that Rails might actually start being an interesting platform when the fanboy mentality breaks down and you start seeing public criticism of it from within the community. You still don't see much of that, so I was quite surprised to hear the honest talk about the weaknesses of Rails in episode 92 of Drunk and Retired.

I'm not mentioning it to cackle with I-told-you-so glee. The point isn't that Rails has problem points, but that you are starting to hear people admit that the Rails-lifestyle isn't all fun and games. That's the point at which you can truly examine Rails for it's technical merits and weaknesses and make an unemotional decision about whether or not it is suitable for a given project.

::Teaching my kid Ruby:: [/tech/ruby] (13:45)

My son is 8, and I've been wanting to get him started programming. I taught myself BASIC programming on a VIC-20 at 10, so I know it's quite possible for young kids to understand the basics of programming. With a simpler environment and some actual instruction, I certainly think it's possible to get started at his age. But, I never was quite sure how to go about it.

Last week, I discovered a JRuby-powered turtle graphics environment that I thought would be fun. Last saturday, we spent some time with it, and I was quite pleased to see how easily he was able to get into it. It's very easy to grasp the concept of loops and functions when you can relate them to something visual on the screen. There's enough room here to work in the concept of variables later, so it seems like you can get a pretty solid intro to programming techniques through it. It will be interesting to see if the environment can keep his interest long enough to get to more advanced ideas.

The app itself is a little primitive. It worked well enough, but I did need to babysit a lot more when things got stuck. I don't think you could leave a younger kid in front of it without close supervision. Ruby syntax is well suited for this sort of primitive interaction. Though Ruby can be rather awkward at times, it's mostly hidden here. The error messages are definitely not kid friendly, and probably would be tricky for anyone who didn't know Ruby.

All in all, it was a great afternoon. If you've been looking for a way to introduce programming to younger kids, definitely check it out.

::site directories and programming languages:: [/tech/ruby] (00:28)

Spending the weekend in Ruby-land has made me think a lot more about the possibility of developing applications in Ruby. One of the biggest problems, as I see it, is the role that site-ruby plays. If you aren't familiar with site concept, the idea is that there is one place on the system that third party libraries can be placed. Once placed there they can be accessed from any ruby application. The java equivalent would perhaps be lib/ext, but anyone suggesting placing libraries there for a shared JVM install would likely be shot on sight. (perhaps even on site)

I can see the role that a site install directory plays in providing an end tool. Emacs has a site install directory, for example. It makes sense to install add-ons to tools in a site-wide manner. But I think it's just plain wrong to pollute the language install directories with third party libraries.

As a programmer, I want to know that I can count on a standard, pure environment. I don't want to tell you users that they need to install 10 additional modules just to run my app. I would prefer to provide them myself. As a user, I don't want to have to allow third party libraries to write into my install directory. And, I certainly don't want ot "sudo ruby install.rb". Yuck! One of the reasons I refuse to use perl is the need to compile in 500 third party libraries to run perl programs. I'm not eager to start doing that for the sake of ruby either.

Maybe this is my Java bias showing, but Java definitely has the right approach here. (even if the details are messed up) In the Java world we still haven't figured out how to version jars in a useful way or how to declare dependencies in anything more clever than brute force classpaths. (well, I guess there is JNLP) However, the general approach of bundling code into jar files local to the application being run seems to solve a lot of problems. (at least I don't have to sudo to make anything run) I'm told .NET assemblies are a better approach, but I just can't motivate myself to really care about anything happening in the .NET world.

I should ntoe that I did see something this weekend called a ruby gem file for packaging ruby libraries. But it looked to me like the gem file was more like an RPM than a jar file. If that is true, I think it is the wrong approach. The goal shouldn't be to make it easier to instlal libraries, but to make it unnecessary to install libraries. But that's just my opinion...

::RubyConf, here I come :: [/tech/ruby] (07:27)

Ruby has been my toy language for the last few months. I've done a number of my side projects in ruby and have been doing some of my protyping at work in Ruby. I'm not a Ruby guru by any means, but I'm getting proficient. I'm definitely interested in learning more, so I was quite excited to see RubyConf is being held here in Austin. I really don't know what to expect, but these kinds of conferences are usually fun.