Re: Good news from FOSDEM: article in the c't magazin

[Nicola Pero]

Hi Stefan, I started writing something but then ran out of time.  Just
thought I would send you the unfinished email as it is, in case it helps
you, rather than throwing it away. :-)


> This is the plan so far. If you have suggestions what could be improved or
> what should be added, please let me know.

Ok - here are my suggestions.  Feel free to copy / rewrite any parts of my
comments into your article.  Of course you can ignore them all :-) it's
just generic suggestions, or better, it's just the standard rant of a
developer for his preferite software :-)


One of the key points we want to give to the audience - in my opinion - is
that while gnustep was mainly born to be a full graphical user
environment, it's not only that.

The most advanced part of gnustep at the moment is the non-graphical part
of it.  gnustep-make + gnustep-base is the definitive Object-Oriented
non-gui development environment.  It just ridiculizes all competitors -
it's by far better than all object oriented foundation frameworks
available for gnu/linux (the only one which stands is Java - but
gnustep-base is much faster, and it's free).  And it's finished - and it's
ready - and it is compatible - with minor tweaks - with MacOS X cocoa
Foundation.

Just take any feature ... gnustep-base is one step forward than anything
else available ... for example, gnustep-base has string objects supporting
unicode.  Other toolkits have that ... but our strings have a
class-cluster design, so the system is able to optimize the treatment of
*each* string depending on whether it's a C string or a UTF-8 string or a
full unicode string.  We have inmutable vs mutable strings ... which
allows automatically different objects to share strings and only copy them
when strictly needed.

When a toolkit says that they have unicode support built in their base
string class, that normally means that all strings will take the double of
memory, and that everything will be slower - but not on gnustep !  
gnustep is already at the next stage - both having full transparent
unicode support, and having a framework which can automatically optimize
down to the C string case behind the scenes when you use C strings!  That
without yourself knowing or doing anything about it.  You use a single
unicode string API.

This example of strings is impressive because this class cluster
architecture is possible *because* we are using dynamic binding.  You just
send a message to a string ... you don't actually know the concrete class
of the string (if it's a C string or a UTF-8 string or a full unicode
string or a mutable string or a non-mutable string) till runtime.  So -
when people say that OO dynamic binding makes the language slower ...
(they usually say that in comparison with C++) ... well you can point them
to the fact that using OO dynamic binding you can implement such big
design optimizations in the foundation classes that probably balance -
them alone - the fact that you are using dynamic binding at all!  (oh -
you can probably implement transparent string class clusters in C++ but
whatever implementation you use is equivalent to using dynamic binding -
and if you start dynamically binding all calls to the foundation string
classes, and if you do that to get more performance, then all the point of
using C++ because `dynamic binding is slower' becomes totally meaningless)

<this comparison with C++ was probably really just a rant, I have no idea
of the order of magnitudes - except that I know that the overhead of
dynamic binding is so little that it seems reasonable to me that the
excellent design of string management gets a speed boost of the same order
of magnitude - everything depends a lot on the application>

gnustep-base can dynamically load classes from files.  It's like having
the full power of Java dynamical loading facilities, but working at the
speed of C !

gnustep-base can do distributed objects.

Don't forget to say that Objective-C has categories and forwarding, which
Java doesn't have.  So, paradoxically, Objective-C is more dynamical than
Java, and at the same time faster.

[ mail truncated - sorry - ran out of time ]