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:
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.
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).
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.
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.
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.
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.
Several weeks ago, Wolfgang asked after a rename command for Hecl. Pretty simple to do in terms of the Hashtable that maps strings to commands, so I added it. However, there was a problem: in order to save space, I’d been grouping commands together in one class, and dispatching on “argv[0]”. A nearly empty class in Java compiles to something like 500 bytes, so mapping one command to one class is not an acceptable practice when you are working, in some cases, with an upper limit of 64K. Dispatching on argv[0] meant treating it as a string, and doing a compare against the command name, which meant hard coding the command names into the classes implementing commands. Try renaming one of those commands and…oops!
I struggled for a bit trying to find an answer I was happy with, and after talking it over on the mailing list, arrived at doing things like this:
A big class that implements a number of commands, with a dispatch method:
static void dispatch(int cmd, Interp interp, Thing[] argv) throws HeclException {
That method then does a plain old ‘switch’ on the cmd int to go to the correct block of code. The code that calls this is simple, and it has to be, because one gets instantiated for every command, and so it’s imperitive that it doesn’t take up much memory:
class MathCmdFacade implements Command {
private int cmdtype;
public MathCmdFacade(int cmd) {
cmdtype = cmd;
}
public void cmdCode(Interp interp, Thing[] argv) throws HeclException {
MathCmds.dispatch(cmdtype, interp, argv);
}
}
So far, I’m pretty happy with the results. By making the ‘facade’ (I’m not sure it’s really the facade pattern, but… oh well, the name works for me) small, I don’t waste memory. Plopping all the code in the switch statements is probably loathsome to purists, but it makes the code smaller, something that’s never far from mind when working on Hecl. Things are also a bit faster, because we don’t do the string comparisons to dispatch commands either. All things considered, the code isn’t illegible by any means, either. Furthermore, because the new ‘facade’ commands still just implement the regular old Command interface, which means that Proc still works, and that you can still associate a class implementing Command with a string, so that it remains very easy to implement new Hecl commands in Java, and the interface hasn’t changed.
Faster, smaller, backwards compatible, and ‘rename’ works too… life is good!
I read something via reddit recently that hit a nerve:
In this article: Meeting the founders of reddit
he says that: “Reddit, like many other initiatives is more a “project” than a “company/business”
Like everyone, I get inspired by Paul Graham’s writings, and like the idea of making money doing something cool, but my brain seems to be much better at generating ideas for fun projects/cool hacks, as opposed to businesses. I wonder if it’s possible or worth it to make that change. Sometimes trying to “be what you aren’t” is unpleasant and unsuccessful. On the other hand, perhaps it’s more of an acquired skill that doesn’t really conflict with the ‘hacker’ mentality…
Something else I found on reddit:
An Agile Approach to a Legacy System (pdf)
seems interesting because it deals with crappy, real world code, rather than some ideal workplace that exists only in fantasyland. I wish that they’d explained a bit more, at the technical level, of how they managed to integrate their new system with the old one, as that is often a difficult task when the code always has to be up and running, and the old system is in production.
I have a Big Ball of Mud to deal with myself, and a development process that is not agile, nor much of anything else really. It’s the kind of situation that is only going to change ‘in small iterations’, rather than trying (and quite possibly failing) to impose a new way of doing things in one fell swoop. So perhaps what I need is an agile methodology for introduction agile development in small iterations?
I released a new snapshot of Hecl this evening, with a few minor fixes. I’m pleased that the project has picked up a regular contributor, Wolfgang Kechel, who seems to be doing some interesting things with it. He’s a bright guy, and it’s good to have feedback and someone to talk things over with. I have been sidetracked with Ruby on Rails (more on that in the future) lately, so I haven’t dedicated as much time to Hecl as I would have liked to.
I found this brochure about open source in Oregon. It’s “marketing materials” kind of stuff, but still… I’m proud to see all the interest in open source in my home state. Almost makes me want to go back, but then I talked with my parents on the phone, who told me about the 24 days of rain in a row, which brought me back to my senses.
I had been investigating OFBiz as something to use in the company where I’m working, but apparently that’s not going to happen for now, which is a pity, because it’s well done software, and more importantly, has attracted a bright, diverse group of people to work on it. Indeed, I liked it so much that I’m helping out (I hope!) by acting as a “mentor” for the project as it goes through the process known as incubation at the Apache Software Foundation, which means that it hasn’t officially been accepted as part of the ASF, but has the potential to do so if we get all the i’s dotted and t’s crossed. It’s been an interesting experience, as it’s about as far away as you can get from my Tcl work at Apache!
Whilst ambling around on the web after seeing a post on reddit.com that piqued my curiousity, I happened on some work discussing “maximizers and satisficers”, which, put crudely, says that there are two kinds of people. Those who, out of a group of options want the best one – maximizers – and those who just want something that will work – satisficers.
Anyone who has been around programming languages more than, say, a week, will instantly recognize the above theme in the endless discussions of “which programming language is best?”, or more generally, which “X” is best? I’d be willing to bet that programmers, and especially open source programmers, tend towards the ‘maximizers’ end of the spectrum – I don’t want just any old X, I want the best one, dammit! Sometimes, this can be a good thing, as it leads us to continuously seek to improve things we come into contact with, or try new approaches, it can also be detrimental if your goal is simply to accomplish some task, rather than spending too much time fretting about finding the perfect tools to accomplish the task with.
This also has ramifications for people designing or dealing with programming languages. One of the papers (the original?) on the subject (here), actually deals with the fact that maximizers, in their search for perfection tend to be less happy. Where satisficers are happy because they’ve got something that works, and they can go on to something else, maximizers have lots of room for “fear, uncertainty, and doubt” about their choices.
In some instances, actually reducing people’s choices makes them happier. Python’s “one good way to do it” makes everyone happy, because both maximizers and satisficers know that they’re doing things right, and don’t have room to worry. Another example that I know well from my involvement in the Tcl community is “object systems for Tcl”. For those who don’t know Tcl well, it’s an extremely flexible, extensible language, both in the language itself and in terms of its C API. So flexible, in fact, that you can write an OO system in Tcl itself, which has been done, or in C, which has also been done several times, leading to a proliferation of OO systems, and a never-ending stream of questions on the newsgroup about which is the best one? Perl’s “there’s more than one way to do it”, despite apparently providing and pushing choice, may actually work well because it encourages people to be satisficers and use whatever works. I’m sure everyone can think of examples where too much choice causes doubts and hesitation.
I think the lesson to be learned is that while it’s important to encourage experimentation in order to explore possible solutions to problems, at a certain point it makes sense to consolidate and provide one or two recommended ways of doing something. That’s not always possible (Linux distributions, for instance), and squashing competing ideas too early might cause friction with people generating innovation, so it can be difficult to accomplish, but I believe it’s an important social aspect of software creation to keep in mind.
We’ve hit something of a stumbling block with Hecl, and it’s proving tricky. Far from being “write once run anywhere”, Java has many versions, when you take into considerations the wide array of devices that run one of several configurations roughly lumped together as “J2ME”. My cell phone’s implementation doesn’t have floats, for instance. This necessitates that the J2ME and J2SE versions contain different code, but Java doesn’t make this easy, because there are no macros or other ways of conditionally compiling code.
The solution we’ve adapted so far is problematic because it’s not very fine grained: we have two separate directories, one for ‘core’ Hecl (sans floats) and another that contains the exact same classes, but with floating point. For instance:
BasicMathCmd.java – no floating point
BasicMathCmd.java – the floating point version.
As you can imagine, this means that code is replicated in two places, and each change has to be done twice, carefully, keeping track of the actual differences between the two files. This can only get worse as the code grows.
I’ve seen some hacky ways of doing macros and things like that, but they don’t look very satisfying. I’m too much of a Java novice to think of anything better than what we’ve got, though.
Update 2006-04-20: we chose to use Antenna
Bill Gates wrote his famous letter thirty years ago, tomorrow:
http://www.blinkenlights.com/classiccmp/gateswhine.html
In the meantime, people are still missappropriating software, the “hobbyists” have returned with a vengeance and have built software that rivals or bests Mr. Gates’, and the economics of the industry still aren’t entirely clear. What economist would have ever predicted the success of Open Source? They’re certainly fascinated by it now that it’s here.
DedaSys Journal 