Boss Ross has declared that we are far enough out of stealth mode for me to use my powers as Tucows’ TC/DC (Technical Community Development Coordinator) and actually say what language the developers are using to write this pretty cool blogging tool called Blogware…
Ruby!
Some of you might right now be cocking your head to one side. Ru-what? If you’re one of these people, Ruby is:
- A complete, full, pure object oriented language. Even the number 1 is an instance of class Fixnum.
- Flexible and dynamic. It’s both dynamic (no need to declare variables) and strongly typed (types are checked at runtime). What to add methods to a class at runtime? No prob. Want to add methods to an instance at runtime? Once again, No prob.
- A language with a nice clean, consistent syntax
- Open source
For more detailed information, check out the following:
- What’s Ruby? from the Ruby language web site
- Ruby author Yukihiro Mastumoto’s foreword to Programming Ruby
- The Wikipedia entry for Ruby
Ruby is on the list of languages I’m actively learning, and I’ll be documenting my experiences and other Ruby-related news here.
3 replies on “So, what language is Blogware implemented in?”
Dudical!! Ruby is out sekret weapon! đ
It should be noted that 1 is the only major difference from Python. I’m not sure whether it’s a benefit or a liability.
– AaronSe
I’ve looked at Ruby a bunch of times. It is of course extremely similar to Python, to the extent that deciding between the two would be pretty much a coin-toss or aesthetic choice (some people are allergic to Python’s indentation rules, others to Ruby’s more Perl-like syntax) for most people. Since I already know Python, though, and in particular since I’ve gotten pretty damn good at writing extension modules for Python, I personally find insufficient reason to switch.
The metaprogramming/overloading actually strikes me as a liability. It’s not useful all that often, but it does give alpha-geek-wannabes a way to obfuscate their code so it’s hard for anyone else to maintain it. There’s also a performance cost, because now every operation even on builtin types has to involve a complete method lookup. Lastly, the lack of multiple inheritance just bugs me. I don’t use MI that much, and then generally only in a shallow non-joining mixin kind of way, but its absence in Ruby still seems like a shortcoming.
Jeff Darcy