Smalltalk › Squeak › Squeak - Dev

[squeak-dev] what is holding back Smalltalk?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

85 messages Options

12345

Mark Volkmann

[squeak-dev] what is holding back Smalltalk?

I don't have a lot of experience with Smalltalk yet, but I really love
what I've seen so far.

I'm curious what experienced Smalltalkers see as some of the reasons
why it doesn't attract more attention. I understand the issues with
Smalltalk in the past related to license costs and performance, but
those have been addressed now. Have you tried to convince someone to
consider Smalltalk and failed to convince them? Why do you think they
rejected it? What improvements could be made to current Smalltalk
environments, especially Squeak, that might sway them?

For me the biggest issue has been trying to run my code from outside
Squeak. This includes running Squeak headless to do something script-
like and configuring a GUI application to run in a way that doesn't
require the user to know they are running Squeak. Both of these are
supposedly possible, but very difficult to get right.

---
Mark Volkmann

Michael van der Gulik-2

Re: [squeak-dev] what is holding back Smalltalk?

On Fri, Nov 21, 2008 at 12:02 PM, Mark Volkmann <[hidden email]> wrote:

I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.

I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention. I understand the issues with Smalltalk in the past related to license costs and performance, but those have been addressed now. Have you tried to convince someone to consider Smalltalk and failed to convince them? Why do you think they rejected it? What improvements could be made to current Smalltalk environments, especially Squeak, that might sway them?

I'd like to ask how Ruby on Rails got so popular, and what makes it different from Squeak?

Gulik.

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

David Mitchell-10

Re: [squeak-dev] what is holding back Smalltalk?

In reply to this post by Mark Volkmann

Most of the things that make Smalltalk great (what makes Smalltalk
Smalltalk) are the things that hold it back for a lot of people.

If you want a more Unixy, scripty, Smalltalkish thing with syntax
blended C and Perl that you can hack with a text editor, try Ruby.

If you want objects all the time with a crazy amount of integration in
the tools and little attempt at conforming to outside ideas, Smalltalk
is your game.

On Thu, Nov 20, 2008 at 5:02 PM, Mark Volkmann <[hidden email]> wrote:

> I don't have a lot of experience with Smalltalk yet, but I really love what
> I've seen so far.
>
> I'm curious what experienced Smalltalkers see as some of the reasons why it
> doesn't attract more attention. I understand the issues with Smalltalk in
> the past related to license costs and performance, but those have been
> addressed now. Have you tried to convince someone to consider Smalltalk and
> failed to convince them? Why do you think they rejected it? What
> improvements could be made to current Smalltalk environments, especially
> Squeak, that might sway them?
>
> For me the biggest issue has been trying to run my code from outside Squeak.
> This includes running Squeak headless to do something script-like and
> configuring a GUI application to run in a way that doesn't require the user
> to know they are running Squeak. Both of these are supposedly possible, but
> very difficult to get right.
>
> ---
> Mark Volkmann
>
>
>
>
>
>

David Mitchell-10

Re: [squeak-dev] what is holding back Smalltalk?

In reply to this post by Michael van der Gulik-2

Rails is a web framework. Did you mean Seaside?

On Thu, Nov 20, 2008 at 5:24 PM, Michael van der Gulik
<[hidden email]> wrote:

>
>
> On Fri, Nov 21, 2008 at 12:02 PM, Mark Volkmann <[hidden email]> wrote:
>>
>> I don't have a lot of experience with Smalltalk yet, but I really love
>> what I've seen so far.
>>
>> I'm curious what experienced Smalltalkers see as some of the reasons why
>> it doesn't attract more attention. I understand the issues with Smalltalk in
>> the past related to license costs and performance, but those have been
>> addressed now. Have you tried to convince someone to consider Smalltalk and
>> failed to convince them? Why do you think they rejected it? What
>> improvements could be made to current Smalltalk environments, especially
>> Squeak, that might sway them?
>
> I'd like to ask how Ruby on Rails got so popular, and what makes it
> different from Squeak?
>
> Gulik.
>
> --
> http://people.squeakfoundation.org/person/mikevdg
> http://gulik.pbwiki.com/
>
>
>
>

Mark Volkmann

Re: [squeak-dev] what is holding back Smalltalk?

In reply to this post by David Mitchell-10

On Nov 20, 2008, at 5:28 PM, David Mitchell wrote:

> Most of the things that make Smalltalk great (what makes Smalltalk
> Smalltalk) are the things that hold it back for a lot of people.

Maybe I'm naive on this, but it seems like it should be easy convince
lots of people that Smalltalk has a beautiful syntax and a wonderful
development environment.

> If you want a more Unixy, scripty, Smalltalkish thing with syntax
> blended C and Perl that you can hack with a text editor, try Ruby.

I think this depends on how we define "scripty". I take that to mean
quick, short, one off programs. I personally use Ruby for that today.
However, I'd like to be able to use Squeak when things get a little
bigger. For example, suppose I want to run an application every night
that queries a database, produces some text report and emails it to
several people. I don't see any reason why those kinds of applications
should be difficult to write and deploy using Squeak, but they seem
pretty difficult to me today because I can't get the headless stuff to
work.

> If you want objects all the time with a crazy amount of integration in
> the tools and little attempt at conforming to outside ideas, Smalltalk
> is your game.
>
> On Thu, Nov 20, 2008 at 5:02 PM, Mark Volkmann <[hidden email]>
> wrote:
>> I don't have a lot of experience with Smalltalk yet, but I really
>> love what
>> I've seen so far.
>>
>> I'm curious what experienced Smalltalkers see as some of the
>> reasons why it
>> doesn't attract more attention. I understand the issues with
>> Smalltalk in
>> the past related to license costs and performance, but those have
>> been
>> addressed now. Have you tried to convince someone to consider
>> Smalltalk and
>> failed to convince them? Why do you think they rejected it? What
>> improvements could be made to current Smalltalk environments,
>> especially
>> Squeak, that might sway them?
>>
>> For me the biggest issue has been trying to run my code from
>> outside Squeak.
>> This includes running Squeak headless to do something script-like and
>> configuring a GUI application to run in a way that doesn't require
>> the user
>> to know they are running Squeak. Both of these are supposedly
>> possible, but
>> very difficult to get right.
>>
>> ---
>> Mark Volkmann
>>
>>
>>
>>
>>
>>
>

---
Mark Volkmann

CdAB63

Re: [squeak-dev] what is holding back Smalltalk?

In reply to this post by David Mitchell-10

David Mitchell escreveu:

Most of the things that make Smalltalk great (what makes Smalltalk
Smalltalk) are the things that hold it back for a lot of people.

If you want a more Unixy, scripty, Smalltalkish thing with syntax
blended C and Perl that you can hack with a text editor, try Ruby.

If you want objects all the time with a crazy amount of integration in
the tools and little attempt at conforming to outside ideas, Smalltalk
is your game.

Some things that hold back smalltalk:

It was not supported by a media boosted corporation the way Java was in the 90ties. Today everybody knows that Java sucks. Everybody knows that with current technology (JVM) it is not possible to build large intensive Java applications (just study how the garbage collection works... what happens when you have to handle large data...). But Java got a good marketing while smalltalk and Self and other really interesting things were related as "geek things".
Smalltalk community was not able to create a really functional organization capable of delivering important things as standards and documentation.
Not taking into account the commercial versions of smalltalk that are supposed to satisfy small closed markets, the open versions like squeak never succeeded in releasing and maintaining "distributions" (like Linux) where all bundled parts are more or less assured to work properly with each other.

Much of the heat recently generated around smalltalk results from people perceptions about the dead-ends imposed by other programming models (like Java). With a little lucky it will attract investment and supporting infrastructure (money to pay for people doing the hard works of documenting things, establishing certain standards, testing & debugging, etc).

signature.asc (267 bytes) Download Attachment

Jon Hylands

Re: [squeak-dev] what is holding back Smalltalk?

In reply to this post by Mark Volkmann

On Thu, 20 Nov 2008 17:36:06 -0600, Mark Volkmann <[hidden email]> wrote:

> I don't see any reason why those kinds of applications
> should be difficult to write and deploy using Squeak, but they seem
> pretty difficult to me today because I can't get the headless stuff to
> work.

What problems are you having? I run Squeak headless all the time on my
robots...

Later,
Jon

--------------------------------------------------------------
Jon Hylands [hidden email] http://www.huv.com/jon

Project: Micro Raptor (Small Biped Velociraptor Robot)
http://www.huv.com/blog

Nicolas Petton

Re: [squeak-dev] what is holding back Smalltalk?

In reply to this post by David Mitchell-10

Le jeudi 20 novembre 2008 à 17:28 -0600, David Mitchell a écrit :
> Most of the things that make Smalltalk great (what makes Smalltalk
> Smalltalk) are the things that hold it back for a lot of people.
>
> If you want a more Unixy, scripty, Smalltalkish thing with syntax
> blended C and Perl that you can hack with a text editor, try Ruby.

You may also want to try GNU Smalltalk (http://smalltalk.gnu.org).
I just started using it for my scripting tasks, and so far I think it a
lot better than Python or Ruby.

Nicolas

signature.asc (204 bytes) Download Attachment

Igor Stasenko

Re: [squeak-dev] what is holding back Smalltalk?

In reply to this post by CdAB63

I think that one of the major drawbacks of smalltalk is its 80's
implementation which offers 0 (zero) modularity.
A smalltalk image is a universe, which contains everything. It can't
be split on parts, you can't manage these parts to load/unload on
demand. Everything is tightly welded together and sometimes, even if
you want to get rid of some stuff - its very hard to do. Its like a
painting ink - once you stepped into it once - you start leaving
footprints everywhere.
Its very good from one side, but not always: for a people working in
contaminated areas, they need to pass a clean-up procedures to reduce
the risk of bringing unwanted stuff into that environment.
In smalltalk there is no such contaminated areas - you free to go
everywhere and leave your footprints. Who cares? :)
This is the problem: if people don't have a discipline and leaving
stuff everywhere they think it good to be, then at the end we got a
complete mess, no structure, no organization, just a half-working
pieces spreaded across many places.

Also, even if organized well, projects can't grow bigger than certain
amount, and at some point they become unmanageable, simply because no
single man can hold so much information in his head to understand it
and make some progress with it.
At some point, you have to split your project on separate parts and
delegate your work to other people. And also, make sure that these
parts can evolve more or less independently.
This is where fun begins: a smalltalk inherent implementation lacks
modularity and offers nothing to you how to break things apart without
losing consistency.
Instead, it makes you addict in using globals everywhere and be
careless about future :)

Another analogue: kids playing with lego puzzle. One kid puts one
piece on top of another, then second puts some more pieces on top of
it, and so on, then another kid came and realizes that if he replace
the piece inside a construction it would be much more elegant. But at
first attempt when he tries that, he breaks the whole construction :)

I hoping this will change in near future. Smalltalk syntax is the
simplest and most powerful syntax i met.

--
Best regards,
Igor Stasenko AKA sig.

Randal L. Schwartz

Re: [squeak-dev] what is holding back Smalltalk?

In reply to this post by Nicolas Petton

>>>>> "nico" == nico <[hidden email]> writes:

nico> You may also want to try GNU Smalltalk (http://smalltalk.gnu.org).
nico> I just started using it for my scripting tasks, and so far I think it a
nico> lot better than Python or Ruby.

But beware of looking at any of its source code if you ever think you
might be contibuting to the Squeak core. See my discussion at
http://methodsandmessages.vox.com/library/post/beware-gnu-smalltalk-if-you-work-on-squeak.html

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Rob Rothwell

Re: [squeak-dev] what is holding back Smalltalk?

In reply to this post by Mark Volkmann

I'm pretty "new" in my abilities, but I have found a TERRIFIC product written in VisualWorks thanks to networking with all you Smalltalk-y people. We are working to develop a data collection and reporting tool in a healthcare environment using this system that already existed and was designed specifically to be able to bring together "fragments" of information from multiple sources of data through conflict resolution rules, etc... into a single "Object Model" (set of classes).

Anyway...what I am doing is another topic--but it IS the back story for the following tale.

Because we are "developing" something together, and it is "Smalltalk" (even though it's not, but because I found it by EXPLORING Smalltalk, it's "branded"), one of our Board Members (a former programmer) is extremely leery.

In his words, he is "extremely prejudiced" against Smalltalk, even though he used it during a big project "back in the day." He calls it a "quirky, unusual" language that you can do "great and powerful things" with. The "Father of real object oriented programming," but only a "niche" language that small groups of bright people use to go of and accomplish amazing things with. But, because the business is full of "ordinary" people, he thinks you would never be able to find anyone to work with the code you have written as a business when your Smalltalk developers leave for other pursuits.

Hence, he suggests that I look to other development environments such as Java Beans or Eclipse!

All this, and we won't even be "programming," but using a "meta-programming" environment designed SPECIFICALLY to solve the KIND of problem we have (how lucky was that?). Sure, it's got Smalltalk at it's core, and yes, you can drop down into Smalltalk when you need to, but...yeesh....

Just thought you'd like an anecdotal tale of the feelings that are out there as of a few days ago!

Rob

On Thu, Nov 20, 2008 at 6:02 PM, Mark Volkmann <[hidden email]> wrote:

I don't have a lot of experience with Smalltalk yet, but I really love what I've seen so far.

I'm curious what experienced Smalltalkers see as some of the reasons why it doesn't attract more attention. I understand the issues with Smalltalk in the past related to license costs and performance, but those have been addressed now. Have you tried to convince someone to consider Smalltalk and failed to convince them? Why do you think they rejected it? What improvements could be made to current Smalltalk environments, especially Squeak, that might sway them?

For me the biggest issue has been trying to run my code from outside Squeak. This includes running Squeak headless to do something script-like and configuring a GUI application to run in a way that doesn't require the user to know they are running Squeak. Both of these are supposedly possible, but very difficult to get right.

---
Mark Volkmann

Blake-5

Re: [squeak-dev] what is holding back Smalltalk?

In reply to this post by Mark Volkmann

Let me just say that "scripty" doesn't have to be antithetical to
Smalltalk.

If I had a Smalltalk Apache module that I could plug in to handle various
requests, and still log in to as a live image? That'd be better than any
scripting language.

The modularity point is a good one along the same lines: I love the image,
I just want it not to be isolated.

As for GPL-tainted stuff, that shouldn't affect someone who's just =using=
the product, right? (I'm not but I've been thinking about it.) Unless one
digs into the source code, one should be fine, yes?

Alan Grimes-2

Re: [squeak-dev] what is holding back Smalltalk?

In reply to this post by Mark Volkmann

> For me the biggest issue has been trying to run my code from outside
> Squeak. This includes running Squeak headless to do something
> script-like and configuring a GUI application to run in a way that
> doesn't require the user to know they are running Squeak. Both of these
> are supposedly possible, but very difficult to get right.

1. The VM, it's weak, no multithreading, few IO options.

2. The restriction to image based smalltalk instead of the ability to
run discreet programs...

Image based smalltalk is awesome but it makes it difficult to interface
smalltalk code with external systems.

--
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.

Igor Stasenko

Re: [squeak-dev] what is holding back Smalltalk?

2008/11/21 Alan Grimes <[hidden email]>:

>> For me the biggest issue has been trying to run my code from outside
>> Squeak. This includes running Squeak headless to do something
>> script-like and configuring a GUI application to run in a way that
>> doesn't require the user to know they are running Squeak. Both of these
>> are supposedly possible, but very difficult to get right.
>
> 1. The VM, it's weak, no multithreading, few IO options.
>
> 2. The restriction to image based smalltalk instead of the ability to
> run discreet programs...
>
> Image based smalltalk is awesome but it makes it difficult to interface
> smalltalk code with external systems.

i think, community would be able to overcome both problems, if there
was an option to build VM as shared (or static) library
to include it in own project.
Then image plays role as external module, which you can load and play
with, and then drop it once you don't need it anymore and load another
one.
As well, as having a reentrant interpreter would allow to interoperate with it.

>
> --
> New president: Here we go again...
> Chemistry.com: A total rip-off.
> Powers are not rights.
>

--
Best regards,
Igor Stasenko AKA sig.

keith1y

Re: [squeak-dev] what is holding back Smalltalk?

In reply to this post by Rob Rothwell

> In his words, he is "extremely prejudiced" against Smalltalk, even
> though he used it during a big project "back in the day." He calls it
> a "quirky, unusual" language that you can do "great and powerful
> things" with. The "Father of real object oriented programming," but
> only a "niche" language that small groups of bright people use to go
> of and accomplish amazing things with. But, because the business is
> full of "ordinary" people, he thinks you would never be able to find
> anyone to work with the code you have written as a business when your
> Smalltalk developers leave for other pursuits.
I once wrote a simulator for telecoms equipment. The original demo took
2 weeks to produce in order to convince my boss.

After 3 months work, the simulator was simulating a single piece of
equipment 2 months before real equipment was available. This gave the
whole team a considerable head start. After a further 6-8 months the
simulation was doing 1000 pieces of equipment simultaneously, of 3
different varieties, while at the same time simulating up to 20 users
prodding the management system. There were 1500 unit tests ensuring that
everything was according to spec. The simulation turned out to be key to
proof of concept for our clients signing on the dotted line.

On the other side of the office, a contractor attempted to write a
similar simulator for another piece of equipment, in perl. After a year
that was scapped and a team of 4 started in Java. That was also scapped
and a top guru tried again in java, his efforts ran on 10 pcs! Finally,
last I heard another extremely expensive contractor was starting again
in C++.

I estimate (being generous) that they must have spent over a half a
million pounds on that failed project, and that doesnt include some
rather expensive bought in libraries (for which source code was not
visible). Little ol- me knocked up my Smalltalk equivalent for perhaps
5-10% of the cost. (we did buy an ST/X licence for £2000).

When I went on holiday, the only non-programmer in my team, the guy
doing automated testing was quite able to fix bugs, run unit tests and
keep things going. When I left the company the entire system was handed
over to a perl programmer, and last I heard it was still being used by 9
people daily. I must ring up and ask if it reached its 10th bithday.

So... if your boss is happy to spend 10x as much to get a poorer
result... there is not much else can be said.

cheers

Keith

Brad Fuller-4

Re: [squeak-dev] what is holding back Smalltalk?

Keith,

That's a great story. We should put that on the website!

On Thu, Nov 20, 2008 at 8:21 PM, Keith Hodges <[hidden email]> wrote:

>
>> In his words, he is "extremely prejudiced" against Smalltalk, even
>> though he used it during a big project "back in the day." He calls it
>> a "quirky, unusual" language that you can do "great and powerful
>> things" with. The "Father of real object oriented programming," but
>> only a "niche" language that small groups of bright people use to go
>> of and accomplish amazing things with. But, because the business is
>> full of "ordinary" people, he thinks you would never be able to find
>> anyone to work with the code you have written as a business when your
>> Smalltalk developers leave for other pursuits.
> I once wrote a simulator for telecoms equipment. The original demo took
> 2 weeks to produce in order to convince my boss.
>
> After 3 months work, the simulator was simulating a single piece of
> equipment 2 months before real equipment was available. This gave the
> whole team a considerable head start. After a further 6-8 months the
> simulation was doing 1000 pieces of equipment simultaneously, of 3
> different varieties, while at the same time simulating up to 20 users
> prodding the management system. There were 1500 unit tests ensuring that
> everything was according to spec. The simulation turned out to be key to
> proof of concept for our clients signing on the dotted line.
>
> On the other side of the office, a contractor attempted to write a
> similar simulator for another piece of equipment, in perl. After a year
> that was scapped and a team of 4 started in Java. That was also scapped
> and a top guru tried again in java, his efforts ran on 10 pcs! Finally,
> last I heard another extremely expensive contractor was starting again
> in C++.
>
> I estimate (being generous) that they must have spent over a half a
> million pounds on that failed project, and that doesnt include some
> rather expensive bought in libraries (for which source code was not
> visible). Little ol- me knocked up my Smalltalk equivalent for perhaps
> 5-10% of the cost. (we did buy an ST/X licence for £2000).
>
> When I went on holiday, the only non-programmer in my team, the guy
> doing automated testing was quite able to fix bugs, run unit tests and
> keep things going. When I left the company the entire system was handed
> over to a perl programmer, and last I heard it was still being used by 9
> people daily. I must ring up and ask if it reached its 10th bithday.
>
> So... if your boss is happy to spend 10x as much to get a poorer
> result... there is not much else can be said.
>
> cheers
>
> Keith
>
>

--
Brad Fuller

Klaus D. Witzel

[squeak-dev] Nothing much [was: what is holding back Smalltalk?]

In reply to this post by Mark Volkmann

On Fri, 21 Nov 2008 00:02:47 +0100, Mark Volkmann <[hidden email]> wrote:

> I don't have a lot of experience with Smalltalk yet, but I really love
> what I've seen so far.
>
> I'm curious what experienced Smalltalkers see as some of the reasons why
> it doesn't attract more attention.

Me thinks that the Smalltalk community is healthy and vibrant--it is
"just" a community form one would not expect for Ruby or Python or Perl,
etc. To get impression of my impression take a look at what *actually*
happened during the *recent* months:

- Exupery (native x86 methods) powers Huemul
- Seaside (web++ framework++) powers GLASS
- Hydra (multiple parallel .images) powers Croquet .images
- Google hires developers with deep Smalltalk experience
- two more gods to be worshipped in the VM temple ;)
- Squeak powers NewSpeak
- new book Squeak by Example (creative commons license)
- port of OpenDBX to Squeak (still not on windoze)
- port of Squeak/VM to "another" smartphone platform ;)
- DrGeo made it to the XO (OLPC)
- fresh new subcommunity Pharo
- attempt? to port Moose (world class sw analysis) to Squeak
- Google hires developers with deep Smalltalk experience
- Squeak web site migrated to/powered by Aida/Web Squeak
- 4 (four) projects run through 2008's Goggle Summer of Code
- the "everybody needs it" Safara from GSoC as yet not in mainstream
- the "everybody needs it" Squeak GTK from GSoC as yet not in mainstream
- IBM builds Smalltalk IDE inside Eclipse
- Google hires developers with deep Smalltalk experience
- ESUG 2008 conference draws more attendands than ever

That list is of course incomplete, for example one wants to add the many
noobs who joined #squeak and the beginners mailing list.

I do not think that *soo* much is holding back Smalltalk ;)

/Klaus

--
"If at first, the idea is not absurd, then there is no hope for it".
Albert Einstein

> I understand the issues with Smalltalk in the past related to license
> costs and performance, but those have been addressed now. Have you tried
> to convince someone to consider Smalltalk and failed to convince them?
> Why do you think they rejected it? What improvements could be made to
> current Smalltalk environments, especially Squeak, that might sway them?
>
> For me the biggest issue has been trying to run my code from outside
> Squeak. This includes running Squeak headless to do something script-
> like and configuring a GUI application to run in a way that doesn't
> require the user to know they are running Squeak. Both of these are
> supposedly possible, but very difficult to get right.
>
> ---
> Mark Volkmann
>
>

Steven W Riggins

Re: [squeak-dev] Nothing much [was: what is holding back Smalltalk?]

I heard that google hired developers with deep Smalltalk
experience........

On Nov 21, 2008, at 12:28 AM, Klaus D. Witzel wrote:

> On Fri, 21 Nov 2008 00:02:47 +0100, Mark Volkmann <[hidden email]>
> wrote:
>
>> I don't have a lot of experience with Smalltalk yet, but I really
>> love what I've seen so far.
>>
>> I'm curious what experienced Smalltalkers see as some of the
>> reasons why it doesn't attract more attention.
>
> Me thinks that the Smalltalk community is healthy and vibrant--it is
> "just" a community form one would not expect for Ruby or Python or
> Perl, etc. To get impression of my impression take a look at what
> *actually* happened during the *recent* months:
>
> - Exupery (native x86 methods) powers Huemul
> - Seaside (web++ framework++) powers GLASS
> - Hydra (multiple parallel .images) powers Croquet .images
> - Google hires developers with deep Smalltalk experience
> - two more gods to be worshipped in the VM temple ;)
> - Squeak powers NewSpeak
> - new book Squeak by Example (creative commons license)
> - port of OpenDBX to Squeak (still not on windoze)
> - port of Squeak/VM to "another" smartphone platform ;)
> - DrGeo made it to the XO (OLPC)
> - fresh new subcommunity Pharo
> - attempt? to port Moose (world class sw analysis) to Squeak
> - Google hires developers with deep Smalltalk experience
> - Squeak web site migrated to/powered by Aida/Web Squeak
> - 4 (four) projects run through 2008's Goggle Summer of Code
> - the "everybody needs it" Safara from GSoC as yet not in mainstream
> - the "everybody needs it" Squeak GTK from GSoC as yet not in
> mainstream
> - IBM builds Smalltalk IDE inside Eclipse
> - Google hires developers with deep Smalltalk experience
> - ESUG 2008 conference draws more attendands than ever
>
> That list is of course incomplete, for example one wants to add the
> many noobs who joined #squeak and the beginners mailing list.
>
> I do not think that *soo* much is holding back Smalltalk ;)
>
> /Klaus

Bert Freudenberg

Re: [squeak-dev] Nothing much [was: what is holding back Smalltalk?]

Where did you hear that?

- Bert -

On 21.11.2008, at 10:47, Steven W Riggins wrote:

> I heard that google hired developers with deep Smalltalk
> experience........
>
> On Nov 21, 2008, at 12:28 AM, Klaus D. Witzel wrote:
>
>> On Fri, 21 Nov 2008 00:02:47 +0100, Mark Volkmann <[hidden email]>
>> wrote:
>>
>>> I don't have a lot of experience with Smalltalk yet, but I really
>>> love what I've seen so far.
>>>
>>> I'm curious what experienced Smalltalkers see as some of the
>>> reasons why it doesn't attract more attention.
>>
>> Me thinks that the Smalltalk community is healthy and vibrant--it
>> is "just" a community form one would not expect for Ruby or Python
>> or Perl, etc. To get impression of my impression take a look at
>> what *actually* happened during the *recent* months:
>>
>> - Exupery (native x86 methods) powers Huemul
>> - Seaside (web++ framework++) powers GLASS
>> - Hydra (multiple parallel .images) powers Croquet .images
>> - Google hires developers with deep Smalltalk experience
>> - two more gods to be worshipped in the VM temple ;)
>> - Squeak powers NewSpeak
>> - new book Squeak by Example (creative commons license)
>> - port of OpenDBX to Squeak (still not on windoze)
>> - port of Squeak/VM to "another" smartphone platform ;)
>> - DrGeo made it to the XO (OLPC)
>> - fresh new subcommunity Pharo
>> - attempt? to port Moose (world class sw analysis) to Squeak
>> - Google hires developers with deep Smalltalk experience
>> - Squeak web site migrated to/powered by Aida/Web Squeak
>> - 4 (four) projects run through 2008's Goggle Summer of Code
>> - the "everybody needs it" Safara from GSoC as yet not in mainstream
>> - the "everybody needs it" Squeak GTK from GSoC as yet not in
>> mainstream
>> - IBM builds Smalltalk IDE inside Eclipse
>> - Google hires developers with deep Smalltalk experience
>> - ESUG 2008 conference draws more attendands than ever
>>
>> That list is of course incomplete, for example one wants to add the
>> many noobs who joined #squeak and the beginners mailing list.
>>
>> I do not think that *soo* much is holding back Smalltalk ;)
>>
>> /Klaus
>

Bert Freudenberg

Re: [squeak-dev] what is holding back Smalltalk?

In reply to this post by Mark Volkmann

On 21.11.2008, at 00:36, Mark Volkmann wrote:

> On Nov 20, 2008, at 5:28 PM, David Mitchell wrote:
>
>> Most of the things that make Smalltalk great (what makes Smalltalk
>> Smalltalk) are the things that hold it back for a lot of people.
>
> Maybe I'm naive on this, but it seems like it should be easy
> convince lots of people that Smalltalk has a beautiful syntax and a
> wonderful development environment.

Maybe you are naive ;)

I think David nailed it.

Smalltalk is powerful precisely because it is different than today's
popular programming environments. The idea of a "live system" is too
strange for the masses.

The thing with the popular languages is that they all are used in
pretty much the same way - write source code in a file in an editor or
IDE of your choice, build your program, run it, debug it, ship it.
This makes it relatively easy to switch to a new language, it's
basically just a different syntax and a change in the makefiles. You
can easily replace parts of your project with pieces in another
language. The SCM can work the same. You can continue to use the
editor you know in your sleep.

All that makes switching to Smalltalk hard to do on your own, you
basically need a team that has made the transition already. It also
makes it hard to use for a little side project, because the initial
overhead of new things to consider is so big. It makes it hard to find
its place in the wider open-source community, which is becoming (or
already is) the primary educational resource for new programmers.

But to cater to these wider audiences you would indeed have to strip
Smalltalk of what makes it Smalltalk. It's been done of course, but
what you end up with is not Smalltalk anymore.

- Bert -

12345