BloggEd

From the human (programmer) point of view, all computer languages suck. It’s not the fault of their designers; creating a successful programming language is very difficult, as different tasks call for different kinds of tools. By definition, a general-purpose language will be always suboptimal for certain kinds of tasks. On the other hand, languages intended for specific use are seldom used for programming tasks, unless there is no viable option. This is easy to explain, as people don’t want to learn dozens of domain-specific languages to be able to work effectively.

Having used several programming languages, one should easily find out what features a language should really have, on the assumption that all language features can be implemented in a consistent way and the combinations of those features do not create unwanted warts.

So, here are my thoughts:

• Hybrid OOP/functional language, with emphasis on imperative style
  • I find functional languages more beautiful in principle, but to gain wide-spread adoption (think of all the software industry) it must be something that is easy for all those Java/C++/C# folks to adapt to. By pure OOP I mean that everything is an object, including primitives, classes and methods (regarding syntax; implementation may even resort to hacks as long as the object abstractions don’‘t leak, as they do in Java). Ruby is like that, and it has an awesome design. Because classes are truly objects (of class Class) as well as methods, and combined with introspective features, it is a powerful tool for all kinds of metaprogramming tasks and a very capable language for modeling all kinds of things. All kinds, as far as I’m concerned.
• Strong, dynamic typing with some kind of optional typing support
  • Static typing doesn’t really help in creating bug-free programs. Successful compilation is far from working program. However, static typing does have certain advantages, mainly it allows the compiler to optimize stuff automatically, and it also helps in creating intelligent editors and IDEs. Optional typing could be supported through annotations or similar mechanism. Type inference is another viable solution, something where Haskell really shine (ok, Haskell is bright and shiny in many other ways too, but that’s a topic for completely another rambling).
• Single inheritance with mixins
  • This applies to OOP languages only, but yeah. Single inheritance is a pretty concept, but if all your classes derive features only from one superclass at any time, and the only extension mechanism is pure abstract classes (interfaces), your language sucks more than ten Electrolux vacuumers combined.
• Proper introspection
  • You should be able to find out what methods an object has, at least along with their arity, and the ability to create custom methods on the fly. How else will you be able to create funky DSL languages, more suited for describing the models of the problem domain? Yeah, I thought you wouldn’t realize the benefit. That’s precisely why you think your <insert language name here> is suited for all your needs. It is exactly the same with math; if you can’t do math, you don’t understand it’s benefits. Naturally I don’t mean you, but the other guy, the one who doesn’t read these kinds of blogs.
• Every method should have a an owner, a class or module, but some modules/classes could be imported by default. Again, Ruby works exactly like that while not creating a tyrannic kingdom of nouns. Reason for this is mostly concerned with providing your custom implementations. Say you want to customize behaviour of all your print statements in your program. You don’t want to modify the source, as much of it is drawn from third party sources, and it would break the updates. So you overwrite Kernel::print or something similar. What, you can’t? I’m so sorry for you. Sooo sorry.
• Easy syntax for co-routines
  • I’m not sure if a co-routine is a proper name for it, but if I had to choose three reasons.. no, make it two.. for why Ruby is such a nice language, I’m quite sure Ruby blocks would belong to that list.

In short, I think Ruby is quite close to my ideal language. And should be yours too. Please reread this article and ignore the invisible, specially encoded subliminal messages injected between the lines in the text until you agree with me. Now, good. At this point I can admit that It does have its problems as well, but there aren’t many, and they are quite far from severe. In my opinion, some of those are

• The inability to choose between green and native threads
  • I don’t think Ruby should use native threads; sometimes green threads (ie. threads are implemented in the interpreter) are really nice—they were not chosen for Ruby by accident. But sometimes you need true concurrency as well, so you should be really able to choose. This problem isn’t related to the language itself, but the current implementations, namely MRI and JRuby.
• Inability to configure GC behaviour / choose from different models
  • I don’t like Java too much, but at least there you can configure several aspects related to memory usage. But that’s because JVM is an astonishing piece of …stuff, you know, the magical elven pixie dust kind of thing. Java has its shortcomings, but Java engineers are really bright people, as well as Gosling himself. We are still learning how to design languages, so one shouldn’t be too hard for picking.. umm.. on certain languages. And again, this problem is not related to the language but the implementations.
• Lack of (optional) typing mechanism combined with powerful metaprogramming tools makes Ruby really hard for editors. Yeah, this is a language thing! Yay.
• Performance
  • This is so often not a problem, that I wanted to mention it last. However, sometimes it is. And even though doing C interfaces for Ruby should be quite easy, it should be possible to do it in Ruby. And this is partly a language thing, as without more compile-time information about types it is quite difficult to optimize.

I should have published this long ago, but I always wanted to make it longer. But Steve Yegge has already said everything important about programming That Takes A Longer Posting To Blog About, so I publish this unfinished as it is. So there.