Roads Less Taken

I got the opportunity to make a Skype interview with Dan Ingalls, so I decided to try to record it. Had no idea it was not as easy as a "press record"-button. I am on Ubuntu, Karmic Koala. First of all I had serious trouble getting proper sound working with Skype, I ended up following the HOWTO in order to install Skype 2.1 beta - which uses PulseAudio ONLY. That took care of that issue, after a bit of fiddling in the "Preferences" dialog you get when right-clicking on your volume applet :)

So… I did roughly this:

Record both sides of the conversation using parec. This is a tool in PulseAudio, so the recording is done "outside" of Skype. In two different files! I used this shell script to record both sides at the same time (note that this produces RAW files):

        parec -r -d alsa_output.pci-0000_00_1b.0.analog-stereo.monitor \
                -n "Mon Rec" > mon-rec & \
        parec -r -d alsa_input.pci-0000_00_1b.0.analog-stereo \
                -n "Mic Rec" > mic-rec &

Note that I found the alsa-yaddayadda names in… eh, some dialog somewhere! Don’t recall. Anyway, read more on this part here.

I then converted the resulting two RAW audio files into WAV using sox, some kind of audio swiss army knife. I don’t have the exact one-liner handy, but I used the options found in the link above.

Finally I mixed the two files together… eh, ah, problems… They don’t synch! Now… I have absolutely no idea how that can be, but the files end up drifting out of synch, and this seems to be a known Skype thing according to Mighty Google.

So in the end I had to manually cut/edit the two files in order to get a proper question+ answer sequence as an interview. I played with Audacity, ReZound etc but ended up doing it in Sweep, it felt simpler and didn’t cause me any other trouble.

NOTE: On "other less worthy platforms" than Linux there seems to be other options. I also found some stuff for recording on Ubuntu, but AFAICT these solutions would not work with Skype 2.1.

Well, perhaps it helps someone else out there intending to do the same journey!

regards, Goran

I just read Joe Armstrong’s old "Why OO sucks" article, Joe Armstrong being the inventor of Erlang. Granted, the article is from year 2000 I think, so perhaps I should cut him some slack… nah! :)

First of all - no, I haven’t programmed in Erlang (yet), but quite a lot of other programming languages. My favorite language is the grand father OO language - Smalltalk. So sure, I am biased in favor of OO.

I have read other criticisms of OO, and various discussions about good or bad characteristics of OO in general and in specific OO languages… Sorry, this article is IMHO not among the good ones, and my feeling is that Joe wrote it quite quickly and with no real experience in programming in OO.

But I don’t intend to say his article "sucks" without arguing for why I feel it sucks :). And also, I am in great awe of the stuff Erlang makes possible so I have great respect for Joe - but that doesn’t mean he can’t be dead wrong.

Let’s go through his article bit by bit:

"Objection 1 - Data structure and functions should not be bound together"

I quote:

        "Since functions and data structures are completely different types of animal it is
        fundamentally incorrect to lock them up in the same cage."

Rereading that first objection I only see kinder garten explanations of what functions and data are. I don’t see any real serious explanation of why they couldn’t be combined into objects other than "because they are different". That is not an argument.

It is in fact quite logical to group functions and data together into objects based on their interaction patterns, if for no other reason.

Let’s say we have data structures A, B, C and D. And we have functions q, x, y, z. If you start looking at what data is read and written by these functions you may find that q and x operates only on A and B, reading one and writing the other etc. So the functions and data structures form "natural clusters", and usually these clusters are quite intuitively modelled as objects.

Putting them together creates a boundary around this group of data and functions - encapsulation. Sure, you may call that a "module" but an object is IMHO slightly different since objects have identity, a life cycle and we can hold them, send them around etc.

So in some sense objects can probably be viewed as modules but often more fine granular. And we can combined such "modules" into larger modules (since objects have identity and can be referenced etc) and we can create and kill them dynamically (life cycle).

If I was coming from a language with a well developed "module" concept I can definitely see this as just "another step" forward.

Another interesting fact with objects having a life cycle is that since an object contains data A, B, C and D we now easily can create a whole such data "group" by just instantiating this object. And we deallocate them together as a single entity too - manually or automatically. Again, quite natural.

So ok, I can go on and on about this but since Joe didn’t really give any arguments I will stop there.

"Objection 2 - Everything has to be an object."

Now, being a Smalltalker I wouldn’t use the phrase has to be but I can clearly see all the benefits when the paradigm is really followed through in a pure way.

Ok, but let’s look at what Joe says. He points to an example - different datatypes for describing amount of time, or well, not "amount" but in fact partial pieces of points in time. Hour (of day), minute (of hour), year etc. Without knowing Erlang these data type definitions typically define ranges of integer values valid for these types. Anyway, then his main points are:

• These data types can be used everywhere.
• There are no associated methods.

The first argument is odd. Let’s look at Smalltalk (or any OO language), let’s say we have a class called TimeStamp. Or Date. We can instantiate these classes from anywhere in the system, there is no reason for classes to have any less (or more) scope than data types. So objects of classes can also be used "everywhere".

The second argument is plain dumb (sorry). No associated methods? There are TONS of interesting behavior you can attach to these kinds of objects! For a true tour de force, just look at Chronos for example. The fact that Joe can make such a claim is IMHO clearly showing that he really haven’t seen how a good OO library can work. Or I suspect ever programmed in an OO language in fact.

But if we disregard this bad example, going back to the original objection, I agree - everything does not HAVE to be an object. But a LOT of the problems in many OO languages can be traced to the fact that they still retain lots of "fundamental data types" that are not objects. And most of the modern OO languages get closer and closer to Smalltalk where almost everything really is an object, just look at Python, Ruby, Scala etc.

The object concept is very powerful and its power gets even greater when applied generously. :)

"Objection 3 - In an OOPL data type definitions are spread out all over the place."

Ehm, sorry Joe but this one really shows poor understanding of OO languages. First of all, I presume you mean "data type definition" as an enum or similar. Or a class definition. Ok, and then you seem to say it is a pity that you can’t just put them in one single place - ehrm, but you can… but it would be rather horrendous design.

It is simple normal modularisation, you don’t want ALL data types/classes defined in a big global scope, right? I would in fact argue in the exact OPPOSITE - in an OOPL data type definitions are where they should be - close to the place of use. The modular way.

Anyway, now we come to the last paragraph - and it is simply confused. Let me quote:

        "In an OOPL I have to choose some base object in which I will define the ubiquitous
        data structure, all other objects that want to use this data structure must inherit
        this object. Suppose now I want to create some "time" object, where does this belong
        and in which object..."

No, no, no - why would all other objects need to inherit that class? Inheritance is normally used for specialization, the mechanism you are totally missing is composition. If my Account object needs to have a TimeStamp in it - then I simply instantiate a TimeStamp and let my Account hold onto it in an instance variable. This is basic OO, chapter 1.

It is also amusing that the examples of "ubiquitous data types" mentioned are LinkedList, Array and Hashtable. All three being standard collection classes that almost all OO languages have, no problem there, sorry. Note that Erlang was created around 1990. Smalltalk was created in the late seventies and Simula in 1967. Smalltalk has worked very successfully with an "all objects" approach and having very rich and appreciated collection classes - including LinkedList, Array and Dictionary (Hashtable). It feels like Joe thinks OO came around in 1996 with Java - nope, it is in fact much older than Erlang.

"Objection 4 - Objects have private state."

Again, confused arguments. Quote:

        "OOPLs say 'hide the state from the programmer' "

Well, yeah, in an encapsulation-and-modularity-is-good-kinda-way. Not in a programmers-should-not-care-or-know-kinda-way.

The argument about C/Pascal using scoping rules - ehm, well, OOPLs do too, hard to see the distinction there. Joe call’s the OO idea of encapsulation as the "worst possible choice". But again, no real argument for why encapsulation would be a bad thing. In fact it is one of the most important aspects of OO - the ability to expose a concept - an object - in a comprehensive high level way with a nicely designed API without forcing the user to look at all the details inside. Classical black box composition, an idea older than… old :)

And no, the blackness does not have to be strict - if the programmer wants to look I say go right ahead. I am definitely not defending the pretentious protective ideas gone berzerk in languages like Java, C++ and C# where keywords like "final", "sealed", "private", "protected" etc tend to simply make life miserable for the programmer who actually knows exactly what he or she is doing. But enough of that little rant, claiming that encapsulation is a BAD THING is … simply daft.

The final conclusion about why OO got popular does not hold any substance either - I am not even going into it. So all in all I think Joe is totally off in this article. :) Having said that I still look forward to learn Erlang, and since I am dabbling with CouchDB I might get my feet wet soon.

/Goran

I have been making movies that I am spreading within the Squeak community (primarily) and since they are around 700Mb each I decided to set up a bit torrent tracker on my Debian server. It turned out to be non trivial to find info about how this is done and now someone asked me to share - sooo, here it is - modulo things I have done clumsily.

Ok, so first I ran:

        apt-get install bittorrent

Then I ended up with a script to start the tracker software (I think you can now just tweak something under /etc/default/bittorrent to get it running) but I missed that:

        bttrack --port 6969 --dfile dstate --logfile tracker.log --nat_check 0
        --allowed_dir /someDirWith/ALlAllowedTorrents &

When the tracker runs you reach it at yourserver:6969

Next step is to generate a .torrent file for your movie file (or whatever):

        btmakemetafile http://yourserver:6969/announce yourfile.avi

This creates yourfile.avi.torrent and you should put this file in both /someDirWith/AllAllowedTorrents and make it also accessible on a website somewhere for people to find it. Final step is to start seeding, I have done this from the same server by putting yourfile.avi and yourfile.avi.torrent in a directory (and other torrents too) and then use:

        btlaunchmany /dirWithTorrentsToSeed > /dev/null &

It will take 15 minutes to pick up any new files added to that dir. And well, that is about it. :)

Good luck

OOPSLA last year in Portland was interesting as always. This report is a bit late, but better late than never. Attendance was a tad lower than I had expected - now that the industry is picking up speed again. The organization was good as always and everything follows the patterns established since long time back.

Being a Smalltalker I quickly found my fellow Knights of the Square Bracket and we formed the regular improvised Camp Smalltalk. The exhibition area was small and boring this year, earlier years we actually had the Camp Smalltalk in the middle of the exhibition, but that was also problematic since lots of Smalltalkers come by without an actual conference pass.

This year I actually gave a demonstration of Gjallar - four times! It went good I think, even though I almost missed one occasion due to a flaky schedule, and the first demo suffered from bad time estimation and got cut off abruptly at the end, my fault.

I also managed to see a few presentations, talk to a bunch of interesting people, attend the Squeak BOF of course and the regular OOPSLA events going on in the evenings.

One highlight this year was the co-located Dynamic Languages Symposium - a full day with very interesting speakers. I was not going to miss the first presentation - Ian Piumarta presenting his latest work on something he calls COLAs (or pepsi/coke/jolt). And of course, Avi finishing the day was also interesting (even though some people in the audience almost hijacked his presentation). I missed Audrey Tang’s presentation which I regret.

An interesting invited speaker was Guy Steele presenting Fortress. Guy is a good presenter and Fortress has lots of interesting aspects like for example heavy use of Traits, parallellism and rich notation encouraging the use of Unicode for source code. Quite thought provoking stuff.

Things still ringing

Every OOPSLA leaves me with a few "things" ringing in my head. This year the list goes like this in no particular order:

1. Haskell. I was not aware of Haskell until a few years ago when I discovered Darcs. Now it seemed to get mentioned everywhere - obviously the current pet of the computer science people, but also used "for real".
2. Static vs Dynamic. This war is raging more than ever perhaps since Java is loosing its hype and new kids on the block like Ruby are getting more and more attention. There is also a general frustration of the silly cathedrals of complexity being generated by some developer communities these days (think Java). As a Smalltalker it is of course nice to see the flocking to more dynamic alternatives.
3. Tons of Java blabla. Evidently the academic world, at least in the US, is still amusingly over focused on Java when it comes to student theses and research grants. The Poster reception traditionally held at OOPSLA felt like a boring competition in making Java even more complicated, or perhaps I imagined that, I dunno. Reading the first half of the Proceedings doesn’t really help that picture at least.
4. Ruby people hanging with Smalltalkers. This is fun! Ruby and Smalltalk have a lot in common - both technically and culturally. Both camps gain from this.
5. The perpetual ODBs vs ORMs discussion. Objects all the way or "cheating" using ORMs? Sometimes utterly boring and sometimes interesting to compare. Different people have very different experiences, both solutions have their pros and cons, if you haven’t tried an ODB you have no idea (just like dynamic typing), film at eleven. But isn’t there a renaissance brewing for ODBs or am I imagining it? Again, the cathedrals of complexity are causing a rediscovery of something simpler IMHO.
6. Ian's magic. I knew about Ian’s work (COLAs) before going to OOPSLA but the presentation still blew me away, like it did with most people seeing it I think. Finally something refreshing when it comes to language implementation. It has the score card full to the brim and it is under the MIT license. Please Ian, keep on coding, it already rocks but if followed through it could even disrupt the giants.

Conclusion

OOPSLA is a great conference and even though this year was not one of the best, I enjoyed it. But a popsicle on the ice cream social? That was an alltime low. :) I will keep attending if I can, even though it would be great to go to ESUG or Smalltalk Solutions too - never been to those.

Recently the ODB vs RDB subject popped up on squeak-dev and I felt like posting about my experiences. Then Todd Blanchard blogged about his experiences and reading that I really wanted to respond "piece by piece".

Todd mentions having worked with ObjectStore, Versant, Poet and a few more. I have worked a lot with GemStone (both the Java and the Smalltalk version) and used Poet with Java in a project when it was first out of the gate with a ODMG binding for Java. I have also used Magma for most of 2006 (the Gjallar project), which is a Squeak specific "GemStone light clone". I have also used one or two "lesser" ones, like Tensegrity (not around anymore?).

About the key concepts described by Todd I generally agree - even though I would probably have mentioned one or two other concepts too. Todd also writes:

"The object reference can only be accessed within a transaction - trying to read data from it outside of a transaction will fail with an exception. This makes redrawing user interfaces problematic."

I don’t share that experience - some ODBs generally think you are in a Transaction "all the time" - the question is if you end it with a commit (saving any changes made) or abort (updating the objects in your session with all changes made by others since you began). And some also allow you to run "outside" of a Transaction - generally giving you the same effect. Exactly how this affects user interfaces I don’t know - I have seen no issues regarding that.

In fact, in one project we built a DTP component that allowed multi-authoring using a domain model that was fully persisted in GemStone, and whenever someone made a modification it was immediately propagated to all concurrent viewers/editors. In fact, the performance we got would IMHO have been really hard to get using an ORM+RDB solution.

Todd then proceeds describing 9 problems with ODBs. Let me give my view on them all - I am not saying Todd is "wrong" - I just have a different opinion based on my particular experiences (especially GemStone and Magma).

1. Poor concurrency. Todd also mentions that he knows of no ODBs that use page locking. AFAIK most offer object locking, and both GemStone and Magma does that - both pessimistic and optimistically. The latter approach offers better concurrency than regular pessimistic locks. GemStone also has "reduced conflict" classes offering defined concurrency characteristics thus avoiding locks completely (and I hope/bet that Magma will get something similar over time). Using GemStone and Magma transactions should tend to be short, and most people using GemStone uses optimistic concurrency AFAIK. So sorry, this one sounds dubious to me - unless you only consider the ODBs that only offer page locking. :)
2. Lack of caching, or as Todd writes: "There is no user level in-memory caching". This also sounds very odd. My impression of all ODBs I have looked at is that almost all of them has caching and GemStone/Magma has very advanced and good cache behavior that offer lots of control. Mmm, ok, I admit that GemStone/J did not have this for non GemStone Java VMs (but if you used the Gem’s themselves as clients, which we did successfully, then it was all dandy. In other words - the GemBuilder part for Java was quite bad, at least when I used GemStone/J).
3. Hard schema migration. Again, both GemStone and Magma offers very good support. Both have the ability to have concurrent versions of classes so that it can lazily migrate objects over time. I do not recall how it worked in Poet, but GemStone and Magma works great in this respect - definitely not one bit "harder" than it "should" be.
4. Upgrades demanding downtime. Well, I am unsure about this one - do RDBs generally offer upgrades of the software without any downtime? Since I haven’t really tried to tackle such a scenario I don’t really know. I guess that one technical approach would be using some kind of online synchronization so that you can smoothly "switch over" to a newer software - and it would be interesting to hear from anyone using GemStone (or Chris that is the author of Magma) how they would deal with it.
5. Lack of support due to limited resources. We had outstanding support for GemStone, but I don’t know about their policies on older versions. Using Poet I had direct contact with the development team. Magma is open source so it is a different ball game, but Chris has been superb so far :). It is generally true that most ODB vendors are smaller - but some of them like GemStone have very high profile customers running mission critical systems - and they demand good support. Personally I have always gotten better support from a smaller vendor, but hey, mileage vary.
6. Bugs are forever. This one sounds really odd too, I guess the products I have used are different. If I screw up my objects they are… screwed up. But I fail to see how that would be different with an ORM+RDB and I fail to see why that would make "read code fail". I think I need more info because I must be misunderstanding this.
7. No security. GemStone has a very nice permission model built in. Magma does not AFAIK. Personally I have never felt a need.
8. Lack of GC. GemStone has very advanced online GC, no problem. Magma has GC, but offline as of yet (I think). ODBs differ in this respect probably because GC in a distributed transactional world is complex stuff. But I agree that GC is something you wish to check when picking an ODB.
9. No ad hoc query capability. This is not true, some ODBs support a specific query language like OQL, but even if they do not then at least when we look at the Smalltalk ODBs we all know that you "have to write a new program" to even create a class. So in fact - Smalltalk is the "query language" and "a new program" can be as short as "myCollection do: [:each | each blabla]" - much more powerful than SQL IMHO. I rather manipulate my objects using messages honouring encapsulation while offering the full capabilities that my programming language gives me - extensible to boot. All that said I still think it is nice that Magma is getting an SQL extension enabling access using ODBC - simply because that offers lots of possibilities. But I would never use it for writing.

So obviously a great deal of experience with ODBs can leave people with very different opinions. I love ODBs but I have had the opportunity to use some good ones that were made for use with Smalltalk. And there is a great lack of good open source ODBs.

But in the end I don’t think it is strange that a mature product built and designed to handle objects is better at it than a "hack" of an ORM on top of an RDB. Of course, the RDBs are very mature at what they do - and some ORMs are really good - but it is still a complicated solution with lots of drawbacks compared to an ODB.

If you already have data in an RDB that you have to work with - typically in a schema not designed to be used as objects - then I would rather like to explore solutions embracing the relational model - like ROE or SimpleORM (for Java) - making it very easy to manipulate the relational model just as it is.