Canol Gökel


Sloganı olmayan blog

XML: <!-- Weirdly --> Extensible Markup Language

I was looking at XML these days. It is really interesting language. It is very useful and I like it a lot and I used it in some of my projects to save data but as I learn how I can extend it or use the not well known features, it confuses me.

For example, you can create entities, which are like variables in other languages. You can define/declare entities like this:

<!ENTITY client "Canol">

Here, we created an entity named client and which has a value of Canol. The thing I cannot understand is that why we use such a not understandable syntax. It is against to the intention of XML, which is being readable. Why can’t we just use an XML like syntax for this, like:

<entity name="client">Canol</entity>

Ok, the user should be able to define his/her own element named entity, so let’s write it like this:

<!entity name="client">Canol</!entity>

So, a predefined element (like keywords in other languages) are beginning with exclamation mark.

You can also use entities which are not to be replaced by XML processor and then it looks even uglier, like:

<!ENTITY mypicture SYSTEM "canol.gif" NDATA GIF>

You cannot even guess why we wrote words like SYSTEM, NDATA and GIF. You should learn this weird rules of XML. It is like learning what the parts before and after semi-colons do in for loops in languages like C:

for (part 1; part 2; part 3)

You cannot guess them, you should read the rules for writing for loops from somewhere. But, for example, in Python:

for i in range(1, 5)

You can most probably guess what i does here, right? And the above example could be:

<!entity name="mypicture" type="ndata/gif">canol.gif</!entity>

XML is full of such interesting things, even <!-- and --> look ugly to me. Was there really no other way, that they have to come up with these things? Then why are they allowing us to define the xml version like this:

<?xml version="1.0"?>

And not like this:


Filed under: Programming, ,

Is Bob Rock “the” Evil?

I sometimes hear that Bob Rock is the man behind the unsuccessfulness of Metallica. Maybe it’s true but I am not sure of that. If you ever listened Metallica concert records, they are simply _awful_. They just can’t play it, just can’t sing it etc. But if you listen the same songs on albums the old ones are simply great, even James sounds great. And the awful songs from Load to St. Anger are at least listenable. And notice that the sound engineer/producer behind this albums are Bob Rock.

Also one of the Bob Rock’s recent work, The Offspring’s Rise and Fall Rage and Grace, got mostly positive reviews including me, and it was a hard job to work on an album whose group didn’t make any album for 5 years because the expectation of fans gets bigger as the gap between albums gets bigger.

Bob Rock can’t just pop and also compose the songs, Metallica should do it for theirselves. Although, I admit a great leader can always influence a group of people to make them do great things it became obvious that that great leader is not inside Metallica, they are searching a producer to be that leader. So, Bob Rock is most probably a great producer but Metallica is not just searching for a great producer, they are unfortunately so desperate that they are also in search of a great maestro. Hope Rick Rubin will help’em.

Filed under: Music, ,

Broken a Record

Today, I’ve just broken my old record of writing an errorless program at the first try with 29 lines of code which includes creating classes, subclasses, methods, comments and doing some test 🙂 Hooray Smalltalk! What is your record and in what language? Leave a comment 🙂

Filed under: Programming, ,

Smalltalk and Turkish

I realized one important thing which pulls me towards Smalltalk, subconsciously. Smalltalk’s syntax resembles Turkish in some ways. I will try to show it via examples.

The first thing which seperates Turkish from other English like languages is that verbs are put at the end of sentences, not after the subject. In English, the order of sentence components is:

Subject verb object.

In Turkish:

Subject object verb.

In Turkish, you can join subject and verb into 1 word. In that case it is like:

Object verb.

The key thing here is that objects are “before” the verbs in English and “after” the verbs in Turkish. Let’s take some examples:

1 to: 3 do: [something].

In English like languages you normally tell such a pattern as:

Do something from 1 to 3.

In Turkish:

1'den 3'e kadar birşey yap.

“1’den 3’e kadar” means “1 to 3”. “birşey yap” means “do something”. In Turkish “what to do” is said after specifying other details. But in English you first say what to do and then specify the details.

Take an example for splitting a string. A message might be formed like this:

'A string to be splitted' split.

In english you would say:

Split the sentence "A string to be splitted".

In Turkish:

"Bölünecek cümle" cümlesini böl.

“cümlesini” means “sentence” and “böl” means “split”. In programming we don’t need to specify that it is a sentence because it is understood from single quotes. So let’s form English and Turkish sentences without “the sentence” and “cümlesini”:

In English:

Split "A string to be splitted".

In Turkish:

"Bölünecek cümle" böl.

Can you see the closeness of Smalltalk expression and Turkish sentence?

'A string to be splitted' split.
"A string to be splitted" böl.

Maybe a C++ or Tcl like syntax is more close to English in this one:

split("this sentence");
split "this sentence"
Split "A string to be splitted".

This is because in Turkish, you first tell the object and then what to do with it, in contrast to English inwhich you first tell what to do and then the object in concern.

Now take the ifTrue: controlling message:

[something] ifTrue: [do another thing].

In English you would say:

if something is true do another thing.

It is close but not as close as Turkish because you give the “controlling meaning” before the condition via “if”. In Turkish you give the condition first and then give the controlling meaning:

Birşey doğruysa başka birşey yap.

“Birşey” means “something”, “doğruysa” means “if true” and “başka birşey yap” means “do another thing”.

Birşey => [something]
doğruysa => ifTrue:
başka birşey yap => [do another thing]

The classic C style is more close to English:

if (something is true) do another thing;

We can tell the same thing with whileTrue: message.

In conclusion: Although in some situations C style syntax is more close to English; in general, Smalltalk is more close to both English and Turkish compared to C style syntax. But it is even more close to a Turkish language user. There are “suffixes” in Turkish which causes some serious differences between Turkish and English/Smalltalk but the main order of sentence components causes it to feel native to Turkish people. I read somewhere about Turkish being an ideal computer language syntax but didn’t see an example until Smalltalk. But I think the suffix system of Turkish language would make a computer language design unnecessarily complex, like the article system of German language (der die das) would, too.

Maybe the thing I mentioned above is one of the reasons why I fall in love with Smalltalk syntax.

Filed under: Programming, ,


Did you tried Pardus? It is a GNU/Linux distribution not as well known as Ubuntu or Fedora but a really serious 3 year project developed by Turkish National Research Institute of Electronics and Cryptology (UEKAE), which is under the Scientific and Technological Research Council of Turkey (TÜBİTAK).

They just released their third major version, Pardus 2008, so I thought, it might be good to mention about Pardus for people who does not know it.

For me, I’m not a KDE guy and like Gnome distributions better but if you like KDE then I might suggest Pardus. It uses a different packaging system named PiSi. I don’t know if it has a GNU Smalltalk package, even Ubuntu does not have an up-to-date one, nevertheless they suffer from not having as many contributers as other distros and the package number is not as much as others.

It has some other different programs for doing things written for Pardus itself. With this and having their own art team, Pardus distinguishes itself from other distros. Pardus team uses Python and Qt for their coding extensively.

You can get more information about Pardus from:

Pardus official site:


Filed under: Linux, ,

If you want to understand blocks, then learn Smalltalk

When I was taking a look at Ruby to learn what is it like, I faced a concept called “block”. But I never got it bacause you could do everything with a block, also with traditional methods you learned so far. So I asked myself, why would a human being invent something like block? Maybe this is because of the people who tries to explain the blocks or because of my low IQ but this was the case for me when learning Ruby.

Then I started learning Smalltalk and even before I get to the blocks chapter of Blue Book, I thought there should be some kind of structure to group some expressions so that we can pass them as arguments and so that we can have controlling messages. And Smalltalk showed me the real meaning of the block concept, I got the subject at the first reading.

But if the block concept of Ruby is different then the block concept of Smalltalk and this observation is totally wrong then I would definately like to hear it.

Filed under: Programming, , ,

Steve Dekorte’s Io Programming Language

I met Io programming language a few weeks ago. It is very simplistic, minimalist and has a consistent syntax. It is a fully object oriented language inspired by Smalltalk. A significant difference from Smalltalk is that it is prototype based, so there are no classes.

To name a few advantages and disadvantages:


  • Very consistent syntax
  • Very minimalistic rules
  • Has a lot of useful methods that makes your life easier
  • Very polished source code
  • Very informative and polished errors
  • Chic documentation


  • I like the writing style:

    "Hello" at: 1 put: "a"

    instead of

    "Hello" atPut(1, "a")

    Because it is more human like.

  • Indexing begins from 0 not from 1.
  • I don’t like when a language does not want you to declare your variables before usage. I think declaring obligatory provides some kind of documentation to the user of a program.
  • Some methods does not behave what you would like it to. For example, when you write

    "Hello" at(1)

    You get the byte representation and not the letter itself.

  • Resulting elseif structures look a bit ugly.
  • No GUI library bindings yet

Of course these are all subjective.

I think the worst disadvantage is that it does not have GUI binding yet. But once it has, then it will be a killer programming language.

Filed under: Programming, ,

Dear Diary

Part I of Blue Book is almost complete, actually I read it but didn’t understand the metaclass concept, so I will read last chapter again. Then I am thinking of going through the GNU Smalltalk tutorial so that I can learn the differences between Smalltalk-80 and GNU Smalltalk syntax. Part II is the longest part of the book but once complete I will be able to do practical programming with GNU Smalltalk.

It is good that I didn’t loose my interest in GNU Smalltalk yet 🙂 Actually, I’m looking forward to do some GUI stuff with it. Especially, after seeing the beautiful problem Bichromat had written to Ubuntu forums (…

I guess GNU Smalltalk is supporting Tk and GTK.

Filed under: Programming, , ,

Something Like Comparison Table


I guess the mailing list issue I have is something related with my university internet. So, I haven’t solved it yet. Let’s continue to make suggestions from here.

One of the other things that experienced users who come across with a new language looking for is a comparsion table of that language with other languages or a simple table that lists whether the language includes some common key features of most programming languages. Like the comparison table here for D programming language:

So, I think maybe we can create such a list for GNU Smalltalk which should be very objective so that a newcomer can see the cons and pros of the language quickly. Also some “No”s does not mean that it is one of the cons. For example, a “No” for “Multiple Inheritance” or “Multiple Paradigms” means advantage for a lot of programmers :).

I started writing such a table but it is not complete because I haven’t yet learned the language completely and also don’t think I’m capable of doing such a technical table all by myself. But I will try to complete it during my learning process. Maybe somebody can also help me to add new entries/delete entries which shouldn’t be there/complete the question marks etc… Here is the first draft of it:

Key Features of GNU Smalltalk ( Last Edited on 25th May 2008 )
Object Oriented: Yes
Multiple Paradigms: No
Dynamic Typing: Yes
Garbage Collection: Yes
Multiple Inheritance: No
Method Overriding: Yes
Nested Classes: No
Nested Methods: No
Class Templates: No
Method Templates: No
Resizeable Arrays: Yes
Built-in Strings: Yes
Array Slicing: Yes (MappedCollection)
Array Bounds Checking: Yes
Modules: Yes
Inline Assembler: No
Guaranteed Initialization: Yes
Exception Handling: Yes
Macro Text Preprocessor: No
Unicode Source Text: Yes
Documentation Comments: Limited

Edit: Thanks goes to Paolo!

Filed under: Programming, ,