f



Why smalltalk?


I guess it shouldn't appeal to everyone. But I'm having some hard time
convincing myself to keep on learning smalltalk in much detail. Instead
preferring to focus on lisp-scheme, forth, and to a lesser extent tcl.

Here are the reasons.

1. It seems OOP is the main reason d'etre for smalltalk. But it can be
done in lisp-scheme, forth, and tcl, and in many different ways too.
Considering that there is no one definite way to do OOP, why would I
restrict myself to the smalltalk model of doing it when I can have a
look at clos, prometheus, xotcl, snit... etc. Those languages have OOP
extensions that range from the minimalist to the complex.

2. Smalltalk is single paradigm. Those languages above, especially
lisp, are capable of being extended to support many paradigms. Why
would I restrict myself to OOP, and to one way of doing it? It would
seem to me that lisp and forth perhaps are better language to try to
master for the future as they can be adapted to accomodate future
trends and ideas without needing to change the language.

3. Smalltalk, Squeak in particular, focuses too much on GUI. I look at
its future direction, such as croquet, and I'm a little perturbed. 3D?
Why? As if 2D GUIs weren't too much of a distraction. I got into
programming this time after becoming fed up with GUIs. It started with
awk for doing csv simple databases and then tetex for documents. That
was a revelation. I could use plaintext and not worry about formats,
tools or platforms. I also found that I like bash and grep. As a result
I haven't used Office software for a long time and when I install a
linux distro first thing I do is delete openoffice. I much prefer to do
things now with the CLI and a simple text editor. With Squeak its GUIs
all again. Type in a litle on the keyboard, reach for the mouse, click
for context menu, then click print it or do it, mouse again... argh.
That's why I'm not quite fond of Squeak. I think GUIs are bad in the
long term and text-cli is simpler. It also introduces much unneeded
complexities. I could perhaps use GNU smalltalk, but the arguments of 1
and 2 still apply to it, and it doesn't seem well documented enough for
a newbie to learn it.

4. Lisp and forth have excellent books and documentation, ranging from
newbie to very advanced. Lisp for example has the MIT and UCB
literature, and forth has the Brodie's books. And those books teach me
not only their languages, but programming and computer science in
general. The problem with smalltalk, though many free books are
available, they seem to have too much of a narrow range of concern, and
that is, 1) OOP 2) GUI, lots and lots of GUI emphasis 3) a particular
commercial smalltalk.

So I'm failing to see smalltalk as a suitable learning language, and,
also, as a suitable main general-purpose long-term language to focus on
and hope to master. At least for me with the above implied preferences.
Please correct me where I'm wrong.

0
casioculture
6/30/2006 4:36:05 AM
comp.lang.smalltalk 3549 articles. 0 followers. Post Follow

9 Replies
718 Views

Similar Articles

[PageSpeed] 30

On Thu, 29 Jun 2006 21:36:05 -0700, casioculture wrote:

> 1. It seems OOP is the main reason d'etre for smalltalk. But it can be
> done in lisp-scheme, forth, and tcl, and in many different ways too.

This cuts both ways from a learning perspective: you only get to know
one approach, but also you only need to deal with one approach.

There are different kinds of OOP, Smalltalk is the one where 
class-based OOP is implemented without distractions. Self, JavaScript
or Io (www.iolanguage.com) are prototype based, which is similar,
but not the same. CLOS and Dylan use generic functions, which
requires a completely different way of thinking. 

> 
> 2. Smalltalk is single paradigm. Those languages above, especially
> lisp, are capable of being extended to support many paradigms. 

Which, in the case of lisp, also means that they carry 
lots of baggage where some burden is put on the newbie for
historic reasons. As an example, I've never understood, why
there is no *single* accessor function for sequences, instead
you have (elt list index) and (aref vector index).

From a SBCL session:
  * (elt '(1 2 3) 2)
  3

  * (aref #(1 2 3) 2)
  3

  * (elt #(1 2 3) 2)
  3

  * (aref '(1 2 3) 2)
  debugger invoked on a TYPE-ERROR: The value (1 2 3)
  is not of type ARRAY.

Things like that annoy me, nowadays more than when I was younger.

> 
> 3. Smalltalk, Squeak in particular, focuses too much on GUI. 

Squeak is a tool, which is often used for GUI related work and
experiments. But nobody stops you from running a headless image
with seaside as a webserver. 

I guess part of the public emphasis on GUIs is that you can quickly
*see* the effects of your work instead of only experiencing it
second-hand through a working web application.

> 
> 4. Lisp and forth have excellent books and documentation, ranging from
> newbie to very advanced. Lisp for example has the MIT and UCB
> literature, and forth has the Brodie's books. And those books teach me
> not only their languages, but programming and computer science in
> general. The problem with smalltalk, though many free books are
> available, they seem to have too much of a narrow range of concern, and
> that is, 1) OOP 2) GUI, lots and lots of GUI emphasis 3) a particular
> commercial smalltalk.
> 
> So I'm failing to see smalltalk as a suitable learning language, and,
> also, as a suitable main general-purpose long-term language to focus on
> and hope to master. At least for me with the above implied preferences.
> Please correct me where I'm wrong.

Pick one language at one time and immerse yourself. Try to do everything
in it. After, say 6 months or a year, tackle the next on your list.

s.
0
Stefan
6/30/2006 11:48:39 AM
Good questions.  Others will post answers to your specific points.  But 
speaking from my own experience, I'd encourage you to learn a broad spectrum 
of computer languages.  Each one will show you a slightly different 
perspective.  And include things like Prolog and Snobol.

I believe that over time, the elegance of Smalltalk of will become self 
evident.  Yes, it does have a strong OO bias, but that's because it was 
created from day one a 'person centric' tool.  The language itself evolved 
from a desire to better enable people (specifically children) to program a 
computer.  Thinking in terms of objects was the most obvious way of modeling 
the problems; the language grew from that.

As your applications grow in size and complexity, the utility of having an 
OO model will really show its strength.  Within our application (VA + GS) we 
make use of concepts learned from other tools, and easily implemented in 
Smalltalk.  There is no reason why you can't use OO to implement a state 
machine, for example.

Your observation that documentation for new Smalltalk users is weak is true. 
We're working on it.  I strongly believe the reducing the barrier to entry 
to people interested in Smalltalk is fundamental to growing the use of the 
language.

Personally, I think you should keep looking at Smalltalk.  It does take a 
while to get the bigger picture... I hate the way that sounds, but its true. 
At some point you do start seeing software problems differently.  My 
personal epiphany happened when I learned to model transaction objects: if 
you need to transfer money from chequing to savings, you don't delegate that 
to either account object, you create a 'transfer' object and have it do the 
work.  Just like you need a farmer to milk a cow; a cow can't milk itself, 
and milk cannot un-cow itself.

Bob Nemec
STIC

<casioculture@gmail.com> wrote in message 
news:1151642165.129887.209450@y41g2000cwy.googlegroups.com...
>
>
> I guess it shouldn't appeal to everyone. But I'm having some hard time
> convincing myself to keep on learning smalltalk in much detail. Instead
> preferring to focus on lisp-scheme, forth, and to a lesser extent tcl.
>
> Here are the reasons.
>
> 1. It seems OOP is the main reason d'etre for smalltalk. But it can be
> done in lisp-scheme, forth, and tcl, and in many different ways too.
> Considering that there is no one definite way to do OOP, why would I
> restrict myself to the smalltalk model of doing it when I can have a
> look at clos, prometheus, xotcl, snit... etc. Those languages have OOP
> extensions that range from the minimalist to the complex.
>
> 2. Smalltalk is single paradigm. Those languages above, especially
> lisp, are capable of being extended to support many paradigms. Why
> would I restrict myself to OOP, and to one way of doing it? It would
> seem to me that lisp and forth perhaps are better language to try to
> master for the future as they can be adapted to accomodate future
> trends and ideas without needing to change the language.
>
> 3. Smalltalk, Squeak in particular, focuses too much on GUI. I look at
> its future direction, such as croquet, and I'm a little perturbed. 3D?
> Why? As if 2D GUIs weren't too much of a distraction. I got into
> programming this time after becoming fed up with GUIs. It started with
> awk for doing csv simple databases and then tetex for documents. That
> was a revelation. I could use plaintext and not worry about formats,
> tools or platforms. I also found that I like bash and grep. As a result
> I haven't used Office software for a long time and when I install a
> linux distro first thing I do is delete openoffice. I much prefer to do
> things now with the CLI and a simple text editor. With Squeak its GUIs
> all again. Type in a litle on the keyboard, reach for the mouse, click
> for context menu, then click print it or do it, mouse again... argh.
> That's why I'm not quite fond of Squeak. I think GUIs are bad in the
> long term and text-cli is simpler. It also introduces much unneeded
> complexities. I could perhaps use GNU smalltalk, but the arguments of 1
> and 2 still apply to it, and it doesn't seem well documented enough for
> a newbie to learn it.
>
> 4. Lisp and forth have excellent books and documentation, ranging from
> newbie to very advanced. Lisp for example has the MIT and UCB
> literature, and forth has the Brodie's books. And those books teach me
> not only their languages, but programming and computer science in
> general. The problem with smalltalk, though many free books are
> available, they seem to have too much of a narrow range of concern, and
> that is, 1) OOP 2) GUI, lots and lots of GUI emphasis 3) a particular
> commercial smalltalk.
>
> So I'm failing to see smalltalk as a suitable learning language, and,
> also, as a suitable main general-purpose long-term language to focus on
> and hope to master. At least for me with the above implied preferences.
> Please correct me where I'm wrong.
> 


0
Bob
6/30/2006 12:40:31 PM
Bob Nemec wrote:
> Just like you need a farmer to milk a cow; a cow can't milk itself,
> and milk cannot un-cow itself.
Yes, if you model the real-life, but the virtual-world (computer science
one) isn't the real life, just an artifact of some real-life aspects.
Indeed, take as example the audio CD reader: a user put the CD in the reader
in order to listen musics. According to your mind, we have to model the CD,
the reader and, why not, the user that put the CD within it.
But in fact, this is mandatory in our world for listening musics in a
desktop for example: the music is encoded into audio tracks that are
carried in a CD and we require material in order to listen them. In the
virtual-world, we don't require them. The only think that we want is to
listen musics and to handle it, and the virtual-world can provide you
theses facilities without inserting intermediary entities. The music is
modeled as itself, no needs to representing the CD, the reader or the user:
no means in this world; the music is an object that can live as itself in
this virtual-world and as such it can play itself. In the virtual-world,
the OS should be only the layer that manages and provides transparently
mapping betweens the real-life entities (materials) and the virtual-world
ones. But upon it, IMHO what we call the user space should be the
virtual-world as itself and we have to think differently than we used to
think in our own world; we have to concentrate ourself to the 'what'
question than to the 'how' one.
0
Miguel
6/30/2006 1:09:33 PM
Miguel,

This may sound insulting, but it isn't meant to be.  It looks to me like
you're trying to convince yourself not to learn Smalltalk.  If you don't want
to spend some time learning a different way of programming that many people
have found to be highly productive, then don't.  It's that simple. If you
don't really want to learn it, don't waste your time.  And don't waste the
time of people in this newsgroup asking to be convinced of how wonderful it
is.  

If I've misinterpreted your posts, I apologize.  In that case, you should just
dive on in.  Google 'free Smalltalk books', download VisualWorks NC, and start
on in.  If you don't get this stuff after a couple of months of honest effort,
you probably never will.  I found it easy, but I know intelligent people who
don't.  It's not for everyone.  But what have you got to lose by trying it? 

Jeff

Miguel Moquillon <miguel@home.fr> writes:
> Yes, if you model the real-life, but the virtual-world (computer science
> one) isn't the real life, just an artifact of some real-life aspects.
> Indeed, take as example the audio CD reader: a user put the CD in the reader
> in order to listen musics. According to your mind, we have to model the CD,
> the reader and, why not, the user that put the CD within it.
> But in fact, this is mandatory in our world for listening musics in a
> desktop for example: the music is encoded into audio tracks that are
> carried in a CD and we require material in order to listen them. In the
> virtual-world, we don't require them. The only think that we want is to
> listen musics and to handle it, and the virtual-world can provide you
> theses facilities without inserting intermediary entities. The music is
> modeled as itself, no needs to representing the CD, the reader or the user:
> no means in this world; the music is an object that can live as itself in
> this virtual-world and as such it can play itself. In the virtual-world,
> the OS should be only the layer that manages and provides transparently
> mapping betweens the real-life entities (materials) and the virtual-world
> ones. But upon it, IMHO what we call the user space should be the
> virtual-world as itself and we have to think differently than we used to
> think in our own world; we have to concentrate ourself to the 'what'
> question than to the 'how' one.
0
jhallman
6/30/2006 2:42:17 PM
Jeffrey J. Hallman wrote:

> Miguel,
> 
> This may sound insulting, but it isn't meant to be.  It looks to me like
> you're trying to convince yourself not to learn Smalltalk.  
No, it isn't what I mean. My post isn't about learning or not Smalltalk, it
is about the model "Just like you need a farmer to milk a cow; a cow can't
milk itself, and milk cannot un-cow itself." In fact, I don't really agree
with that approach that, IHMO, is more focused on the "how" question than
the "what" one by taking as example an aspect of our real-life. IHMO, the
virtual-world isn't our world and we need to think differently when we
model a solution to a problem whatever the tool we use for doing, Smalltalk
or not.

Miguel
0
Miguel
6/30/2006 3:56:39 PM
If that is your mindset going into it I wouldn't recommend Smalltalk as
a pursuit IMHO. As a pure OO language Smalltalk was a pioneer in
bringing the problem domain into real world terms. Taking an abstract
task and qualifying it in terms of representative objects sending
messages back and forth to one another to complete the task. If you go
into this abstract task thinking that this isn't viable then using
Smalltalk your code will appear to be at best convoluted and be hard to
maintain. At worst it wouldn't work at all and you would give up in
frustration. Perhaps I am wrong on this, but that' my $0.02...

Miguel Moquillon wrote:
> Jeffrey J. Hallman wrote:
>
> > Miguel,
> >
> > This may sound insulting, but it isn't meant to be.  It looks to me like
> > you're trying to convince yourself not to learn Smalltalk.
> No, it isn't what I mean. My post isn't about learning or not Smalltalk, it
> is about the model "Just like you need a farmer to milk a cow; a cow can't
> milk itself, and milk cannot un-cow itself." In fact, I don't really agree
> with that approach that, IHMO, is more focused on the "how" question than
> the "what" one by taking as example an aspect of our real-life. IHMO, the
> virtual-world isn't our world and we need to think differently when we
> model a solution to a problem whatever the tool we use for doing, Smalltalk
> or not.
> 
> Miguel

0
gregarican
6/30/2006 4:02:44 PM
Miguel,
The point was not to model the real world, but to show how things like 
actions and concepts can themselves be modelled as objects.  Be it a farmer, 
a bank transfer, a state, a complex behaviour, etc.

For example, in our app we model 'state change' as instances of a domain 
transaction class.  This allows us to see the history of changes, and, more 
importantly, to undo them.  By linking all the related transaction instances 
of a business 'unit of work', we can undo very complex actions.

State change in most applications (and in real life) is ephemeral.  It's not 
something that would normally be modelled.  In our case, it proved very 
useful.

Another example: we implanted async method execution by storing message 
sends in a semaphore controlled queue.  Having the messages as real objects 
made this possible (think of how different that is from a function call).

It's when you start seeing the possibility of objects in new and interesting 
ways that you know you've arrived.

Bob Nemec
STIC

"Miguel Moquillon" <miguel@home.fr> wrote in message 
news:44a5228e$0$20720$636a55ce@news.free.fr...
> Bob Nemec wrote:
>> Just like you need a farmer to milk a cow; a cow can't milk itself,
>> and milk cannot un-cow itself.
> Yes, if you model the real-life, but the virtual-world (computer science
> one) isn't the real life, just an artifact of some real-life aspects.
> Indeed, take as example the audio CD reader: a user put the CD in the 
> reader
> in order to listen musics. According to your mind, we have to model the 
> CD,
> the reader and, why not, the user that put the CD within it.
> But in fact, this is mandatory in our world for listening musics in a
> desktop for example: the music is encoded into audio tracks that are
> carried in a CD and we require material in order to listen them. In the
> virtual-world, we don't require them. The only think that we want is to
> listen musics and to handle it, and the virtual-world can provide you
> theses facilities without inserting intermediary entities. The music is
> modeled as itself, no needs to representing the CD, the reader or the 
> user:
> no means in this world; the music is an object that can live as itself in
> this virtual-world and as such it can play itself. In the virtual-world,
> the OS should be only the layer that manages and provides transparently
> mapping betweens the real-life entities (materials) and the virtual-world
> ones. But upon it, IMHO what we call the user space should be the
> virtual-world as itself and we have to think differently than we used to
> think in our own world; we have to concentrate ourself to the 'what'
> question than to the 'how' one. 


0
Bob
6/30/2006 5:01:24 PM
|  speaking from my own experience, I'd encourage you to learn a broad spectrum 
|  of computer languages.  Each one will show you a slightly different 
|  perspective.  And include things like Prolog and Snobol.

  I agree. I have seen a lot of languages, some I just had a cursory
encounter with during study (like ML, Prolog, miranda), others I solved
some more or less interesting problems with (C, C++, perl) and some I
liked for no apparent reason (Lisp, APL, Smalltalk).

  Each has taught me something different, be it either something good
or something I hated -- but it made my horizon of "a language can actually
do THAT? in only one line?" wider.

  What I personally like about Smalltalk is the minimalism and strict
OO architecture. I find that very elegant and sexy.

|  I believe that over time, the elegance of Smalltalk of will become self 
|  evident.

  Didn't I just say that? Ah right :-)

  Regards,

	mjl

0
Martin
6/30/2006 8:56:25 PM
On 29-Jun-2006, casioculture@gmail.com wrote:

> 3. Smalltalk, Squeak in particular, focuses too much on GUI. I look at
> its future direction, such as croquet, and I'm a little perturbed. 3D?
> Why? As if 2D GUIs weren't too much of a distraction. I got into
> programming this time after becoming fed up with GUIs. It started with
> awk for doing csv simple databases and then tetex for documents. That
> was a revelation. I could use plaintext and not worry about formats,
> tools or platforms. I also found that I like bash and grep. As a result
> I haven't used Office software for a long time and when I install a
> linux distro first thing I do is delete openoffice. I much prefer to do
> things now with the CLI and a simple text editor. With Squeak its GUIs
> all again. Type in a litle on the keyboard, reach for the mouse, click
> for context menu, then click print it or do it, mouse again... argh.
> That's why I'm not quite fond of Squeak. I think GUIs are bad in the
> long term and text-cli is simpler. It also introduces much unneeded
> complexities. I could perhaps use GNU smalltalk, but the arguments of 1
> and 2 still apply to it, and it doesn't seem well documented enough for
> a newbie to learn it.

From my perspective you've mixed two things together here: IDEs and
development of GUI applications. One of the premier uses of Squeak for
several years was the exploration of new user interface paradigms and
approaches. Thus, it's "to many people" wierdness. That doesn't stop you
from building headless applications, but can certainly put off a newcomer.
None of the applications I've worked on in Smalltalk in the last 10 years
have significant GUI compionents. They primarily manipulate databases and
files, and communicate with the rest of the world using IP or messaging,
or web services, or CORBA, or .... So Smalltalk is certainly, from my
perspective, not focussed on GUI applications.

As to IDEs, on the other hand: I like keyboard shortcuts a lot. I use them
in my Smalltalk work more than most of my colleagues. I also wish the
Smalltalk IDEs made it easier for me to use keyboard shortcuts rather than
the mouse for commonly used browsing actions. BUT!, I would never give up
my IDE for a text editor, even SlickEdit which I used to like very much.

> 4. Lisp and forth have excellent books and documentation, ranging from
> newbie to very advanced. Lisp for example has the MIT and UCB
> literature, and forth has the Brodie's books. And those books teach me
> not only their languages, but programming and computer science in
> general. The problem with smalltalk, though many free books are
> available, they seem to have too much of a narrow range of concern, and
> that is, 1) OOP 2) GUI, lots and lots of GUI emphasis 3) a particular
> commercial smalltalk.

One of the best books for you might be Chamond Liu's "Smalltalk Objects
and Design". It does not focus on building GUI applicaitons. It focusses
on using Smalltalk to design for and solve real world type problems.

Doug Swartz
0
Doug
7/1/2006 3:02:38 PM
Reply: