Smalltalk › Squeak › Squeak - Beginners

Squeak vs. Smalltalk

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Avidan Ackerson-2

Squeak vs. Smalltalk

I know that Squeak is written in Smalltalk, but are there specific
advantages to Squeak over Smalltalk proper?
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

David Mitchell-10

Re: Squeak vs. Smalltalk

What makes Squeak special is the Squeak community. Fantastic history
and tradition. Inspiring thinkers. Colorful ideas.

For someone used to commercial Smalltalk development, Squeak is a bit
of a siren song. I've certainly felt that way. Much of Squeak's GUI
wasn't built to satisfy commercial developers, but to get some wild,
crazy, next generation media playground for kids and adults to
experiment with. Very trippy but sometimes frustrating to someone who
just wants to build a CRUD GUI.

If you want to build for the web, Squeak is a nice home for Seaside
development. I'm currently using Pharo, which is still Squeak to me,
but it may diverge in the near future.

Now to get a little pedantic:

Squeak is a Smalltalk. It is written in Squeak Smalltalk*.

Visual Works is a Smalltalk. Most of it is also written in Visual
Works Smalltalk.

All Smalltalks have little variations. There is no downloadable,
runnable thing called Smalltalk proper. You might call Smalltalk-80
Smalltalk proper. Squeak and VisualWorks both descend** from
Smalltalk-80**. You might also call ANSI Smalltalk proper, but there
is no implementation of Smalltalk that is only ANSI Smalltalk.

If you want to write code that you can take from one Smalltalk into
another, you're in for a bit of a bumpy ride. The Seaside team
probably has the most broad and most current experience here. Looking
at the work they are doing for 2.9 (as well as their coding standards)
are a good things to emulate.

Squeak and GNU Smalltalk are both open-source. GNU is GPL, natch.
Squeak predates the OSI definition of that term and so has a more
colorful license history, but it will (soon) be MIT with bits of APSL.

VisualWorks and GemStone are not open-source, but each provides
professional commercial support and licenses that make it easy to
start exploring and developing. VW is probably the most mainstream,
commercial tool. GemStone is the leader for big Object-Oriented DBs.

Instantiations still supports VisualAge Smalltalk (formerly IBM
Smalltalk). Also good commercial support.

Lots of other Smalltalks I'm leaving out.

Between Squeak and GNU, Squeak is the more traditional, image-based
Smalltalk. GNU keeps its code in files, which makes sense to most
non-Smalltalkers. But, as MarkusQ wrote recently:

"Trying to get your head around smalltalk without using the IDE is
like going to Paris and eating at McDonalds. Sure, you're in Paris,
but you aren't really exposing yourself to what it's all about."

Footnotes:

* There are a few parts of the Virtual Machine that are written in C,
but even those are actually written in a pidgin (reduced) Squeak
Smalltalk called Slang. It really is a C subset with Squeak Smalltalk
style. The benefit of this is you can simulate the VM using Smalltalk
tools as you develop.

**and lore has it they may actually both still be running some of the
same bits as an ancient Smalltalk image.

On Mon, Apr 20, 2009 at 9:44 PM, Avidan Ackerson
<[hidden email]> wrote:
> I know that Squeak is written in Smalltalk, but are there specific
> advantages to Squeak over Smalltalk proper?
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Steve Lloyd-3

RE: Squeak vs. Smalltalk

In reply to this post by Avidan Ackerson-2

David's summary put the relationship between Squeak and Smalltalk very well

"Squeak is an implementation of Smalltalk"

... but a Smalltalk with a unique cultural background, a helpful community and some features which mean that as your experience and interests evolve you can delve into the system at many levels. For example Squeak is uniquely able to help you in exploring the workings of the virtual machine which supports the rest of the system. Its also the most widely deployed Smalltalk system (thanks to One Laptop Per Child & Etoys).

Because of the way in which Squeak has grown organically, there are inevitably some areas which don't match everyone's tastes, hence projects like Pharo which pares down Squeak to suit developers. (But I'm sure even the most hard-bitten of developers can benefit from an occasional rummage in the more exotic appendages of Squeak). Interestingly the Squeak Board seem to be tentatively aiming for future development of a 'modular' Squeak, in which the various interest groups can load features on top of a clean stable core. ( listen to the interview at http://www.cincomsmalltalk.com/audio/2009/industry_misinterpretations131.mp3 ).

The commercial Smalltalks have their own areas of excellence (aside from support), but the great thing is that each group embraces the notion that cooperation and cross-sharing can only benefit the community as a whole. The porting of Seaside to the various dialects is a good example of this.

If you'd like to explore the fascinating history of Smalltalk and Squeak one thing you should do is listen to the interview with Dan Ingalls at http://www.twit.tv/floss29 and there is Alan Kay's "The early history of Smalltalk" http://www.iam.unibe.ch/~ducasse/FreeBooks/SmalltalkHistoryHOPL.pdf

International Baccalaureate Steve Lloyd ICT Technical Analyst - Research Engineer
Peterson House, Malthouse Ave. Cardiff Gate, CARDIFF CF23 8GL, United Kingdom
Tel: +44 (0)2920 547869 | Fax: +44 (0)2920 547779 | Web: http://www.ibo.org
________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Avidan Ackerson [[hidden email]]
Sent: 21 April 2009 03:44
To: [hidden email]
Subject: [Newbies] Squeak vs. Smalltalk

I know that Squeak is written in Smalltalk, but are there specific
advantages to Squeak over Smalltalk proper?
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Mark Volkmann

Re: Squeak vs. Smalltalk

In reply to this post by David Mitchell-10

On Apr 20, 2009, at 10:28 PM, David Mitchell wrote:

> Very trippy but sometimes frustrating to someone who
> just wants to build a CRUD GUI.

This was a key factor in me setting Squeak aside for a bit. I love the
syntax of Smalltalk and the tools, but I was amazed at how difficult
it was to build and deploy a simple GUI application. For example, I
just wanted to build a GUI with a text field for entering a name and
an OK button. When the button is pressed I wanted to display a dialog
box that contains the text "Hello" and the name. The most frustrating
parts were the layout of widgets and the packages of the application
which involves a large number of steps.

A more recent concern for me is the lack of support for taking
advantage of multi-core processors. I know someone is working on
improving this.

I hope to return to using Smalltalk at some point.

---
Mark Volkmann
http://www.ociweb.com/mark

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

smime.p7s (7K) Download Attachment

Mark Volkmann

Re: Squeak vs. Smalltalk

On Apr 21, 2009, at 7:01 AM, Mark Volkmann wrote:

> On Apr 20, 2009, at 10:28 PM, David Mitchell wrote:
>
>> Very trippy but sometimes frustrating to someone who
>> just wants to build a CRUD GUI.
>
>
> This was a key factor in me setting Squeak aside for a bit. I love
> the syntax of Smalltalk and the tools, but I was amazed at how
> difficult it was to build and deploy a simple GUI application. For
> example, I just wanted to build a GUI with a text field for entering
> a name and an OK button. When the button is pressed I wanted to
> display a dialog box that contains the text "Hello" and the name.
> The most frustrating parts were the layout of widgets and the packages

I meant "packaging".

> of the application which involves a large number of steps.
>
> A more recent concern for me is the lack of support for taking
> advantage of multi-core processors. I know someone is working on
> improving this.
>
> I hope to return to using Smalltalk at some point.

---
Mark Volkmann
http://www.ociweb.com/mark

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

smime.p7s (7K) Download Attachment

Michael van der Gulik-2

Re: Squeak vs. Smalltalk

In reply to this post by Mark Volkmann

On 4/22/09, Mark Volkmann <[hidden email]> wrote:

> On Apr 20, 2009, at 10:28 PM, David Mitchell wrote:
>
>> Very trippy but sometimes frustrating to someone who
>> just wants to build a CRUD GUI.
>
>
> This was a key factor in me setting Squeak aside for a bit. I love the
> syntax of Smalltalk and the tools, but I was amazed at how difficult
> it was to build and deploy a simple GUI application. For example, I
> just wanted to build a GUI with a text field for entering a name and
> an OK button. When the button is pressed I wanted to display a dialog
> box that contains the text "Hello" and the name. The most frustrating
> parts were the layout of widgets and the packages of the application
> which involves a large number of steps.

+1. It's on my TODO list.

> A more recent concern for me is the lack of support for taking
> advantage of multi-core processors. I know someone is working on
> improving this.

Unfortunately the situation here is rather dire. I blogged about it:
http://securesqueak.blogspot.com/2009/03/concurrency.html.

It's fully possible to make a Smalltalk VM that does fine-grained
concurrency, but nobody concurrently has the time(/money), energy and
raw creative intelligence to make one. Until then, Igor's Hydra VM is
the best we have. I'd love to make one, but I haven't put it on my
TODO list because I don't need a concurrent VM. My single cored 1Ghz
Celeron CPU is plenty fast enough.

I'm fascinated by concurrent computing, and I've dabbled in it a bit
as a hobby, but most of what I do isn't CPU bound. There's a lot of
very interesting stuff you can do before you're limited by your CPU
speed.

Gulik.

--
http://gulik.pbwiki.com/
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Mark Volkmann

Re: Squeak vs. Smalltalk

On Apr 21, 2009, at 4:52 PM, Michael van der Gulik wrote:

> On 4/22/09, Mark Volkmann <[hidden email]> wrote:
>> On Apr 20, 2009, at 10:28 PM, David Mitchell wrote:
>>
>>> Very trippy but sometimes frustrating to someone who
>>> just wants to build a CRUD GUI.
>>
>>
>> This was a key factor in me setting Squeak aside for a bit. I love
>> the
>> syntax of Smalltalk and the tools, but I was amazed at how difficult
>> it was to build and deploy a simple GUI application. For example, I
>> just wanted to build a GUI with a text field for entering a name and
>> an OK button. When the button is pressed I wanted to display a dialog
>> box that contains the text "Hello" and the name. The most frustrating
>> parts were the layout of widgets and the packages of the application
>> which involves a large number of steps.
>
> +1. It's on my TODO list.

Excellent!

>> A more recent concern for me is the lack of support for taking
>> advantage of multi-core processors. I know someone is working on
>> improving this.
>
> Unfortunately the situation here is rather dire. I blogged about it:
> http://securesqueak.blogspot.com/2009/03/concurrency.html.
>
> It's fully possible to make a Smalltalk VM that does fine-grained
> concurrency, but nobody concurrently has the time(/money), energy and
> raw creative intelligence to make one. Until then, Igor's Hydra VM is
> the best we have. I'd love to make one, but I haven't put it on my
> TODO list because I don't need a concurrent VM. My single cored 1Ghz
> Celeron CPU is plenty fast enough.
>
> I'm fascinated by concurrent computing, and I've dabbled in it a bit
> as a hobby, but most of what I do isn't CPU bound. There's a lot of
> very interesting stuff you can do before you're limited by your CPU
> speed.

To be honest, it's not so much that I have applications in mind that
require use of multiple CPUs as it is fear for the future. While one
core may seem fast enough today, what will we think when machines
commonly have 16 or more? The thought that I may really be asked to
write software that takes advantage of multiple cores has prompted me
to start dabbling in functional languages. At the moment my functional
language of choice is Clojure. That said, I'd rather work in Smalltalk
if it could do that too.

---
Mark Volkmann
http://www.ociweb.com/mark

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

smime.p7s (7K) Download Attachment

Avidan Ackerson-2

Re: Squeak vs. Smalltalk

In reply to this post by David Mitchell-10

Thank you for all your answers, as it has given me a good idea about the
nature of Squeak. But what can you tell me as far as performance ability
goes? I recall reading somewhere that Squeak can cause a drag in
processing at times.

David Mitchell wrote:

> What makes Squeak special is the Squeak community. Fantastic history
> and tradition. Inspiring thinkers. Colorful ideas.
>
> For someone used to commercial Smalltalk development, Squeak is a bit
> of a siren song. I've certainly felt that way. Much of Squeak's GUI
> wasn't built to satisfy commercial developers, but to get some wild,
> crazy, next generation media playground for kids and adults to
> experiment with. Very trippy but sometimes frustrating to someone who
> just wants to build a CRUD GUI.
>
> If you want to build for the web, Squeak is a nice home for Seaside
> development. I'm currently using Pharo, which is still Squeak to me,
> but it may diverge in the near future.
>
> Now to get a little pedantic:
>
> Squeak is a Smalltalk. It is written in Squeak Smalltalk*.
>
> Visual Works is a Smalltalk. Most of it is also written in Visual
> Works Smalltalk.
>
> All Smalltalks have little variations. There is no downloadable,
> runnable thing called Smalltalk proper. You might call Smalltalk-80
> Smalltalk proper. Squeak and VisualWorks both descend** from
> Smalltalk-80**. You might also call ANSI Smalltalk proper, but there
> is no implementation of Smalltalk that is only ANSI Smalltalk.
>
> If you want to write code that you can take from one Smalltalk into
> another, you're in for a bit of a bumpy ride. The Seaside team
> probably has the most broad and most current experience here. Looking
> at the work they are doing for 2.9 (as well as their coding standards)
> are a good things to emulate.
>
> Squeak and GNU Smalltalk are both open-source. GNU is GPL, natch.
> Squeak predates the OSI definition of that term and so has a more
> colorful license history, but it will (soon) be MIT with bits of APSL.
>
> VisualWorks and GemStone are not open-source, but each provides
> professional commercial support and licenses that make it easy to
> start exploring and developing. VW is probably the most mainstream,
> commercial tool. GemStone is the leader for big Object-Oriented DBs.
>
> Instantiations still supports VisualAge Smalltalk (formerly IBM
> Smalltalk). Also good commercial support.
>
> Lots of other Smalltalks I'm leaving out.
>
> Between Squeak and GNU, Squeak is the more traditional, image-based
> Smalltalk. GNU keeps its code in files, which makes sense to most
> non-Smalltalkers. But, as MarkusQ wrote recently:
>
> "Trying to get your head around smalltalk without using the IDE is
> like going to Paris and eating at McDonalds. Sure, you're in Paris,
> but you aren't really exposing yourself to what it's all about."
>
> Footnotes:
>
> * There are a few parts of the Virtual Machine that are written in C,
> but even those are actually written in a pidgin (reduced) Squeak
> Smalltalk called Slang. It really is a C subset with Squeak Smalltalk
> style. The benefit of this is you can simulate the VM using Smalltalk
> tools as you develop.
>
> **and lore has it they may actually both still be running some of the
> same bits as an ancient Smalltalk image.
>
>
> On Mon, Apr 20, 2009 at 9:44 PM, Avidan Ackerson
> <[hidden email]> wrote:
>
>> I know that Squeak is written in Smalltalk, but are there specific
>> advantages to Squeak over Smalltalk proper?
>> _______________________________________________
>> Beginners mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>>
>>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Michael van der Gulik-2

Re: Squeak vs. Smalltalk

On 4/22/09, Avidan Ackerson <[hidden email]> wrote:
> Thank you for all your answers, as it has given me a good idea about the
> nature of Squeak. But what can you tell me as far as performance ability
> goes? I recall reading somewhere that Squeak can cause a drag in
> processing at times.

The Squeak VM itself is fast, for a particular value of fast. The
reason it feels slow is because the user interface has been becoming
bloated. I haven't tried it myself, but people report that the Cuis
image is much faster than the standard Squeak image (Google or read
other emails on this email list for links). Older images such as
Squeak 1.3 (from ye olde archives) are very reactive, but feel "old".

As far as interpreted VMs go, I believe that the Squeak VM is among
the faster ones. Somebody should correct me if I'm wrong, but I
/believe/ that the Squeak VM is faster than the standard Python VM,
Perl and Ruby. Things might have changed since I last looked.

However, Squeak is (I believe) slower than Forth interpreters and
slower than compiled code from C++ and C. It will also be slower than
just-in-time compilers/interpreters such as the Sun Java VM.

Eliot Miranda has joined our ranks recently and is working on the Cog
VM. This will make Squeak even faster. Bryce Kampjes is also working
on Exupery, which is another approach to speeding up code.

A stock Squeak VM can't use multiple CPU cores, although the Smalltalk
language itself has support for this. A single-cored CPU will run
Squeak at the same speed as a dual or quad-core machine.

Gulik.

--
http://gulik.pbwiki.com/
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners