Popularity or not of smalltalk?

This is fun!  Thanks for the discussion...

csrabak wrote:
>
> Sean, once you really get to metal subtleties and other nuances on the
> language and syntax appear to bug your team.  Have you ever heard of
> John McSweeney's "Smalltalk ‘Traps’" piece¹?
>

[ sean isOnChair ] whileTrue: [ sean laugh ].
 

7 pages! (actually 6.5 - with embedded images)  That actually proves my
point vs. entire textbooks ;-)  Not to mention that:

* the first page and a half's examples are trivial and not exactly "traps"
(the fact that self is implicitly returned)
* the "10 + (10 negated) negated" "trap" executes intuitively and correctly
in Squeak
* the example of changing a loop while iterating with do: seems like C++
code translated literally into Smalltalk
* the last 1.5 pages are totally contrived (and use global variables which
are discouraged anyway; I haven't had to use one yet) - yes, if you *want*
to screw up the system, you can:
   #right
       basicAt: 1 put: 119;
       basicAt: 2 put: 114;
       basicAt: 3 put: 111;
       basicAt: 4 put: 110;
       basicAt: 5 put: 103.
   #right
An equivalent argument is: if you hit your laptop repeatedly with a bat, it
will not work regardless of what programming language you were using, so you
might as well pick any

csrabak wrote:
>
> Well, comparing C, even C++ which normally hasn't automatic garbage
> collection, is somewhat stretching the argument...
>

Well, that's just the point, isn't it?  We're talking about language
popularity and those are #2 and #3 on the TIOBE index.

csrabak wrote:
>
> even with those
> "idiosyncrasies" as soon the size of the application grows up, these
> perks of Smalltalk quickly become less noticeable
>

I've been using Smalltalk for less than a year, but I'm already more
productive by far than in C, C++, or even Ruby, and haven't hit that limit
writing software for small businesses.  If there is a size at which the
benefit lessens, isn't it more likely caused by poor design/devs or any
number of factors (don't most large projects fail)?  It can't be the same or
worse to use a poor library in a dynamic live environment.  I recently wrote
a simple Ruby bridge and found it liberating to deal with the library in the
Smalltalk tools rather than in Ruby's code/run cycle.


csrabak wrote:
>
> Smalltalk... programmers attention to avoid the attribution of wrong

> objects to instance variables as there is no type checking...
>

I have never encountered this and I've often heard it said by dynamic
language experts to be mostly static language paranoia.  What is the
evidence that this becomes a severe problem in real-life dynamic systems?

Sean
--
View this message in context: http://forum.world.st/Popularity-or-not-of-smalltalk-tp3073990p3076885.html

Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Hear hear!!

(specific responses below)

On Tue, Dec 7, 2010 at 5:21 PM, Jimmie Houchin <[hidden email]> wrote:

On 12/7/2010 5:38 PM, [hidden email] wrote:

Sean,

Hope that additional to the fun, we can converge to an understanding how can we increase Smalltalk popularity.

OTOH, I made the reference as a sample, I did not intend to have this as all encompassing list of issues nor start a thread about comparisons with other languages.

As I said earlier, what is 'trivial' or 'intuitive' for some is 'maverick' or 'bizarre' for others, it is in the eyes of the beholder... ;-)

My main message is more around this: although Smalltalk was a very advanced technology when its inception, present status have almost all of its characteristics embedded in present technology.  Even, when newer concepts as xUnit have started in Smalltalk, the _concept_ was absorbed in mainstream technologies so again we're stuck with small delta between what Smalltalk does 'better' than the incumbent technologies we would like to replace.

I can't help but disagree with this most strenuously.

Almost nothing has touched Smalltalk's advanced technology. They don't have the world view or paradigm for doing so. They are languages that operate in dead cycles. They have dead processes and do dead post mortem debugging. Yuck!  (yes, I know that was redundant. :)

I am not a computer scientist or trained programmer. I am a creative guy who is a businessman. I find Smalltalk empowering. I also use Python when necessary, but Squeak/Pharo is my preferred language. I find myself infinitely more productive in Smalltalk than in Python. Operating in a live environment is incredibly empowering, enabling and productive. Where else can I find this. C, C++, C#, Java, Python, Ruby, VB, nope, none...

Demonstrating large scale Smalltalk projects have been canceled does not prove Smalltalk's inferiority, nor that the competition (should one choose to refer to them as such) has caught up or passed us. Especially when said project was not canceled for technical reasons but political ones and for software that was/is demonstrably inferior to the already existing Smalltalk software. But what it does prove is that Smalltalk has been and can be effectively deployed for large scale projects where someone has the courage or political will to choose something different than the status quo languages.

The decisions of PHBs (Pointy Haired Bosses, Dilbert) does not invalidate anything about Smalltalk. After all their primary motivation is job security, not project success. No one ever got fired for choosing, MS, Java, IBM, Oracle, etc...

The biggest weakness for Smalltalk or at least our open source version in Squeak/Pharo IMHO is its integration, cooperation or access story to certain outside systems and technologies. And I speak as an end user who cannot develop a plugin, or use Alien or FFI and program in C.  In my situation for example. I have to interface to either a Windows dll or to a Java library to access financial servers. No choice. So I must choose a technology which can interface their technology. In my case, I chose to use Python to interface the Windows dll. I have written a minimal Python app which accesses the dll and thus the servers to access the data and my accounts. But the business logic I am writing in Pharo. The Python app simply provides my Pharo app the data and executes the actions directed by the Pharo app.

Indeed.  An immature FFI, lack of dll options etc.  Integration is indeed one of the biggest weaknesses.  But we're making progress here.  So things may be different in months, if not years.

 

I would that I could have interfaced the dll (or Java library) directly from Pharo. But despite that obstacle I am choosing to write my app in Pharo. Most in this business are using VB/C#/Java. They do not provide the flexibility or productivity that I have in Pharo/Smalltalk. They do not enable the small guy like me as well as Pharo/Smalltalk. Yes, this is my opinion. But guess what. This is a Pharo mailing list populated by people who are for and proponents of Smalltalk. If we favored other languages and environments we would be there. Many of those on the this list are also pretty dog gone expert in the other technologies as well. They did not make their decisions out of ignorance. What I don't understand is that if you are so convinced that the advantages of Smalltalk are so minimal and of no consequence, then why are you here?

I would like to see Pharo/Squeak bridge the gap to be able to interface system components or other business libraries. I would like to be able to use Pharo/Squeak anywhere I could use Python. I would like to see that there are fewer and fewer technical reasons for not choosing Pharo/Squeak. I can understand other choices. Other people are more comfortable with other languages, systems, environments. They may have a knowledge, systems, and process investment. But this can only validate their decision for them and in no way invalidates the technology or capabilities of Smalltalk.

There are many, many projects for which Smalltalk/Pharo/Squeak have no discernible technological disadvantages. They do not require any systems integration or use of the "native ui".

Enterprise. I agree with the sentiment that we don't need to worry about it. Let Cincom address enterprise users. We need to empower the little guy in the enterprise who has small side projects which do not have to go through the same channels as the larger "enterprise" projects. Projects for which they might choose Python or Ruby. Over time we can improve our enterprise story and infiltration. Fortunately for us, Smalltalk/Squeak/Pharo is in the long game. It has seen technologies come and go and is still here. If we the open source Smalltalk community continue to make the improvements we are making, then we will be an increasingly viable choice for the entrepreneur, small businessman, enterprise guy with the side project, the person with a project they do on their personal time at home. It is the most enabling technology I know.

Well, I'll end my rant here and get back to being enabled in the development of my business app.

Jimmie

Thanks for these fine words Jimmie!

best

Eliot 

On 12/7/2010 5:38 PM, [hidden email] wrote:

Sean,

Hope that additional to the fun, we can converge to an understanding how can we increase Smalltalk popularity.

OTOH, I made the reference as a sample, I did not intend to have this as all encompassing list of issues nor start a thread about comparisons with other languages.

As I said earlier, what is 'trivial' or 'intuitive' for some is 'maverick' or 'bizarre' for others, it is in the eyes of the beholder... ;-)

My main message is more around this: although Smalltalk was a very advanced technology when its inception, present status have almost all of its characteristics embedded in present technology.  Even, when newer concepts as xUnit have started in Smalltalk, the _concept_ was absorbed in mainstream technologies so again we're stuck with small delta between what Smalltalk does 'better' than the incumbent technologies we would like to replace.

I can't help but disagree with this most strenuously.

Almost nothing has touched Smalltalk's advanced technology. They don't have the world view or paradigm for doing so. They are languages that operate in dead cycles. They have dead processes and do dead post mortem debugging. Yuck!  (yes, I know that was redundant. :)

I am not a computer scientist or trained programmer. I am a creative guy who is a businessman. I find Smalltalk empowering. I also use Python when necessary, but Squeak/Pharo is my preferred language. I find myself infinitely more productive in Smalltalk than in Python. Operating in a live environment is incredibly empowering, enabling and productive. Where else can I find this. C, C++, C#, Java, Python, Ruby, VB, nope, none...

Demonstrating large scale Smalltalk projects have been canceled does not prove Smalltalk's inferiority, nor that the competition (should one choose to refer to them as such) has caught up or passed us. Especially when said project was not canceled for technical reasons but political ones and for software that was/is demonstrably inferior to the already existing Smalltalk software. But what it does prove is that Smalltalk has been and can be effectively deployed for large scale projects where someone has the courage or political will to choose something different than the status quo languages.

The decisions of PHBs (Pointy Haired Bosses, Dilbert) does not invalidate anything about Smalltalk. After all their primary motivation is job security, not project success. No one ever got fired for choosing, MS, Java, IBM, Oracle, etc...

The biggest weakness for Smalltalk or at least our open source version in Squeak/Pharo IMHO is its integration, cooperation or access story to certain outside systems and technologies. And I speak as an end user who cannot develop a plugin, or use Alien or FFI and program in C.  In my situation for example. I have to interface to either a Windows dll or to a Java library to access financial servers. No choice. So I must choose a technology which can interface their technology. In my case, I chose to use Python to interface the Windows dll. I have written a minimal Python app which accesses the dll and thus the servers to access the data and my accounts. But the business logic I am writing in Pharo. The Python app simply provides my Pharo app the data and executes the actions directed by the Pharo app.

I would that I could have interfaced the dll (or Java library) directly from Pharo. But despite that obstacle I am choosing to write my app in Pharo. Most in this business are using VB/C#/Java. They do not provide the flexibility or productivity that I have in Pharo/Smalltalk. They do not enable the small guy like me as well as Pharo/Smalltalk. Yes, this is my opinion. But guess what. This is a Pharo mailing list populated by people who are for and proponents of Smalltalk. If we favored other languages and environments we would be there. Many of those on the this list are also pretty dog gone expert in the other technologies as well. They did not make their decisions out of ignorance. What I don't understand is that if you are so convinced that the advantages of Smalltalk are so minimal and of no consequence, then why are you here?

I would like to see Pharo/Squeak bridge the gap to be able to interface system components or other business libraries. I would like to be able to use Pharo/Squeak anywhere I could use Python. I would like to see that there are fewer and fewer technical reasons for not choosing Pharo/Squeak. I can understand other choices. Other people are more comfortable with other languages, systems, environments. They may have a knowledge, systems, and process investment. But this can only validate their decision for them and in no way invalidates the technology or capabilities of Smalltalk.

There are many, many projects for which Smalltalk/Pharo/Squeak have no discernible technological disadvantages. They do not require any systems integration or use of the "native ui".

Enterprise. I agree with the sentiment that we don't need to worry about it. Let Cincom address enterprise users. We need to empower the little guy in the enterprise who has small side projects which do not have to go through the same channels as the larger "enterprise" projects. Projects for which they might choose Python or Ruby. Over time we can improve our enterprise story and infiltration. Fortunately for us, Smalltalk/Squeak/Pharo is in the long game. It has seen technologies come and go and is still here. If we the open source Smalltalk community continue to make the improvements we are making, then we will be an increasingly viable choice for the entrepreneur, small businessman, enterprise guy with the side project, the person with a project they do on their personal time at home. It is the most enabling technology I know.

Well, I'll end my rant here and get back to being enabled in the development of my business app.

Jimmie

>
>
> Indeed.  An immature FFI, lack of dll options etc.  Integration is indeed one of the biggest weaknesses.  But we're making progress here.  So things may be different in months, if not years.

Eliot did you get interpret reentrant?

Because we are discussing that point with igor and yes we want that to have :)

Stef