First, let me say that I’m actually enjoying Ruby on Rails quite a bit. I agree with the large number of people who, like me, are finding that Rails hits a sweet spot between too much structure, configuration and overhead, and anarchy, on the other side. It’s good code, fun to use, and for the most part I enjoy Ruby as a language.

However, being a bit of a perfectionist, and since Rails is “opinionated software”, I thought I’d fire mine right back at it regarding a few of the things I don’t like. Mostly minor nitpicks, but I’ll likely add to them as time goes by and I use Rails more (I’d like to use it more at work, for instance) – after all, I’m opinionated myself.

• XML processing directives are <? and ?>, not <% and %>. I think PHP got it right there.

• To make a variable “visible” in a template that you create in a controller, you use an @instance @variable. However, only instance variables are visible in templates, class variables (@@somevar) aren’t. Odd… If I understand things correctly, it turns out that the variable scope isn’t what’s being looked at (as one’s mental model might lead one to believe), but rather, all the instance variables are introspected and made visible in the template. I think I was happier thinking something along the lines of the template having the scope of another method in the controller. I honestly haven’t thought it through, much, but it seems that rather than ‘instance variables’, they are ‘variables marked, via a @, for inclusion in the template’.

• The one thing that does drive me batty is that you have to restart Webrick to see changes in templates. Other people don’t seem to observe this, so perhaps it’s the versions of everything I’m running (Debian stable, Ruby 1.8.2, Rails 1.0, Postgresql backend) that don’t quite work out. Of course it’s not in production mode and thus cacheing. What happens is when I restart the server, I see the changes I made. At that point, I can usually change the template file once and see the changes. After that, they simply don’t show up, even if changes in the controller always do. So to edit my template, I have to restart the server a bunch, which is extremely annoying. I have a feeling that there must be something I’m doing wrong.

• I really wish I could use ActiveRecord with primary keys on multiple columns. I know that the authors just aren’t in favor of the idea, but it would be damn useful in transitioning away from legacy databases (I’m thinking of work, here). It would make my life that much better if I could smear some ActiveRecord putty over the crufty old tables and be able to deal with them in a nice, clean way from Ruby.

• Indiscriminate use of strings and symbols. There doesn’t seem to be an entirely clear rule of when to use strings and when to use symbols. You eventually memorize what to use where, but it feels like it’s not quite as consistent as it might be, that there’s a ‘helpful rule’ that’s missing.

For the curious, who read Conditional Compilation in Java, and were waiting on the edge of their seats to know what happened, we decided to use Antenna, with the work being done mostly by Wolfgang. It’s not particularly elegant – the source code ends up being, in some places, what the Italians call a “pugno nell’occhio” – a “fist in the eye”. But all things considered, it’s not that bad, and it’s better than writing the same file in slightly different ways in different subdirectories, especially in those cases where the code changes only slightly from one version to another. As a bonus, Antenna gives you a lot of handy tasks for doing common j2me things.

Indeed, Wolfgang did a very nice job of revamping the Hecl build system, and after a bit of additional tweaking, it works very well. It builds different .jars and .jads for different targets, so that it’s easy to develop for new platforms without stepping on everyone else’s toes.

My current plans are to spend some more time on build tools and infrastructure – I think more people will start to experiment with Hecl once they realize just how easy it is to build applications. You don’t even need a java compiler if you use HeclBuilder, which is a simple GUI that lets you specify the input script, the jar file to create, and then generates a new Hecl application read to be loaded onto a cell phone. It does this by keeping a copy of Hecl.jar as a resource, which it then modifies (replacing the script.hcl resource that the Hecl.jar itself contains) and then writes out as a new .jar/.jad. The long and short of it being that you have a very quick edit/”build”/test cycle when using an emulator. I have some ideas about improving on this even more, perhaps utilizing microemulator, which, although not as complete as Sun’s WTK emulator, is open source and thus redistributable with Hecl.

Ding ding. (Round 1 – for those who missed it)

Kidding aside, remember that I like and respect both of them.

Libraries

In the first article, I mentioned that Ruby has a lot of momentum, which is a pleasant change from Tcl’s relative ‘uncoolness’ amongst the Web 2.0/O’Reilly/”next big thing” crowd. That said, there are still places where that momentum hasn’t taken it. I set about writing some code that I’d wanted to play with that involves sending some email. Something that’s very easy in Tcl:

http://tcllib.sourceforge.net/doc/smtp.html (towards the end of thepage).

Python seems to have a pretty complete email system too, for that matter: http://docs.python.org/lib/module-email.html.

So it appears that, based on a sample of one attempted task (how’s that for statistics?), that Ruby is still lacking a few things in its standard distribution. Note that this functionality is available elsewhere (TMail, to cite one), but email is ubiquitous enough that it ought to be in the standard library.

Command line swiss-army knife

While Ruby’s OO system gives it a head start when you need to create a larger system with distinct parts, it can still be used as a quick’n’dirty scripting language for quick one-off jobs. From the man page:

% cat /tmp/junk
matz
% ruby -p -i.bak -e ’$_.upcase!’ /tmp/junk
% cat /tmp/junk
MATZ

Very handy. Tcl’s command-based syntax just isn’t quite as quick for those sorts of operations, so Ruby wins hands down here. I’ve suggested that the Tcl folks distribute a second program that takes a lot of the Perl-style command line arguments for this sort of work, but the idea doesn’t seem to be of much interest.

C API’s

On another tack completely, one of the things that originally drew me to Tcl was its very, very nice C API. It’s documentation is clear, and thorough, and the API itself lets you get involved in pretty much any aspect of the language that you want. This makes sense, because when Tcl was originally created by Dr. Ousterhout in the late ’80ies, the idea was to create a scripting language as a C library that would be loaded into other programs. The language has always been faithful to its heritage, and to this day I find it lots of fun to merge Tcl with C code.

I have to admit that I don’t know the Ruby API all that well, but what I have looked up looks pretty nice. To a certain degree, it’s comparing apples and oranges, because Ruby requires you to deal with the very object oriented nature of the language, whereas Tcl is a lot more direct. The Programming Ruby book’s coverage of the subject also leads me to believe that Tcl really gives you access to more stuff (interpreters, channels, events, and many other parts of the system). Ruby seems to take an approach that might best be described as letting you write Ruby in C – meaning that you create Ruby objects, use their methods, get their values, and so on, but you’re still really dealing with Ruby. This has a certain elegance, but sometimes it’s necessary to muck about with things at a lower level.

I don’t know how it works out in practice, but Ruby has a bit more infrastructure in place for actually building extensions once you’ve created them. Tcl has “tea”, which is a set of m4 macros, but anyone can tell you that the auto tools are not much fun to work with (going to the dentist is more fun) – anything that keeps me away from them is welcome.

Garbage collection

One of the more interesting aspects of the different approaches to C interoperability is the fact that Tcl uses a simple, robust, straightforward reference counting system to keep track of, and throw away resources that are no longer used. Ruby has a mark and sweep garbage collector, which is probably more sophisticated, but also more complicated, and requires a bit more support from the programmer initially. The benefit is that once things are set up, they require less keeping track of, because you hand off memory management to the computer. From the end user’s point of view, Ruby wins here, but if you happen to be writing a C extension, I could see it being more difficult to write and debug to this API, although Tcl has its own warts, one of the worst of which is the fact that Tcl values must be convertible back and forth to strings, so that for things like a file handle that can’t really survive the round trip, because it’s just a pointer, you use a hash table and some sort of string to hold onto the object:

 "file1" -> int fd1
 "file2" -> int fd2

which makes it impossible to GC these values.

I suspect that both approaches have their merits – Ruby’s is more elegant, but Tcl’s is simple and rugged.

Licensing

Bouncing back to something completely non-technical, Ruby’s licensing is either the GPL, or their own license. If I understand things correctly, you can get around the GPL’s “viral nature” by simply renaming things, if you have a need to include Ruby in a proprietary product:

1. You may distribute the software in object code or executable
   form, provided that you do at least ONE of the following:

   a) distribute the executables and library files of the software,
   together with instructions (in the manual page or equivalent)
   on where to get the original distribution.

   b) accompany the distribution with the machine-readable source of
   the software.

   c) give non-standard executables non-standard names, with
   instructions on where to get the original software distribution.

   d) make other distribution arrangements with the author.

So it seems that you’re ok if you just call it something else. However, the license goes on to talk about several other files in the core distribution:

1. You may modify and include the part of the software into any other
   software (possibly commercial). But some files in the distribution
   are not written by the author, so that they are not under this terms.
   They are gc.c(partly), utils.c(partly), regex.[ch], fnmatch.[ch],
   glob.c, st.[ch] and some files under the ./missing directory. See
   each file for the copying condition.

Looking through the LEGAL file in the distribution shows that there are files distributed under other terms. Of course, they’re all free software, but some are LGPL, some BSD, and a few others for good measure.

Tcl’s licensing, on the contrary, requires very little understanding. The language was developed at the University of California, Berkeley, and the license remains BSD. This goes for many of the libraries and extensions as well. If you need to embed a language in your proprietary system, Tcl and its libraries present no problems whatsoever. Of course, I prefer to work with open source code and communities, but that’s not possible 100% of the time, so it’s always nice to know things are free and clear, should that need arise.

Internationalization

This is something the Ruby folks know they need to fix, and are working on, so it’s not worth dwelling on it much, but it is a proud point for the Tcl community. Tcl has had very nice i18n setup for many years, at this point – since the 8.0 release. It’s built into the language, so that everything works with it. You have commands to set encodings of IO channels, and even munge strings. Tcl wins here – no contest.

As I continue exploring Ruby, I think I’ll find more stuff to compare with Tcl, so we won’t ring the final bell just yet.

Weak/Dynamic typing

One of the things I really like about Tcl is how very, very dynamic it is. It’s possible to replace just about everything ‘on the fly’, including control commands like if and while (in Tcl, they’re just commands, not special syntax).

Like Lisp, Tcl gets a lot of its flexibility from its simplicity, and one of the ways that things are kept simple is via the concept of “Everything Is a String”. Some people erroneously recall the early days of Tcl and take this to mean that Tcl represents everything as a string internally, making it very slow for numerical operations. That hasn’t been true for something like 8 years – Tcl values are translated into a more appropriate internal representation ‘on demand’. However, the concept still gives you lots of flexibility:

set a b

You don’t have to quote things – they default to strings – the variable ‘a’ now contains the value ‘b’.

set lst {a b c d e}

No fiddling around with lots of syntax – the above is defined as a string (we could have used “” to group the words), but it gets turned into a list

llength $lst
5

Things are automatically converted into the type you want to work with. Of course, this also makes it really easy to work with code as strings and vice versa:

proc until {cond code} {
    while {1} {
        uplevel $code
        if { [uplevel [list expr $cond]] } { return }
    }
}

set i 0

until {$i == 10} {
    puts "i is $i"
    incr i
}

and so on and so forth.

Ruby (and Python) handles things a bit differently than Tcl does. Even though it’s still very dynamic, it is more strongly typed:

"5" + 5 # error

Whereas the same code runs just fine in Tcl – “5” is transformed into a number, because if the programmer is trying to add to it, they must want it to be a number. On the other hand, strong typing can help catch errors, may help make things clearer, and in corner cases, probably helps catch nasty surprises.

One of the things that Tcl’s system facilitates, at least with simple types (lists, strings, numbers, dicts) is ‘marshalling’ or ‘serializing’. Want to send a hash table down a socket?

 puts $sk $mydict

 # And on the other side:
 gets $localsk mydict
 dict get $mydict key

When you start treating it as a dictionary, it “just turns into one” – or throws an error. Good programmers will check for errors, but that goes for whatever language you use. This often comes in handy for code-creation, as well – it’s very easy to build up a string programmatically and then evaluate it, much as you might do with a list in Lisp.

It also makes coding short scripts… well, shorter, because you don’t have to fiddle around telling the language what you mean, in most cases. Treat it like how you want to use it, and it will work out what you want to do.

Hecl

Hecl comes into the picture, because I’ve borrowed a lot of design ideas from Tcl, but the language is still used by only a few people, so we’re free to hack on it and change things that we don’t like about Tcl. Lately, we’ve been having an interesting debate on the merits of Tcl style weak typing, vs stronger Ruby-style typing, as well as the string representation you get when you attempt to print a type:

http://sourceforge.net/mailarchive/message.php?msg_id=15254941

http://sourceforge.net/mailarchive/message.php?msg_id=15254942

There are certainly some things that could be improved in Tcl’s way of dealing with things – one area where it doesn’t do so well is in dealing with NULL values – you can’t really deal with that in a string, because a blank string is different from no value at all.

Wolfgang would like to go towards more Ruby-style values. I’m willing to consider most anything at this stage, because it’s interesting, and I like going over the possibilities, in order to make Hecl as useful as possible. “Everything is a string” has its limits in Tcl, in any case, because what ends up happening is that ‘complex’ types (files, say), are tied, via a hash table, to the C struct that actually implements them, meaning that the string representation is really only a pointer to something else, and isn’t “meaningful”, as it is with lists or dicts.

I think, though, that in this case I’ll mostly want to keep types weak/dynamic, as Hecl aims to be a complement, not a replacement for Java, so in many cases, I’d rather see it make nearly the opposite design decision, where it’s reasonable.

We’ll see, though, who knows what ‘type’ of interesting compromise we might end up with. Of course, I’m always happy to see new people join the discussion.

Interesting article on the “opportunity costs” of Java not being open source:

http://www.0xdeadbeef.com/weblog/wp-trackback.php?p=190

It fits in with my interest in the economics of programming languages, and adds a new twist to the debate over how to best popularize and profit from the creation and stewardship/ownership of a language.

I don’t agree with his point that Java would have been where “LAMP” is today – part of the attraction to PHP was how much it scales down, but most of his other points are dead on.

Yesterday, I added Wolfgang Kechel as a committer to the Hecl project, because of the good work he’s been doing on it. He’s demonstrated consistency and quality over a number of months, and has also shows he understands where I want to go with the language, so it was a natural thing to do.

Adding a new committer is not always so clear cut, though, and it’s sometimes a difficult decision, especially with smaller projects. I find that it’s much more fun to work on projects with other people, so I want to encourage them to get involved, and granting access is something that ought to give people a bigger stake in the project, and reward/encourage them in their efforts. In practice, it doesn’t always work out that way, though. Often, after a bit of initial work, they dissappear, which means they weren’t really that interested in the first place, and you shouldn’t have bothered granting them access to the code – they could get by just fine by submitting patches.

The question of openness vs control also plays a strong part in the difficulty of the decision. I think the Apache Software Foundation way of doing things (decisions by consensus of those who work on the code) is pretty successful for well established projects, but I’m also convinced that the “benevolent dictator” model is best in some cases. Design by committee doesn’t work very well for projects like a programming language where you really want to have one coherent vision, rather than some sort of frankenstein mishmash of pieces. (As an aside, Larry Wall, has done a fine job of proving that you can have – even revel in – a mishmash, even with a ‘dictator’!).

The point being that it’s a little scary to hand someone the keys to your project, because you take a risk on them working counter to your goals, especially in new projects without a self-propagating culture in place. An established language like Python has a fairly large number of people who can instinctively tell you if a new feature is “pythonic” or not. But for a small, new project like Hecl, the risk is that there is more room for unproductive arguments, or having to back out “bad” changes should someone really take off in a direction you don’t like. Of course, with Hecl, I think it is at a great point in its life. There is a lot of room to hack, because it isn’t used by many people, so we don’t have to worry about angry users if we break it while trying to improve it!

All things considered, it’s a positive step to get more people involved, but it’s important to start building a culture in order to keep your code going in a healthy direction. Depending on the project, that culture might include a healthy dose of what is and what isn’t within the project’s scope, or it might simply regard the quality of code considered acceptable. For instance, Tcl’s standard library is pretty open to whatever people want to implement, however you must accompany your code by either tests or documentation, and preferably both.

I think the most interesting phase is when you are “bootstrapping” – going from just one person to a group. Judging by the number of small projects that have fallen by the wayside without ever getting more than one person to work on them, it’s also the most difficult period in a project’s life.

What do other people think? What tactics do you use to get people involved, yet still make sure they are the right people?

mysql> create table foo (bar int);
Query OK, 0 rows affected (0.00 sec)

mysql> insert into foo values ('');
Query OK, 1 row affected (0.00 sec)

Uh… it is not ok!

Lucky I caught that one, as an administrative interface was setting a value to 0 that should have just been NULL, meaning that instead of using a default value for a minimum threshold, it would have used 0, thus setting up a chain of events with unpleasant consequences.

I wrote an article about the implementation of Hecl, posted here:

http://www.dedasys.com/articles/hecl_implementation.html

Originally it was for a magazine, but I decided that for the amount of money they could pay, I’d rather just have the freedom to post the article as widely as possible.

I think it might be of interest because Hecl is still a simple language, so those who don’t have the time or inclination to delve into the internals of a language like Tcl, Ruby or Erlang can still find out what goes into the making of an interpreter.

Gianugo Rabellino, Matt Asay and others have been discussing “the meaning of open source”. This touches on two things:

1. Free Software Business. How to make money with or from open source software. There was (still is, it’s just not active) a mailing list, “Free Software Business” where this topic was rehashed several times in a number of interesting permutations, and all of the different business models were covered. The participants were all free software fans, with varying motivations that mostly centered around a free market view of the software world, and a desire to discuss ideas about how free software could be self-sustaining economically. Despite having some of the best minds in the business (people like Bob Young, Brian Behlendorf , Michael Tiemann, Russ Nelson [the list’s host]) and a few economists, I don’t think there was ever really a ‘conclusion’. There are several models out there that work, but none of them is “perfect”. They either involve holding something back (dual licensing, for instance), or don’t really solve the problem of getting paid to produce software – service/support businesses are best when the consultants are working on paying gigs rather than creating software from scratch. It’s more than obvious that there is a great deal of value in free software, and it’s an extremely beneficial thing for companies that know how to take advantage of it. What’s not so obvious is how to transfer enough of that value to the creators of the software to keep them going.

   The point being, “free software business” is not a solved problem, so expect to see various models, as people try things out. Some of them will have problems, and won’t survive.

2. This leaves us with the crux of Gianugo’s “rant”, that some of these companies and groups are doing open source, but not in the true, open, community-oriented approach. I think he’s right, but where I don’t agree is with this:

   Also, I’m not buying what Matt, Matthew and Ugo are saying about some sort of Darwinian selection being able to discriminate the good from the bad (assuming there is actually “good” and “bad” – I just tend to think we have different objectives): it’s hard enough to move the CIO masses beyond the “Open Source means Linux” meme, go figure explaining why they should care to consider the difference between Open Source built within the virtuous cycle of community based development and Open Source as a pure distribution model of conceptually proprietary and closed to participation code.

   I see open source as being really strong right now, and do not deem it likely that that will change – it’s survived Microsoft so far, survived the dot com bust, survived people trying to label it as a political movement, survived venture capital… Fundamentally, it just has too many things going for it. There’s too much value, too much diversity, and ruddy health. So I think that where he sees people “not getting it”, I see a competitive advantage for those who do. Things will sort themselves out with time.

(Note: as of 06-04-14, “Round 2” is now available: https://journal.dedasys.com/articles/2006/04/12/ruby-vs-tcl-round-2)

Actually, “Ruby vs Tcl” is just a dramatic title. I like to think of myself as somewhat of a connoisseur of programming languages, which means I find something to like about most of them. Also, having put my toes in the water by creating my own, Hecl, I have way too much respect for the people that do the work to really pick on any language too much. However, comparing and contrasting is fun, as long as it stays productive!

I’m a long time Tcl fan, having known the language for something like 7 or 8 years. Recently, I’ve started picking up Ruby, because I’ve decided to follow the herd and use Rails (which is every bit as pleasant as its made out to be, but more on that another time).

Where Ruby shines

Coming from Tcl, which has to be one of the most misunderstood languages out there, one of the things that I enjoy most about Ruby is all the buzz. It’s a pleasant change from the “trying to hold the line” mentality in the Tcl world. Of course, marketing and the inclinations of ‘the herd’ are fickle things, and as the Python folks are discovering, what popularity giveth, popularity can take away. In any case, learning a new language is fun and not all that difficult with Ruby, so I’m enjoying riding the wave. Point in Ruby’s favor, even though sometimes I’m left scratching my head that it took Rails to convince some of the Java guys that scripting languages really are that much more productive.

The other thing that really sticks out about Ruby compared to Tcl is that it’s Object Oriented (henceforth known as ‘OO’) through and through. At the low level, I don’t really care too much (puts “hello world” is valid Ruby and valid Tcl), but Ruby’s OO is nice for organizing more complex data structures. Tcl has OO as well. Actually, Tcl has several, competing OO systems, which is a classic case of “choice is not good” because none of them is standard and something you can count on being present. Also, most of the Tcl object systems don’t do a great job of deleting unused objects. I don’t suppose it would be that hard to add that if there were one good, standard one. Luckily, such a beast is on the horizon, but it’s awfully late for a language that’s more than 15 years old. Point goes to Ruby.

Ruby also wins in the ‘available libraries’ department, although probably not by that much, being relatively new to popularity. What Ruby really has going for it is that:

1) The standard distribution is pretty big, with lots of good stuff, an approach that the Tcl world hasn’t taken. This means that Ruby out of the box does a lot more than Tcl.

2) Via Ruby Forge and the gems system, Ruby is attempting to centralize and standardize the distribution of extras, something which Tcl has never really managed.

Things they both do well

In terms of community, both languages seem pretty well off. The Tcl newsgroup, comp.lang.tcl, is one of the friendliest, most helpful corners of usenet, and reflects very positively on Tcl. I’m newer to Ruby, but by and large, they seem to be handling the massive influx of new people with aplomb, and without much, if any, of the snotty “I was here way before you” attitude that sometimes crops up in these cases. I’d call it a tie.

Both languages are very flexible, but in different ways. They both support ‘eval’, and let you do all kinds of nifty introspection. I fear I don’t know Ruby well enough to come up with a definitive answer, but I Think I’d still give the edge to Tcl, just because of its ultra-simple syntax and command-based style lets you redefine Tcl commands in Tcl itself – and everything is a command, even if, while, and the lot. Like I said though, this is a vague enough requirement, and they are both very malleable languages that you could make a case for “everyone being a winner”.

In terms of syntax, de gustibus non disputandum est. Ruby has more of it, which can sometimes be helpful. For instance, foo[1] vs lindex $foo 1. On the other hand, Tcl’s

array set hash {
    foo bar
    bee bop
}

Makes me reach for the shift key significantly less than

hash = { :foo => "bar", :bee => "bop" }

Tcl’s spare syntax is one of the reasons it is so flexible, but for everyday use, sometimes it’s nice to have a little bit more. In the end, it’s a question of taste, so we’ll call it even.

Where Tcl is rock solid

Here’s where the “part 1” in the title comes in. The following are things I don’t care for in Ruby, but since I’m new to it, there’s the chance that I’m missing something in these observations.

Interpreters. Tcl lets you handle multiple interpreters not only at the C API level, but in Tcl itself. This is really cool – you can juggle different people running different scripts in your application, without them stepping on one another’s feet. If you want, you can let them share stuff, too. This capability has also been extended to provide safe interpreters for the execution of untrusted code. Ruby has safe evaluation too, but it’s not in a completely separate context, so it’s just a different way of doing things, but still, I like the idea of having and being able to manipulate multiple interpreters. Tcl wins hands down.

Event oriented programming. Tcl really shines here, as it’s possible to create simple, fast servers without actually having to muck about with select yourself. The python folks have caught on to this with Twisted, and I suspect that Ruby will too, if it hasn’t already and I’m simply not aware of it. Note that Ruby has a select call as part of the language, but what I’m talking about is being able to whip up servers in a few lines, without even needing to require any external modules.

Modularity is an area where both languages could do better (well, at least for some users/uses). Both languages might be interesting in the embedded arena, but it takes some effort to cut them down to size. In Ruby on the Mobile, Matz himself states that this isn’t an easy operation. Tcl is notable in that it has some small footprint implementations like Jim, but the core language would require non-trivial hacking to remove some of the bits and pieces that are ‘welded on’.

A few nitpicks about Ruby: no deep copy – you have to marshal/unmarshal, which feels wonky to me. File.split functionality is just dirname/basename rehashed, rather that Tcl’s more correct/useful splitting of a path into a list of all its components based on the current platform’s directory separator.

Threads are another area where Ruby, at first glance, at least, could probably use some work. Tcl has real, OS-level threads, which are very easy to work with because each one gets its own interpreter. Because of this, they almost feel like separate processes, but of course, if you need to, you can do all the sharing and mutexing and so on that you need.

Conclusions

So, what conclusions can you draw from this? Well, they’re both fine languages, and are more than likely capable of doing most anything you need. Something else that I was pleasantly surprised by is the fact that Tcl, despite its age, and its lack of buzz and O’Reilly/Web 2.0/the hot new thingness, still has a lot to show the world, and does a lot of things right, out of the box. It’s also worth noting that most of the problem areas for Tcl are social, rather than technical, and could have been resolved easily/avoided with the right leadership.