## 2010-04-26

### Languages, OOP, Sather et al.

I used to dislike OO programming paradigm. I suppose the main reasons were that I started programming with imperative languages and loved so much mc68k assembly, and that people trying to convince me about the advantages of OOP failed —often talking about the wrong feature in the wrong way (e.g. magnifying functions overloading... which is not a OOP-only thing, e.g. Fortran 95 and later has it!)

Moreover, because of reasons I don't know, C++ does not light my enthusiasm. And so it is for Java (recently I've deleted Google Android SDK... tried to get interest into J2ME for a brand new phone I now own, but it is always... well... Java). I changed a little bit my mind about OOP when I first came in contact with Objective-C. I feel it is the right language that exhibits the right amount of OO features; OO concepts are insinuated in the "C core" better than C++, and Objective-C can at least one thing that currently C++ (AFAIK) can't: extending classes we have not the code of.

Objective-C takes something from Smalltalk, and this language too can extend a class without touching its code. I like Smalltalk too, and luckly GNU Smalltalk can be used as an interpreter, allowing file-based programming. Smalltalk is more "coherent", I mean: everything is really an object. It is not so for Objective-C and C++, which inherited (!) from C primitive types that are not objects. However C is still my preferrend imperative language (when I don't want to stick to Fortran and interpreted languages like Perl are inappropriate), so Objective-C win against Smalltalk, that, by the way, is also not so efficient (read: it is slow).

Got over the primitive "hate" for OOP and OO languages thanks to Objective-C and Smalltalk, there are other details that can make me dislike a programming language. E.g. I don't like that "white spaces" have syntactical meaning. Thus I could like Python (and Haskell), but indeed I ended to dislike them. Another detail is when upper-case or lower-case letters have syntactical meaning too. This detail would rule out other languages (even though I admit they can be cool and powerful).

But recently I decided to take a look at Sather. I wanted just to taste it. Sather uses all upper-case letters for classes, but other OO peculiarities are again more elegant than how C++ or Java take it. The syntax looks to me clear, I like how iterations are performed (I've seen something similar in Ruby), and ... we can create superclasses.

Creating a superclass could mean we can add "behaviours" to a "middle" class. Let us suppose we want the INT class respond to a factorial method (if not already defined into INT). We can create a superclass of INT holding the method. When it is called, the INT class, having no that method, "passes" it to the superclass... where our new method is defined. The result is that we can write

4.factorial

to obtain the factorial of 4, where 4 is an instance of INT which alone has no factorial method. It sounds good, but it does not work. I've tried to understand what's going wrong, but failed. Sather language documentation is spartan, lacks details (to know builtin methods of standard library I had to take a look at the code!). The tutorial uses superclassing, subclassing and abstract classes for typebounds (in generics), even though a sentece let me hope it is possible to use superclasses to obtain what I want. Likely I've not understood something important, but surely "extending" a class is not so natural and easy as it is in Objective-C
and Smalltalk.

I think I won't go too much far with Sather, but first I would like to try to write something really "OO" in Sather. I feel that, from the OOP point of view, Sather has some oddities; I would like to focus them to compare it better with other OO "solutions" (i.e. languages), in other words to confirm that the worst implementations of the OO concepts are those of the most used and widespread languages.

#### 2 comments:

1. These days I played with c.
I had forgotten how bad the strings were uncomfortable and dangerous, googling around,
I found a review of the various libraries
http://www.and.org/vstr/comparison

2. C's still a great language; I don't see problems with strings: for most uses it's ok to handle strings for what they indeed are (a sequence of bytes), for other uses a more high level approach is needed; currently I would go for custom implementations or glib.