Somebody asked over at JoS: "Are other professions this self-involved?"

The thread is at http://discuss.joelonsoftware.com/default.asp?joel.3.592501.5

Here's my answer:

Some might say IT is about working with logic. I'd say IT involves a great deal of reasoning. The reasoning involves communication, reflection, experimentation... IT can both produce a lot of content and consume a lot of content, in many forms, even comics. :-) IT kind of requires a certain level of interest from the participants, and some intelligence helps people in maintaining the interest for longer periods which makes the IT experience, be it in blogging, working, discovery... more exciting to the participants. IT is a new age kind of industry. I was watching today on the National Geographic channel the evolution of the communication up to the discovery of the optical fiber, which is the basis of the Internet. This is all so new, and yet, our lives are so short. :-)

IT can be more recursive than other industries. Whatever that means. :P

IT is renewing itself all the time. IT knowledge can become a little obsolete fast, but the tools of the trade can lose their prestige much faster than the knowledge of course. At the same time, IT requires knowledge from its participants and due to the evolution of things, it falls short of teaching people beyond some minimum knowledge. After school, people start specializing for the job at hand. The specialization each one does is just one in a big universe of specializations. This creates some tunnel vision. And yet, each job can vary greatly from one another, for the same person. Many jobs are not stable.

What other industry is like IT? None.

That's why analogies fall short when comparing apples and oranges of professions and industries.

Rubinius: With great power comes great responsibility.

Somebody else was wondering about Rubinius and MRI and their future at:

• What will Matz do? - http://matt.blogs.it/entries/00002788.html

The question was: "Could he make the switch and adopt Rubinius as the new MVM?"

With great power comes great responsibility.

Maintaining a development tool, like a programming language with its core libraries and even other important libraries or standard libraries, can be quite a challenge. Add to it conferences, books, community, support, decisions and more decisions, it's not a thing for the weak.

Matz and MRI have proven themselves up till now, even though there are barriers like actual language (Japanese), geographic (Japan), and even cultural, that impose some extra difficulty.

It's my understanding that some things in life can be quite hard to understand, unless you have done them yourself. It's easy to judge and to want things to improve. It's much harder to bite the bullet and to do the right things for years, even decades, with little recognition and other kinds of feedbacks.

Rubinius is just starting out. It needs more than just a good philosophy, it needs much work, probably for years to come. Think decades even! On top of that, it shouldn't screw with those guys who made Ruby what it has become. Ruby is not just a Web development platform, even though it works great for it. Ruby was a way of creating higher level programs than C allowed. Ruby was about trying to free developers of much of the low level of C programming.

Rubinius is in its very early days. When users can use Rubinius on Linux, Windows, Cygwin, MacOSX, FreeBSD, and more, it will be taken more serious as a replacement for MRI. Does Rubinius want great power? Then when tens of thousands of users start using it, Rubinius will have to deal with great responsibility as well.

For the time being, I want to see Rubinius at least working on as many platforms as it can. Rubinius should not be just a "PHP killer" if it wants to be a general purpose tool and worth of displacing MRI as the main Ruby implementation (outside of things like Java and .NET, that is).

In general, MRI has a great lead. Rubinius developers need motivation to close the gap, but they will need time as well.

Why functional programming matters? Asks Haskell's mastermind

And you can answer it at:

• http://groups.google.com/group/fa.haskell/browse_thread/thread/40221a24b1f31422/9e5cd81e0bfa89d0?lnk=raot#9e5cd81e0bfa89d0

The answers are pretty uninspiring to me, all in all!

Meanwhile, here's the review done by someone else on a practical Ruby book:

• Practical Ruby Projects - http://on-ruby.blogspot.com/2008/01/practical-ruby-projects-review.html

Much more inspiring, I'd say. :-)

If you are up to it, see the videos of Dave Thomas and Kent Beck on InfoQ also:

• Pragmatic Dave on Passion, Skill and 'Having A Blast' - http://www.infoq.com/interviews/dave-thomas-agile-passion
• Kent Beck on Implementation Patterns - http://www.infoq.com/interviews/beck-implementation-patterns

Dave Thomas is over fifty! He has done nicely so far and passed the baton to a bunch of younger folks by means of training, teaching, supporting with software, documenting... But he is not a "Ruby guy". :-) He mentions that he feels a little nervous when folks mention that they are like a "Java guy". Programming languages come and go, the job markets come and go, and the tasks might demand different approaches. Being just a "very focused on a technology kind of guy" can be detrimental to the objectives and opportunities. And things change, rest assured. :-)

Lambda the Ultimate has a fun discussion including programming languages:

• Prediction for 2008 - http://lambda-the-ultimate.org/node/2600

Come what may, I say. :-)

I didn't know parsing could be such a hard job :-)

I was trying to use Treetop to parse my Wiki syntax, and it made me realize how hard such a task could be. I think this particular syntax does not suit Treetop very well.

In the process I have just grown a little tired of trying to use Treetop to do any parsing job I could have. It's not always an easy task, but it somehow felt good when I used it to parse the subset of SQL I care about. Albeit now I see that things like possible left recursiveness, too flexible syntaxes (like "

<<EOS [...] EOS or <<any [...] any

"), and other complexities can make it less fun.

For now, I am going to keep my hand-crafted parsers as they are tested in the field, and departing from them may cause incompatibilities and possibly other problems for me. :-)

Why, oh why? :-)

Having taken a look on rparsec and Ragel, I think I'm gonna resume my work on Treetop

rparsec seemed too complex for me to grasp at a glance. Ragel seems by design less adequate than Treetop for recursion.

They are all cool technologies. Each has some strong points, and in the hands of skilled people can be made to sing and dance all night long. :-)

But Treetop just feels too good to be true, and if I can make it to work, the simplifications will be worth the trouble. And in the end, I know I'll reach for Treetop in more occasions, as it's so easy to use. If I used something more complex, it would be used less often. For example, while starting a new parser manually is easy, the continued development is rather troublesome. Treetop on the other hand works at a higher level, giving an example to the "keep it simple, sir". :-)

If Treetop despite being a little slower can help me with correctness, it's worth the trouble, definitely!

Thanks for Treetop, Nathan Sobo! He is the author.

Experimenting with Treetop

Treetop is a new generation kind of parser generator:

• Treetop - PEG parser generator for Ruby - http://www.infoq.com/news/2008/01/treetop-ruby-parser-generator

It's a cool paradigm which builds on top of regexes and makes recursion easy, and more than that, it makes building the parser really straightforward.

But it feels a little slow once you already have an alternative. Like, I have a custom SQL parser which I use to build an AST which is possibly manipulated and then the SQL is regenerated to be sent to the server.

As I didn't have what to compare it with in the past, I presumed it was a little slow. But the parser built with Treetop is possibly more than an order of magnitude slower, albeit Treetop does much more work and is much more flexible and clean. It's just that when creating a Web application or site, there's a possibility of requesting several SQL commands to render a single page or resource like JSON. And there's the chance of multiple concurrent requests from different users. If worse comes to worse, it will be hard to justify making these things slower when an ad-hoc solution which is faster already exists.

That likely explains why so many softwares out there tend to be hard to understand as well. :-)

There's another parser I use very often that's a Wiki content which is used by the Blog, Bookmark and Wiki systems, and possibly others. That is, the SQL parser and the Wiki parser can be abused simultaneously!

Not that I am the king of the parsers, by any means. I liked the experience of using Treetop, and I'll keep it as an experimental exercise. Next I will give other kinds of parsers a try, but they can be much faster if they are written in languages like C and Java, but I lose some Ruby compatibility by going there.

Treetop in a word: Fun!

Memory Leaks

Memory leaks are some of the issues affecting high level languages, and they can happen anywhere you have a memory that would need to be freed but it's linked to an object that should not be freed yet.

Motivated by the recent shakeout of Web servers in Ruby, I remembered to take a look at the memory being used, which revealed that there was a leaking under way somewhere.

During my tests, I've been able to eliminate most of the core server code from the blame, and right now I think the problem has to do with my database abstraction code, as when the session is file based, it doesn't leak.

I've found also that the server is really flying fast when not doing database work. I wish I could not only eliminate the leaking, but make things faster as well for the database dependent code. The thing is, I still like and need the database abstractions I have, so it's not something to let go of.

Current uptime of the Thin server process behind this site

Here it is:

$ ps --no-headers -o etime -p 9810

2-22:12:31

Having never used the command to see the uptime of a process before, I presume this means that the process has been running for over 2 days and 22 hours, or since I activated the new Thin server. That's awesome considering how Thin is in its early days still. It means that so far the testing has been going well, and in my own local tests, Thin has been behaving extremely well too.

I am more than ever confident in Ruby as a good platform for Web programs, and one can wonder how well it will work once the new Ruby version which is faster stabilizes and we migrate to it! It all points to a promising future, with Ruby being used to power lots and lots of Web sites and programs.

I am happy enough with this current setup using the current Ruby version though, which is to say that Ruby has a good present and should have a great future too.

EventMachine, one of the main technologies being used by Thin to do its job, is a watershed for Ruby. Thin is only one of the many HTTP servers that could be created by using EventMachine. Needless to say, Thin is here today and doing great.

When will the popular social networking sites be created with Ruby? Any time from now on. If someone is very on the edge he could start using Ruby 1.9 today perhaps, and get another speed boost out of it, and have a little edge over other folks. Ruby 1.9 is not production-ready yet, blah blah blah, but it soon could be. There's a new release of it promised for the end of February. :-)

I host several public and private applications all in one instance of Ruby/Thin. Here's its status:

• doh 9810 0.0 12.9 42732 30968 ? Sl Jan09 2:46 /home/dewd/code/web/deze9/start_ser[...]

Not bad. 42732 KB is fairly acceptable but it could grow further depending on the use. There's some caching in it.

I like the feel of the server though. It's a commodity machine used remotely, and it feels good. Nginx at the front-end, Thin at the back-end.

I am going to give Swiftiply[1] a try in the future, as it's a possible replacement to Nginx, with a better understanding of Ruby. There's a new release of Swiftiply being cooked up which promises to improve things a little. Its features include proxying and static file serving faster than Apache.

Ruby on Rails and Ruby are closing the gap to the market leaders! :-)

Most amazing though is the constancy with which new developments [2] have been started with Ruby. Hardworking has been winning the day time and time again. I'm not sure if ever in the history of the programming languages there has been such a steady pace of work and collaboration as there has been with Ruby and Ruby on Rails.

It has been really easy for Ruby and Ruby on Rails to make the headlines for some reason! :-) It challenges the conspiracy theorists! For example, one company that hosts Ruby and Ruby on Rails applications has just closed a deal [3] with a Venture Capitalist in the order of $3.5 million.

Is all of this surprising or what?

• [1] http://swiftiply.swiftcore.org/index.html
• [2] RubyForge - http://rubyforge.org/
• [3] Engine Yard Takes $3.5 Million Series A From Benchmark Capital - http://www.infoq.com/news/2008/01/engine-yard-gets-three-five

Every developer is a potential evangelist!

It's generally easy to give things a try and to talk about them with enthusiasm or even criticisms.

When doing lower-level work is not required, developers have fun being occasional evangelists. Why not?! Are there too bad cons to such an activity? :-)

Enabling Thin support for this site, replacing Mongrel

Yay! When I first used Mongrel it was a happening, which has been registered in the first days of this blog. And now there's a new server that improves upon Mongrel, while keeping things simple and straightforward -- ridiculously so.

Check it out: http://code.macournoyer.com/thin/

To create the wrapper for it was just a matter of getting to know the Rack library that tries to standardize some HTTP server matters in a cross-framework and -server manner, and use the current Mongrel wrapper I had as a template.

What impresses me the most is how stable it should be despite its newness, otherwise I wouldn't have been able to activate it for this site for live testing. I'm sending this post with it already! Yeehaa!

Talk about reductio ad absurdum in a web server for serving dynamic content!

I concede I don't fully understand the Event Machine part of it, but I love it from the good experience so far! I mean, no multiple threads? And it works for concurrency? Cool!

I practically kill the performance with a lot of database work, but any improvement is welcome. Like, I am anxious to start using Ruby 1.9 on the server which should help with the performance a little more too.