Smalltalk: Requiem or Resurgence? {Dr. Dobb's Journal (05/06/06) Chan, Jeremy}

> Hi,
>     I could not read the whole thread, but I will give my opinion on
> this topic. Sorry if I say something somebody already said.
>     I think the problem with Smalltalk is not technical, nor a problem
> of education either. We all now that Smalltalk has nothing to envy from
> Java, C++, .Net and the like, but the other way around. We all know that
> Smalltalk has a great VM, has a great environment and tools and no other
> main stream language can compete with Smalltalk on this features.
>     Smalltalk can be use in large project (it is not true that only
> scale in small projects, we have a project with 7155 classes and works
> great!... I can not image a Java project of 7155 files...) and I see
> that Smalltalk is not difficult to learn. Every time we contract a
> junior programmer, they feel fine with the language in a period of two
> weeks... so, the syntax is not a problem, not the class library or the
> debugger, etc.
>     The problem with Smalltalk is a MARKETING problem, no technical. We,
> people of the computer field, like to have new things all the time... we
> like to have new widgets like mp3 players, palms, cell phones, smaller
> and faster laptops, etc. "New" it is almost a synonym of "Better", but
> more important, "new" means "cool".... Because of this, most programmer
> think that  new languages are better, just because they are new they are
> "more cool". So, the problem with Smalltalk is that it is OLD.
>     Let's take Ruby as example, is it better than Smalltalk? We all now
> that it is not.... Perl? no... Phyton?, no... What's the difference?
> They are newer... Now Ruby seems to be getting a great attention... why?
> just because Ruby On Rails?. I believe Ruby On Rails is helping to get
> the attention, but Ruby is a "new" language (at least, it does not have
> a long history), and that helps, and compared with Smalltalk, it is

>     The word Smalltalk has a history, and almost everybody relates that
> word to not sucessful histories (I believe, they do it wrongly). Every
> time you say "we use Smalltalk", people ask "Isn't that a language for
> university only?", "Isn't that language old? how does it integrate to
> databases? can you do web apps with Smalltalk?", etc.... So, I have came
> to a sadly conclusion, Smalltalk will never be a main stream language
> because it is OLD.
>     Therefore, my CRAZY suggestion is to create a NEW language, a new
> language that we can name it "COOL" (because it is cool ;-) ), but this
> new language is, at the end, Smalltalk... but nobody has to know it!
> nobody has to relate it to Smalltalk because if they do it, it will
> loose all its "momentum"... With a NEW language, that it is COOL at the
> same time, and of course, with a little bit of help from one big
> company, COOL will be widely accepted... and nobody will care about its
> technical aspects as  most people don't do with the current main-stream
> languages.
>
>     Anyway, just an opinion...
>     Bye, Hernan.
>
>
>
> Ralph Johnson wrote:
>
> > People keep mentioning technical aspects of Smalltalk as being the
> > ones that will make people want to use it.  Technologists are
> > interested in technology, so this is not surprising.  However, people
> > are more important than technology.  If Smalltalk is going to have a
> > resurgence, the people who know and love Smalltalk will have to make
> > it happen.  It isn't going to happen automatically.  Jeremy Chan is
> > right to emphasize people problems like "no big company is pushing
> > it".
> >
> > Every tool has its stengths and weaknesses.  To make Small prosper,
> > people should use it where it works and not use it where it doesn't
> > work.  Smalltalk is fantastic in small groups of motivated
> > programmers.  It is not so good in large groups with high turnover.
> > People seem to get excited about large Smalltalk projects, and to long
> > for the days of ten years ago when there were 100 person projects.  In
> > my opinion, those projects were never run well, and were probably all
> > a mistake.  Many of them were successful in the sense of bringing a
> > product to market, but all the ones I saw could have been done faster
> > and cheaper with a smaller team.
> >
> > Smalltalk fans ought to go start companies.  Smalltalk has lots of
> > advantages in a startup, where it is important to get something
> > running quickly and where compatibility with existing systems is not
> > so important.  It doesn't work as well in a big company, where it is
> > iimportant to play it safe and there are existing standards and lots
> > of  existing systems.
> >
> > Smalltalk is a wonderful language both for teaching and for research.
> > I've always wondered why it did so poorly in universities.  I think
> > that one of the reasons is that it is hard to learn.  There are too
> > many things about Smalltalk that are new.  The language is easy, but
> > the class libraries are large, and the programming environment is
> > different from what people are used to.  People are not used to "live
> > objects" and do not know how to take advantage of them.  The class
> > library is not modularized, so it is hard for newcomers to see what to
> > learn first.
> >
> > Smalltalk is pretty easy to learn if you are pair programming with an
> > expert whose main goal is for you to learn, not to build a system.  It
> > is hard to learn from a book and from experimentation.  I taught
> > myself Smalltalk 20 years ago and have since taught it to a thousand
> > or so students.  I tell my students that they all will learn Smalltalk
> > faster than I did, because they will have a teacher.  This is not 100%
> > true, since some students didn't try very hard.  But it is pretty easy
> > to learn when you have a teacher who knows Smalltalk well.  One of the
> > problems with getting it used in schools is that somebody has to teach
> > the teachers.
> >
> > So, if you want to help Smalltalk spread, sit down and program with a
> > newbie!
> >
> > -Ralph Johnson
> >
> >
> >
>
>
> --
> ______________________________
> Lic. Hernán A. Wilkinson
> Gerente de Desarrollo y Tecnología
> Mercap S.R.L.
> Tacuari 202 - 7mo Piso - Tel: 54-11-4878-1118
> Buenos Aires - Argentina
> http://www.mercapsoftware.com
> ---------------------------------------------------------------------
> Este mensaje es confidencial. Puede contener informacion amparada
> por el secreto profesional. Si usted ha recibido este e-mail por error,
> por favor comuniquenoslo inmediatamente via e-mail y tenga la
> amabilidad de eliminarlo de su sistema; no debera copiar el mensaje
> ni divulgar su contenido a ninguna persona. Muchas gracias.
>
> This message is confidential. It may also contain information that is
> privileged or otherwise legally exempt from disclosure. If you have
> received it by mistake please let us know by e-mail immediately and
> delete it from your system; you should also not copy the message nor
> disclose its contents to anyone. Thanks.
>  ---------------------------------------------------------------------
>
>

> My sincere apologies. It must be something with the setup of my browsers.
> So my experience doesn't illustrate anything.
> --- Trygve
>
>
> At 15:06 12.05.2006, you wrote:
> >"Trygve Reenskaug" <[hidden email]> said:
> > >
> > > At 13:51 12.05.2006, Bert wrote:
> > >
> > > ++++++
> > >
> > > >>For all practical purposes, a desktop application written in squeak
> > > >>will only be used by squeak programmers. Note the term: "desktop
> > > >>application".
> > > >
> > > >And I think you'll be proven wrong with Sophie:
> > > >
> > > >         http://www.geeksrus.com/sophie/2006-05-09.html
> > > >
> > > >- Bert -
> > >
> > >
> > > An excellent illustration to this thread. 2006-05-09.html doesn't work

> >
> >frank
>
>
> --
>
> Trygve Reenskaug      mailto: [hidden email]
> Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
> N-0378 Oslo           Tel: (+47) 22 49 57 27
> Norway
>
>
>
>

>
> I don't know enough about SQL, but at least in the operating system
> world you can achieve a lot of portability by sticking to POSIX which
> is supported on most platforms.
> Similarly, you get pretty good portability in Smalltalk by sticking to
> the ANSI Smalltalk subset.
> Of course, GUI widgets etc. are not included in that standard and so
> are non-portable.
> But does POSIX include standard GUI widgets? Can you write a GUI
> application in C and port it from Linux to Windows without a lot of work?

> I agree with you that it would be great to have easier portability
> between the different Smalltalk systems, so you could switch platforms
> when needed without too much work.
> But in reality, switching between platforms has never been easy.
> Actually, the closest thing to effortless platform migration was/is
> *Smalltalk* with its image file which can be run unchanged on a large
> number of platforms! I've done it with VisualWorks, Squeak and
> VisualAge. The two Smalltalk-80 descendants provide much easier
> migration (just snapshot your image and start up on another machine)
> but VisualAge is pretty doable as well as long as you're willing to
> work around the quirks of the different native widgets under OS/2,
> Windows and Unix/X.

> Alejandro F. Reimondo wrote:
> > Where can we read details on FFI?
>
> Below ;-)
>
> > I am interested becasue I feel that the FFI implementation
> >  requires Assembly code to be compiled.
> > Is it true?
>
> That depends on whether you mean it literally or figuratively. For
> running the FFI there is a bit of per-platform support code needed, some
> of which (the actual call-out) is typically implemented directly in
> machine code and written using assembler.
>
> > Is there any "slow" code in slang for platforms that do not have
> >  easy assemblers?
>
> The FFI is (like many other parts of Squeak) "incomplete" in such that
> it requires a bit of extra support code to implement the actual ABI
> (e.g., setting up the call stack, calling the function, popping args
> from the stack etc). This is handled in the platform specific files (see
> sqWin32FFI.c for an example) and requires some 20 functions or so to
> work (most of those are trivial but provided just in case some platform
> has odd behavior wrt. to some data type).
>
> It is certainly possible to implement much of it without the use of
> assembler. For example, if a platform basically passes everything as
> words (32bit ints) you could do something like here:
>
> int args[MAX_ARGS];
> int argCount;
>
> /* take an int as next argument */
> int ffiPushSignedInt(int value) {
>    args[argCount++] = value;
>    return 1;
> }
>
> /* tons of other int types eliminated for brevity here */
>
> int ffiPushSingleFloat(double value) {
>    /* this will push the 32bit equiv. of the float value */
>    float single = (float) value;
>    ffiPushSignedInt(*(int*)(&single));
>    return 1;
> }
>
> /* ... double works just the same way; 2x32bit entity ...*
> /* ... structures ditto ...*/
>
> /* finally, do the actual callout */
> int ffiCallAddress(int fn) {
>    switch(argCount) {
>      case 1: return ((int(*)(int))fn)(args[0]);
>      case 2: return ((int(*)(int, int))fn)(args[0], args[1]);
>      case 3: return ((int(*)(int, int))fn)(args[0], args[1], args[2]);
>      /* ... etc ... */
> }
>
> This will work just fine and requires no assembler but so far I haven't
> found any platform where things would be as simple as that (both Intel
> as well as PPC have more complex rules than can be reasonably modeled by
> this technique). But if you happen to have a platform where things are
> that simple (or if it's okay to restrict yourself to a subset that can
> be modeled as simply) that's certainly an option.
>
> Cheers,
>    - Andreas
>

> Hi!
>
> I am not really arguing here - just mentioning some pointers about these
> bullets that might be interesting to hear about:
>
> Kendall Shaw <[hidden email]> wrote:
>> If your program doesn't look exactly like every other program and use
>> exactly the same procedure they've had to use for every program, then
>> game over, you might as well not have even bothered to write the program.
>>
>> In squeak, the controls don't look or behave like the other controls a
>> user will use on their computer, so game over, you might as well not
>> have even bothered to write the program.
>
> http://www.wxsqueak.org
>
> ...or just use Dolphin for win32 apps - it is really nice for that.
> Or turn the app into a localhost webapp, like we are currently doing
> with the issue tracker we are writing.

>> Also, I can't easily check a squeak application into a version control
>> system, separate from other squeak applications, but together with other
>> source files in other languages, and other files.
>
> Mmmmm, "easily"... well. There have been numerous approaches of
> mirroring Smalltalk code into files for that like MonticelloCVS or
> CVSTProj. I even hacked up a almost fully functional cvs pserver
> protocol implementation. ;) But these days Monticello is so convenient
> to use and just needs a file dir or an ftp server for team work - there
> is no real incentive to bother. Especially not now that MC2 is seeing
> the light.

> thanks again!
> Ale.
>
>
> ----- Original Message -----
> From: "Andreas Raab" <[hidden email]>
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> Sent: Friday, May 12, 2006 7:31 PM
> Subject: FFI usage
>
>
>> Alejandro F. Reimondo wrote:
>>> Where can we read details on FFI?
>> Below ;-)
>>
>>> I am interested becasue I feel that the FFI implementation
>>>  requires Assembly code to be compiled.
>>> Is it true?
>> That depends on whether you mean it literally or figuratively. For
>> running the FFI there is a bit of per-platform support code needed, some
>> of which (the actual call-out) is typically implemented directly in
>> machine code and written using assembler.
>>
>>> Is there any "slow" code in slang for platforms that do not have
>>>  easy assemblers?
>> The FFI is (like many other parts of Squeak) "incomplete" in such that
>> it requires a bit of extra support code to implement the actual ABI
>> (e.g., setting up the call stack, calling the function, popping args
>> from the stack etc). This is handled in the platform specific files (see
>> sqWin32FFI.c for an example) and requires some 20 functions or so to
>> work (most of those are trivial but provided just in case some platform
>> has odd behavior wrt. to some data type).
>>
>> It is certainly possible to implement much of it without the use of
>> assembler. For example, if a platform basically passes everything as
>> words (32bit ints) you could do something like here:
>>
>> int args[MAX_ARGS];
>> int argCount;
>>
>> /* take an int as next argument */
>> int ffiPushSignedInt(int value) {
>>    args[argCount++] = value;
>>    return 1;
>> }
>>
>> /* tons of other int types eliminated for brevity here */
>>
>> int ffiPushSingleFloat(double value) {
>>    /* this will push the 32bit equiv. of the float value */
>>    float single = (float) value;
>>    ffiPushSignedInt(*(int*)(&single));
>>    return 1;
>> }
>>
>> /* ... double works just the same way; 2x32bit entity ...*
>> /* ... structures ditto ...*/
>>
>> /* finally, do the actual callout */
>> int ffiCallAddress(int fn) {
>>    switch(argCount) {
>>      case 1: return ((int(*)(int))fn)(args[0]);
>>      case 2: return ((int(*)(int, int))fn)(args[0], args[1]);
>>      case 3: return ((int(*)(int, int))fn)(args[0], args[1], args[2]);
>>      /* ... etc ... */
>> }
>>
>> This will work just fine and requires no assembler but so far I haven't
>> found any platform where things would be as simple as that (both Intel
>> as well as PPC have more complex rules than can be reasonably modeled by
>> this technique). But if you happen to have a platform where things are
>> that simple (or if it's okay to restrict yourself to a subset that can
>> be modeled as simply) that's certainly an option.
>>
>> Cheers,
>>    - Andreas
>>
>
>
>

> Alejandro F. Reimondo wrote:
>> Thankyou Andreas for the explanation and code.
>> I asked for a non-assembly option to compile for PocketPC
>>  without learning assembly (to rewrite 20lines of code :-)
>
> You still need to understand the ABI and personally, I typically  
> find this harder than learning the basics of the assembler language  
> involved. For an unknown ABI I'd actually recommend learning the  
> assembler language as a starter, to understand the processor  
> architecture. It explains a lot when you read through the ABI and  
> try to understand some oddball reference to a register you've never  
> heard about and what its purpose might be.
>
> Cheers,
>   - Andreas

>
> On 12-May-06, at 9:15 AM, Charles D Hixson wrote:
>
>> (Well,
>> compilation to C would be better, but I'm presuming that this is
>> impossible.)
>
> Why would compilation to C be better? You wouldn't gain any
> performance in any serious application. Consider a moment; to send
> messages you have to do certain work. If you compiled
> ...
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Oxymorons: Soft rock

> Hi,
>
> Hans-Martin Mosner schrieb:
> > The problem with this comparison is that it is treating Smalltalk as a
> > programming language.
> > It's much easier if you treat it like an operating system or a SQL
> > database - it's a platform.
> In previous posts, Smalltalk was compared against Ruby, Python, etc. and
> why it doesn't,
> as the more mature language, get the same attention.
> Ruby, Python, Java, .Net are all a language + VM or interpreter/compiler
> (for more then one OS)
> + a basic set of libraries.
>
> Smalltalk is only the language. The language comes in a bundle with VM +
> libraries + IDE.
> So, actually you can't compare Smalltalk with any other bundle (Ruby,
> Python, ...).
> Instead you have to compare, for example Squeak, with the others.
> And that is point, that confuses people and makes the entry to Smalltalk
> difficult.
>
> > In theory, your C program should just run on HP-UX, Linux, AIX,
> > Windows, MacOSX, RiscOS, AmigaOS, ...
> > Why did all those operating system vendors invent incompatible system
> > calls, libraries, file system conventions?
> The languages we compare Smalltalk to, do this abstraction by providing
> a VM.
> > Or why can't you just take your SQL application from ORACLE to MySQL
> > or Sybase?
> > After all, SQL is a standard!
> Right, all databases have SQL 95 as least common denominator. You can
> work with
> the SQL standard.
> I was trying to say, that the least common denominator, ANSI Smalltalk,
> is to small to
> base actual work on it. No networking, threading, file system (only file
> stream), ...., database, ...
> >
> > I don't know enough about SQL, but at least in the operating system
> > world you can achieve a lot of portability by sticking to POSIX which
> > is supported on most platforms.
> > Similarly, you get pretty good portability in Smalltalk by sticking to
> > the ANSI Smalltalk subset.
> > Of course, GUI widgets etc. are not included in that standard and so
> > are non-portable.
> > But does POSIX include standard GUI widgets? Can you write a GUI
> > application in C and port it from Linux to Windows without a lot of

> better than nothing, but not a lot more.
> Every language hyped or mainstream right now, got exactly one interested
> group.
> Creating standards is easy for them.
> On the other side, Smalltalk has a lot of interested groups (dialects).
> Creating a
> standard is quite difficult.
> But without (at least) a standard library, you won't be able to compare
> Smalltalk
> to the other languages. Then you are right, you will have to compare it
> with operating
> systems.
> As a side note: At least one language from above, is successful, because
> it promised
> to overcome the operating system barriers.
> > I agree with you that it would be great to have easier portability
> > between the different Smalltalk systems, so you could switch platforms
> > when needed without too much work.
> > But in reality, switching between platforms has never been easy.
> > Actually, the closest thing to effortless platform migration was/is
> > *Smalltalk* with its image file which can be run unchanged on a large
> > number of platforms! I've done it with VisualWorks, Squeak and
> > VisualAge. The two Smalltalk-80 descendants provide much easier
> > migration (just snapshot your image and start up on another machine)
> > but VisualAge is pretty doable as well as long as you're willing to
> > work around the quirks of the different native widgets under OS/2,
> > Windows and Unix/X.
> Smalltalk showed that it is possible to overcome operating system
> barriers. It was the foundation for Java Swing and SWT. It is a: all
> been there,
> all done that. And I don't understand, why the Smalltalk community can't
> come up with a common library layer.
> Don't aim for GUI, but start with something like a common file system
> library.
> >
> > Cheers,
> > Hans-Martin
> Greetings
> Waldemar Dick
>
>

> > Creating standards is easy for them.
> > On the other side, Smalltalk has a lot of interested
> > groups (dialects).  Creating a
> > standard is quite difficult.
>
> It is called "diversity", and is an emergent observable
>  with evolution.
>
> In languages defined as one-for-all (now called "standard")
>  diversity is not observed because they are products
>  of formal design (and not of normal evolution).
>
> For formal definitions, any difference represent a problem.
> For non-formal activities a divergence is a natural path
>  to be taken by a newcommer.
> This differences make diferences in the propagation
>  process of products of formal&non-formal activities.
>
> cheers,
> Ale.

>
> I think Jason wants to talk to a server via https/ssl from squeak, not
> the other way around.
>
> Maybe this helps:
> http://www.stunnel.org/examples/https_client.html
>
> Cheers
> Philippe
>