>From: "Paul D. Fernhout" <pdfernhout at kurtz-fernhout.com>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>Subject: Re: Design Principles Behind Smalltalk, Revisited
>Date: Tue, 26 Dec 2006 08:52:26 -0500
>
>Paul Graham has an essay on why languages become popular:
>   http://www.paulgraham.com/popular.html
>In the case of both C and C++, one should not discount the wight of AT&T, 
>one of the largest and most widespread and visible companies of the time 
>(as it ran a telephone monopoly).

Well I realize this had something to do with it as well.  But I still think 
the "have something now" played the biggest role.  And even with the 
conversion from COBOL, C++ was the most widely used language for a while.  
If you go smalltalk then you train your existing folks but if you go with 
C++ or Java you can leverage that huge base of programmers.

>Well, it is also true one big issue is that an Algol-like syntax with 
>operator precedence (times over plus) is taught in K-12 school. That is a 
>big advantage for a computer language to build on that, even as that 
>precedence is arbitrary and Smalltalk is more consistent.

I actually find the operator preference irrelevant.  Personally I always 
ignored it and wrote the expression to read left-to-right how I wanted it 
evaluated.  And I did this in school as well, when I was learning it.  I was 
accustomed to the left-right orientation, why learn a new one that applies 
in just one area.

>And you are right on how Java seemed an easy move for C++ programmers. Of 
>course, now Ruby seems an easy move for Java programmers (and much of Ruby 
>is based on Smalltalk ideas), so in a matter of time, we may see Ruby 
>developers making the leap to a more self-documenting and flexible syntax. 
>:-)

Lets hope!

>Still, Smalltalk syntax was supposedly designed to be easy for kids to 
>learn. It is not that hard to learn the syntax. I've helped people in 
>business learn it. It takes at most  week to become proficient in it (and 
>often just a day). What is hard is to learn all the libraries. But, with 
>more and more programmers learning things like Java or Python or Ruby, all 
>systems with rich libraries, Ruby's being almost exactly Smalltalk's in 
>many ways, making the leap to a new syntax would be a minor investment (and 
>one worth taking because Smalltalk syntax is more extensible and 
>self-documenting than any of those other languages').

You are right, the libraries are a challenge to learn.  But this is so in 
any language that has any code for it at all.  For example, nearly any 
Haskell tutorial you look at mentions the countless times the author has 
rewritten something that was in the standard (never mind external) 
libraries.

>So, why not people moving to Smalltalk (Squeak especially)?  People in 
>Python or Perl or PHP or Ruby camps are not bemoaning "backward 
>compatibility" as the reason for limited success and adoption.

But keep in mind, python is in the same boat as Java.  I.e. if you know C++, 
it's not much of a jump to learn.  And perl is basically just bash/ksh++.  
It is a language by and for sys admins (of which there were/are a great 
many).  So if you had already been fighting with *sh all this time, perl 
wasn't such a departure.

>While everything you say it true, it is not true enough IMHO to be the main 
>reason. What are the others and how can they be addressed to produce a 
>popular free Smalltalk?

Honestly, I think we are just in the age of "the killer app".  You have to 
have something everyone needs and no other language provides, to draw people 
to you.  After that, the other things start to matter.

The things I see that squeak needs to address are: database access (I hear 
this is being worked on by Alan Knight), advanced JIT-ish technology (I'm 
expecting huge things from Exupery in this area), better thread handling and 
the ability to take advantage of native threads (don't know the status of 
this), modularity (I think Ralph Johnson will bring us a long way with this 
one).

>Java is different, as you point out. However, Java is so different, and 
>received so much attention, and incorporated so many Smalltalk-pioneered 
>ideas in the JVM design and class libraries (Swing) that ten years after it 
>has been introduced, it finally mostly works right as a self-contained 
>environment. Not quite VisualWorks, but darn close in many ways by now, and 
>it is free as in beer and is becoming free as in freedom (GPL). :-)

I think going with the GPL was actually a very bad move.  As far as I know, 
the only people who are going to care about that will be people on the 
fringe (who are, of course, irrelevant).  They could have went with BSD or 
MIT instead.

>But for both Java and Python, being able to be easily edited in vi (or 
>emacs) or being able to use a conventional text oriented version control 
>system were indeed big wins, as they reduced the learning curve and initial 
>commitment to new ideas. Being able to use the familiar file manager to 
>look at code was also of value. And going beyond vi, the fact that Java 
>IDEs started to look like C++ IDEs was another big win on familiarity. And 
>seeing each class in a separate file in the good old reliable file system 
>was also comforting -- at least you knew where your source is, and could 
>use grep or other tools to search and manipulate it and back it up in a 
>familiar fashion.

Well these are good points, but I can tell you, after being in smalltalk for 
a while and then doing some python at work I had a feeling of panic.  I 
realized I was going to have to *do something* if I wanted revision control. 
  In squeak it just happens and I never think about it unless I need to 
revert.

The grep and all the things you mentioned are a matter of training, but yes, 
a project to narrow the gap until people get off the crutches probably 
wouldn't hurt.

>Extensive tested and debugged libraries on a variety of topics.

Well, first I would call this "work", not innovation. :)  If smalltalk had 
the number of bodies working on it that Java has had we would have solved 
cancer by now.

And this isn't only a smalltalk compatibility issue.  *No one* that isn't on 
the JVM can use these.

>>Typically?  It is harder in every case, no matter how badly designed the 
>>programming language.
>
>Well, Spanish to Portuguese might be easier than COBOL to OCaml? But COBOL 
>to OCaml is hard for different reasons than syntax. :-)

Actually there is a story somewhere of a student who learned fluent Spanish 
and then took a trip to Brazil.  He figured it was close enough, and it was. 
  He adjusted very quick.  But he has a terrible time talking spanish now 
since the languages *are* so close.  Human language is just incredibly 
complicated.  You really do, as you mentioned, have to absorb some of the 
culture as well to get fluent.

>My point here wasn't that Squeak should change; it was just an example of 
>how being different and staying entirely in Smalltalk might not have been a 
>big win, compared to just having a VM written in, say, C. There remains the 
>"conceptual" barrier of the VM domain, even as the "technical" one of 
>syntax is removed.

I know what you mean.  I just think in this case it doesn't really apply.  
If the VM had been written in C then the people who worked on it probably 
wouldn't have.  And that would have just resulted in no squeak at all.

>Translating primitives into C or Java, like for sound manipulation, seems 
>like a bigger win. But even then, you have to be writing that code (or 
>rewriting that code) in such a non-Smalltalk way semantically that it is 
>still not clear to me if there is a lot of value in it. Especially when the 
>alternative might be to just call an existing sound synthesis library 
>written in Java or C. We now have Java for a good cross-platform language 
>with equivalent to C++ performance, so it would have been a harder choice 
>ten years previously  as to what cross-platform language to use if not C 
>with all its quirks (Free Pascal?).

Well I think projects like Exupery will be important here.  If it works out, 
then smalltalk code will be able to compete with C or Java in many cases.  
And Java is no better for a cross platform language then smalltalk is.  They 
are both running on VMs.

Now if we ignore Java the language and consider the VM itself as the 
computer that our languages compile to then ok.  But I don't think Java has 
the best VM.  The problem is, the Java VM is made for a static language and 
dynamic languages have to be bolted on.  Microsoft had the same problem 
since they just wanted to basically fork Java.  But as I understand it, both 
are moving toward the idea of having the VM be for dynamic languages and 
build static languages on top of that.  If that is the case then something 
like Strongtalk is already ahead of the game.

>But here again is an issue of culture. Who cares if Sun is "behind"; or if 
>Squeak runs 30% slower without some extra dynamic dispatch opcode in the 
>JVM? Speed is not Squeak's main problem. Being able to leverage Sun's JVM 
>and the fact that you can call AWT classes in the same way for any platform 
>Java runs on is a big win for Squeak IMHO, as it would reduce the 
>maintenance burden of it in terms of complexity of the common code base, 
>and would also make it easy to install one common package for any platform 
>Java runs on. Ten years ago, or even five, I myself would have laughed at 
>the value of this idea (as Java was so buggy and unstable and slow). But 
>most of the bugs have been fixed, the 1.5 JVM shares memory across JVMs and 
>does dynamic translation for speed, so Java finally, now that it is going 
>free under the GPL, has the potential to be a great cross-platform tool 
>where you get both a common base GUI window system as well as the ability 
>to deliver fast primitives written in Java, as well as access to a lot of 
>libraries someone else has already written and debugged for you.
>
>The Squeak community could admit that it would be a big win to leverage 
>that "pink plane" success, even if it is "behind" and decide to move 
>forward on top of it, but in other "blue plane" directions. Or it can 
>continue to spend a lot of time dealing with time consuming basic issues 
>relating to packaging and testing C code for lots of platforms (which 
>essentially just duplicates the work the Java community is doing, but not 
>as well because of more limited people power).

Well those are all good points.

>dot net is a non-starter because it is proprietary (and may be covered by 
>patents). And I would not make this suggestion without basing it on Sun's 
>move to the GPL for Java. There are several JVM Smalltalk already of 
>course.

Don't make the mistake of assuming the world is how we really *want* it to 
be.  dot.net is getting more popular all the time and may end up beating 
Java in the end.  Linux has been GPL from the start but windows is still the 
king of the desktop and growing in the server realm.

And I would be hesitant *because* of Sun using the GPL.  The license has the 
reputation for being viral (even if it isn't anymore) and therefor many 
companies avoid it.  For example I work for a very large company who will 
only allow GPL code to be used in isolation (i.e. as a stand alone program), 
never something to build on top of for fear of having to give away trade 
secrets.

A license that says you *must* make source code available isn't any more 
free then what Microsoft provides.  It is just restricted in a different 
way.

>   http://www.robert-tolksdorf.de/vmlanguages.html
>But none have the power of Squeak. And, building on Squeak's strengths, it 
>could be an opportune time to also shake off licensing problems, say by 
>carefully comparing with and using GNU Smalltalk code when possible, or by 
>using an approach like Bistro to leverage Java libraries temporarily until 
>replacement versions in Smalltalk could be written in a true "clean room" 
>fashion.

Well gcc can optionally output XML instead of assembly code.  I wonder about 
using something like this to convert C projects to smalltalk directly.  And 
this may work for all the gcc compilers (e.g. Java).

>Why not have Squeak in that role too? But the deeper question is, why is it 
>not there already, and why has, say, Talks2 not gotten more effort behind 
>it?

It is a matter of people time.  Everyone always asks "why hasn't <the 
project I'm interested in> gotten more effort behind it?".  There is no free 
effort left to get behind it.  And these questions wont inspire like a 
Braveheart speech before a battle.  All I can suggest is; if you believe in 
it get behind it.  Hopefully others will follow but don't expect it.  I am 
personally looking at ways to pay to get work done in squeak I want to see 
done but don't have the time to do.  Maybe with rentacoder.com or something.

>And I think that issue has to do with community issues and also licensing 
>issues than technology issues. (I myself would build on Talks2, right now 
>except it is stuck in the same licensing ambiguity Squeak is; I'm hoping 
>when Squeak gets that cleared up for itself, that Talks2 might follow).

I did a quick look at the talks2 page and it said you are granted all the 
rights to anything you write on it, to sell or not sell.  What is ambiguous 
about that?  It sounds as free as it gets to me.

Thanks,
J

_________________________________________________________________
>From photos to predictions, The MSN Entertainment Guide to Golden Globes has 
it all. http://tv.msn.com/tv/globes2007/