Hello group,

I have been reading through the mail list archives and I thought I would 
share my thoughts as an outsider (at the moment) to the smalltalk community. 
  I appoligize in advance for the size of this email. :)

Computers were not my initial profession, so I came in from a learn-as-you 
go situation.  But I have been in IT over 10 years now and think I have a 
pretty good idea of a possible silver bullet when I see one. :)  Smalltalk 
seems to be the perfect development environment and what's more; it deserves 
to be used more then the languages that are used right now.

Before I was an effienciency/static typing junky, but smalltalk has made me 
rethink the typing at least. :)  After all, how many errors *has* that 
really caught for me compared to all the times code didn't compile because 
the compiler was confused about something that should work.

Smalltalk even showed me that self generating code could be a good thing.  
When I first heard of, and thought about the possibilities of this years ago 
in Perl I cringed.  But the reason I cringed was simple:  Assembly, C/C++, 
Perl, Java, everyone else really have two distinct modes:  Design mode 
(where your code is layed out and how) and runtime mode (what it actually 
looks like as a running system).  Self modifying code in this situation is a 
scary thing because it pushes those two modes even further apart then they 
were to begin with (which is often pretty far).  But smalltalk opened this 
door for me because it doesn't have that problem.  The design and runtime 
modes are almost the same thing.  If I impliment a "doesnotunderstand:" that 
builds any messages it recieves, let it run for a few days and then come 
back, the system will have made my methods for me.  Then I can take that 
method out if I want.  Amazing.  But it's ok, since the source code and the 
running system are almost one and the same this practice doesn't cloud my 
view of what the running system looks like.

As I have been looking through the programming languages out there (have 
been between jobs, so I decided to brush up on my programming a bit) you 
can't help but see lisp.  I know lisp people hate to hear it, but lisp seems 
like the best of research languages.  It seems like every advance in 
languages came from lisp at one point or another.  But it feels like 
smalltalk has taken the advances and made them usable by the normal man.  
And smalltalk did the right thing taking the real ideas, not a castrated 
version of the idea.  The exception mechanism for example (see C++, Java, et 
al), smalltalk has method resumes, restarts, everything.

Perl is the classic case of a sense of loyalty taken too far.  A man saves 
your life (and perl did save us.  We were programming CGI in C before it 
came along and woke everyone up) but as time goes by he has asked to move in 
with you (perl decided cgi and sys admin wasn't enough, it wants to develop 
all your apps!) and one day you dont see him anywhere but cloths are all 
over the floor, perl and your wife are no where to be seen and there is some 
uncomfortable noise comming from upstairs.  But he saved your life right?

Perl is a disgusting hack from top to bottom.  It is a filesystem based 
language like the rest, but even having a source of more then one file is a 
hack.  "Why do I need a 1; at the end of my file again?  Oh right, someone 
somewhere might want their file to execute code when it gets included and in 
perl TIMTOWTDI!  Since they might, we all must?  What was that you said 
about 'simple things simple, hard things...'?".

Ruby is of course appealing because it has something like the smalltalk 
syntax.  But in the end it is a script language and to get where it needs to 
be to be the best it needs to, well, be what smalltalk is right now.

What about Java?  Well you can build anything you want with turds and glue.  
You can build a big boat, you can build a huge castle, but what do you have 
at the end?  A big smelly pile of crap.  That is what Java is in my mind.  
If the universe is "turtles all the way down", smalltalk is "objects all the 
way down" and Perl is "hacks all the way down" then Java is surely 
"inconsistancy all the way down".  And just as perl has shown, a million 
monkeys typing on a million keyboard wont reproduce the works of 
Shakespeare, and it also wont turn a big pile of crap into a Ferrari.  But 
it might be able to build something to get you to work if you can bear the 
smell.

So what went wrong?  You have the right idea, why isn't everyone here 
already?

Reading through the list, a few things struck me:

First, Luckas and Andreas fighting over extending functionality vs. backward 
compatibiltiy.  Well, I wouldn't presume to take sides in such an argument, 
but there are a couple of important points we must always keep in mind: 
backward compatibility is a noble cause.  No one wants to work where they 
syntax of the language can change before you can even get your program that 
used the "old" syntax finished.  But on the other hand, backward 
compatibility is an open paracute on your back.

In Estonia in the early 90's it was not uncommon to not have running water.  
Only about 50% of the population had a phone line.  But in 2004 Estonia 
became the most technologically advanced nation in all of EU, maybe the 
world.  It has the largest % of cell phone users, the government was 
completley paperless!  How did they come so far so fast?  Simple: no 
backward compatibility what-so-ever.  No one screamming "Wait!  I'm still 
using windows 3.1, we can't make that change!"  No open paracute's on 
anyones back.

So what is the right answer between Luckas and Andreas?  I don't know, but 
when we talk about backward compatibility, while we dont want to break 
things just to say we did, we also can't get in a situation that takes 15 
years to dig out of.  In some cases backward compatibility is the 100% right 
answer, but in my mind the backward compatibility side has 1 default mark 
against it.  If it is indeed the right answer, then it should be able to 
overcome this easily, and perhaps this particular argument is just such a 
case.

Scripting.  Do we need it?  Well Java doesn't have it.  C++ doesn't have it. 
  And those are the two most popular languages afaik.  But both of those 
have huge business backing them.  The languages that do *not* have this kind 
of backing, but are sucessfull are all script languages, or can run in 
script mode.

How hard would it bee to just make an image that looks a little different 
then the default image, it expects arguments set up the way they are with 
typical #! setups?  And any syntax chosen needs to look as close as possible 
to what smalltalk is now.  No new strange constructs that are totally 
different inside the image, no meta-programming as a rule.  It needs to look 
like it does in the browser.

Tim is right, this would be a step back.  Smalltalk has a much better 
environment if you just use the image.  But what is more important at this 
point: being right, or getting a bigger base for the language?  I know which 
one I would pick.  I know it's frustrating having the solution and having to 
stuff it down peoples throats, but if hair dryer companies can put those 
stupid labels on hair dryers, can't we give a scripting option?

And hey, when a squeakscript user says "By the way, have you guys got any 
kind of debugger?"  Out pops the smalltalk salesman complete with a huge 
grin and a cheasy suit saying "Why sure!  Just run this" and presto, when 
they see they can change code in the debugger and it just resumes from 
there, most of them are going to become converts.  But first you have to 
drag them kicking and screaming somehow.

I'm sure the Howard Aiken quote is familiar to all smalltalkers: "Don't 
worry about people stealing your ideas. If your ideas are any good, you'll 
have to ram them down people's throats."

What smalltalk also needs is a killer app.  Maybe seaside will be that 
killer app if the inferier language crowd doesn't steal it first.

But no matter how you get them here, it wouldnt matter one bit today because 
they wont stay.  Why?  Because smalltalk documentation is like a ghost town. 
  When I found whysmalltalk.com (shows up #4 if you google "smalltalk 
tutorial") I was excited about all the examples and tutorials.  After 90% of 
the links pointed nowhere I started doing searches on the net to find out if 
I was simply too late, maybe smalltalk was dead already.  And your own 
squeak site isn't much better.  Nothing screams "no one lives here anymore" 
like dead links.  And the more dead links the loader the scream.

One thing I think I disagree with stéphane about (not sure I understand his 
point exactly) is the releases.  If a squeak version is released in the 
forest and no one is there to see it, will anyone care?  Fixing bugs are 
important if that's what you mean by release.  New features to help support 
those killer aps are important.  But if you don't have any documentation 
anywhere no one will stay.  I stayed because I was determined to fix this 
gap in my knowledge and learn this language, dead or not.

And dont go down the road that "smalltalk is simple so the code documents 
itself".  The code NEVER documents itself, that is a cop-out and a bold face 
lie.  If you don't want to document then for God's sake, hand it off to 
someone who will.  Not every single method ever of course, but anything the 
API user uses directly should be documented.

And it needs to be consistant too.  I'm a "digger", if it is there I will 
find it.  But most people aren't.  If your solution is "well go to the class 
side, there is maybe some method there that documents the class" then you 
don't have a solution.  "Documentation is always on the class side in the 
'documentation' protocol (and here is how you find that)" would be much 
better.

You have a very friendly mail list, the best I've ever seen to be honest.  
But that doesn't overcome documentation.  People are not trained to look on 
mailing lists for documentation.  When thinking about users you have to 
think Homer Simpson.  You can scream "look in the news groups" on every page 
and he will say "Thanks, what is the link to/program that shows the 
documentation?".

I hope someone somewhere finds something I said useful. :)