JAjajaja, It's not that Indexes are not trustable... They are measured in a way Smalltalk will never be recognized as popular: - searches in yahoo - open source projects in some webs - people asking for job The only one that surprized me is the book's one. But 1) the data is not taken from amazon and I don't know this Powell's Books library :P. 2) It's true that there is a stupid amount of java, c#, c++ books... Maybe we can think a not so stupid index. Cheers On Mon, Dec 6, 2010 at 4:12 AM, laurent laffont <laurent.laffont@gmail.com>wrote:

And I've just seen the bottom of the message :), it seems http://langpop.com/ agree with TIOBE.

On Mon, Dec 6, 2010 at 8:09 AM, laurent laffont <laurent.laffont@gmail.com

...

wrote:

...

On Mon, Dec 6, 2010 at 6:51 AM, James Ladd <james_ladd@hotmail.com>wrote:

...

While pleading for Smalltalk support with a developer from a popular and great IDE company, I got the

following response (below)

Is there anything I can do/show to prove or disprove the popularity of Smalltalk?

According to TIOBE, Smalltalk is as popular as Erlang and more popular than Scala http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

But that's only numbers and I don't trust it :)

May be your developer from a "popular" IDE company should define what "popular" means...

Laurent

...

Rgs, James.

...

...

Hello James. About Smalltalk plugin. Weel, I’m not sure Smalltalk has a big audience now. I’ve never heard about commercial products based on Smalltalk.

...

...

Here, some statistics http://langpop.com/

Igor, My perceived experience in project we used freshmen from a University to work in Smalltalk for the Spatmas platform, was a little different. The persons needed about the same than the Java colleagues (which worked in a complimentary part of the project) to become proficient and productive in Smalltalk. We Smalltalkers take sometimes at face value certain things that clash in real world: the famous simplicity of the syntax (which Stef's famous postcard example) of Smalltalk is completely flared by the overwhelming complexity of the class libraries. Contrary to current belief, out of the core libraries (specially the Collection hierarchy) most of the remaining packages are not that elegant or orthogonal enough to preclude the need for digging and learning from experience, which takes as much time as any other language. As soon we get at the need to build production grade systems, we find Smalltalks advantages are not enough to make us stand out of the crowd. my 0.019999... -- Cesar Rabak Em 06/12/2010 10:44, Igor Stasenko < siguctua@gmail.com > escreveu: On 6 December 2010 13:38, Guillermo Polito wrote:

JAjajaja,

It's not that Indexes are not trustable...  They are measured in a way Smalltalk will never be recognized as popular:

- searches in yahoo - open source projects in some webs - people asking for job

The only one that surprized me is the book's one.  But 1) the data is not taken from amazon and I don't know this Powell's Books library :P. 2) It's true that there is a stupid amount of java, c#, c++ books...

i think there is a lot of books because they are very complex ones :) for a smalltalk, you need just one book, and .. whooop .. you know it after few days of study. For C++ or Java it takes couple of months to learn all this stuff..

Maybe we can think a not so stupid index.

Cheers

On Mon, Dec 6, 2010 at 4:12 AM, laurent laffont wrote:

...

And I've just seen the bottom of the message :), it seems http://langpop.com/ agree with TIOBE.

On Mon, Dec 6, 2010 at 8:09 AM, laurent laffont wrote:

...

On Mon, Dec 6, 2010 at 6:51 AM, James Ladd wrote:

...

While pleading for Smalltalk support with a developer from a popular and great IDE company, I got the

following response (below)

Is there anything I can do/show to prove or disprove the popularity of Smalltalk?

According to TIOBE, Smalltalk is as popular as Erlang and more popular than Scala http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html But that's only numbers and I don't trust it :) May be your developer from a "popular" IDE company should define what "popular" means... Laurent

...

Rgs, James.

...

...

Hello James.

...

...

About Smalltalk plugin. Weel, I’m not sure Smalltalk has a big audience now. I’ve never heard about commercial products based on Smalltalk. Here, some statistics http://langpop.com/

-- Best regards, Igor Stasenko AKA sig.

Em 06/12/2010 17:35, Sean P. DeNigris < sean@clipperadams.com > escreveu:

csrabak wrote:

...

e persons needed about the same than the Java colleagues (which worked a complimentary part of the project) to become proficient and productive in Smalltalk. by the time I was "proficient and productive in Smalltalk," I had ered the equivalent of an OS! From threading, to windows, the main t loop - all things that were magically behind the scenes in C, C++, and Ruby to an extent (which at the outer GUI level was down in the same ). Whereas, it really did take only one reading to grok the syntax.

Well, comparing C, even C++ which normally hasn't automatic garbage collection, is somewhat stretching the argument... but; even with those "idiosyncrasies" as soon the size of the application grows up, these perks of Smalltalk quickly become less noticeable, while on the other hand the fact Smalltalk being dynamic dispatched takes its toll in the needing of programmers attention to avoid the attribution of wrong objects to instance variables as there is no type checking...

csrabak wrote:

...

Smalltalkers take sometimes at face value certain things that clash in al world: the famous simplicity of the syntax (which Stef's famous stcard example) of Smalltalk is mpletely flared by the overwhelming complexity of the class libraries.

fact that mastering anything takes time - is orthogonal to the book e. The majority of books I came across in C++ (and needed copies of in y office I worked, to the point where I got a $50 a month Safari books cription) were related to the language, not the libraries - full of , gotchas, and other advice to not trip over the complexities of the uage itself - before even considering the first library!

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¹?

ease of use of a library is a function of the design skill of the ary developers. But I bet you it was much easier to *write* that ary than it would have been in a static language in a non-live ronment ;-)

While the libraries are for 'endogenous' use, yes, as soon we need to have functionality to put our apps in the same stand as the other technologies are right now, the issues start to become all the same... And them the advantages of Smalltalk as platform vanishes against ones more coupled to present technology. Have you tried to automate an Office application with any flavor of Smalltalk lately? Did you see the thread "Is there a good example of an app using SqueakDBX to output data?" All the simplicity of Smalltalk is lost as soon you need to fit the square peg in the round hole... :-| my 0.019999... -- Cesar Rabak [1] http://www.jmcsweeney.co.uk/computing/m206/traps.doc

Dennis, I think if we dig enough we'll find a list of similar size right here in Pharo-project list... Look for the thread about 'silent failures' by Bill Schawb, and similar threads. We have to accept that what used to be 'oddity' became 'intuitive' or 'natural' as (my favorite example) the case of from ver 95 onwards, to turn off a Windows machine you've to look for the "Start" button... -- Cesar Rabak Em 07/12/2010 04:27, Dennis Schetinin < chaetal@gmail.com > escreveu: 2010/12/7 <csrabak@bol.com.br> 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¹? Just to compare: http://www.javapuzzlers.com/contents.html :) -- Dennis Schetinin

On Tue, Dec 7, 2010 at 2:57 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:

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:

Just to ilustrate =) http://www.amazon.com/Java-Pitfalls-Time-Saving-Solutions-Workarounds/dp/047... http://www.amazon.com/Java-TM-Puzzlers-Pitfalls-Corner/dp/032133678X/ref=sr_... Cheers, Francisco

* 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.

On 12/7/2010 5:38 PM, csrabak@bol.com.br 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

+10^27 (That's hellaplus ;-)) Best and most positive rant I've heard in a long time! -- Cheers, Peter On Wed, Dec 8, 2010 at 2:26 AM, Eliot Miranda <eliot.miranda@gmail.com>wrote:

Hear hear!!

(specific responses below)

On Tue, Dec 7, 2010 at 5:21 PM, Jimmie Houchin <jlhouchin@gmail.com>wrote:

...

On 12/7/2010 5:38 PM, csrabak@bol.com.br 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

jimmie I agree :)

On Wed, Dec 8, 2010 at 9:00 AM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:

...

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?

I have a prototype reentrant FFI that can do threaded call-outs and receive threaded callbacks. I was demoing it in Argentina but my demo locks up the UI (not the entire image thoguh) so it is not by any means production-ready. I need to find time to finish it. That's not going to happen in the next two months. I'll see what can be done to get it released in an unfinished state so that others can work on it. best Eliot

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

Stef

Bravo, well and truly stated. (I can't help but wonder how many folks who talk about this stuff have actually encountered an "Enterprise" in real life, and if so why they are still so eager to impress these people, much less go to work for them.) Thanks Jimmy, you have captured a lot of positive energy in a few words. Dave On Tue, Dec 07, 2010 at 07:21:58PM -0600, Jimmie Houchin wrote:

On 12/7/2010 5:38 PM, csrabak@bol.com.br 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

On 8 December 2010 03:16, David T. Lewis <lewis@mail.msen.com> wrote:

Bravo, well and truly stated.

(I can't help but wonder how many folks who talk about this stuff have actually encountered an "Enterprise" in real life, and if so why they are still so eager to impress these people, much less go to work for them.)

Yeah.. It is familiar attitude towards big companies, which i don't sharing. It is starting from first small things, like "i am so proud that i working in huge company" , which immediately rings the bell in my head with a thought: "so, maybe you should start paying this company for being an employee of it?" All this shit: thinking BIG , we are big, we are many.. the common enterprise-level indoctrination , which have nothing to do with a) productivity b) efficiency c) quality of products/services and could even have a reverse effect. So, that's why i DON'T care what enterprise-level people doing and what they thinking about smalltalk. I KNOW that whatever they do, they doing it wrong :)

Thanks Jimmy, you have captured a lot of positive energy in a few words.

Dave

...

Jimmie

-- Best regards, Igor Stasenko AKA sig.

Thank you Jimmie, I've enjoyed your mail. And as a "little guy in the enterprise who has small side projects", I feel Pharo is better week after week and this is good. Laurent On Wed, Dec 8, 2010 at 2:21 AM, Jimmie Houchin <jlhouchin@gmail.com> wrote:

On 12/7/2010 5:38 PM, csrabak@bol.com.br 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

On 6 December 2010 21:22, Tudor Girba <tudor.girba@gmail.com> wrote:

This kind of view is nice as a joke, but I also think it tends to be counter productive. We should not kid ourselves. There are so many books because there is a market large enough to consume them.

No, but you know, books about Java or C++ dedicating a full chapters explaining classes, visibility rules, constructors, destructors, virtual functions, templates or <generics> and all things related to that. A lot of wasted paper (where the Green Peace looking? ;)) And now take the smalltalk at the other side. What we have? Just classes and methods. Simple rules. End. So, at the day when one student finish learning the basics of java or C++, a student who decided to learn smalltalk will finish learning a standard class library basics, and will be ready to go with first coding attempts. While Java/C++ student will still be 2 or 3 chapters away from finishing with basic language concepts and rules. It is a lot of time for reading, not mentioned about how much time it takes to comprehend and understand all the concepts and remember them. Yes, maybe its a bigger market. But i know a good way to learn something: write a description (book) of it. So it looks like many people wanting to learn C++ or Java so bad, that they start writing a books about it. Good for them. Good for readers. Bad for Green Peace :)

Cheers, Doru

-- Best regards, Igor Stasenko AKA sig.

To add a little of data to anecdote, let me put two complimentary pointers: Talks about the "The US Department of Defense has decided to discontinue the development, maintenance, and –use- of JAS (nee JWARS) by year end. JAS is a joint campaign model, (one that represents all the services), consisting of over 1.1 million lines of Smalltalk that has been developed over the last 15 years at a cost to the taxpayers north of $110 million." Further details: http://groups.google.com/groups/profile?enc_user=gNSEzw8AAADszNgJiajay96Y7oE... About Gartner's affirmations (ten years old!) http://groups.google.com/group/ibm.software.vasmalltalk/browse_thread/thread... And a case study of a company that decided _not_ switch from Smalltalk after tried to go java: http://www.nycsmalltalk.org/2009/11/return-to-smalltalk/ HTH to enlighten our discussions on these matters. -- Cesar Rabak Em 06/12/2010 14:27, csrabak@bol.com.br escreveu: Guillermo, While all the criticisms of yours are correct, they do not change the reality. If you take some other sources like the inventory of systems benchmarked by companies specializing in this kind of job¹, or government inventories or even the ISBSG database, you'll find Smalltalk use (which relates to 'popularity') is residual in any realm. In fact, Gartner issued some years ago a research note² and classified languages according to a "A Life-Cycle Maturity Matrix". Recently James Robertson from Cimcon managed to have Gartner to write (in a blog, however, no "Research") flattering things about Smalltalk in a context of dynamic languages. Regards, -- Cesar Rabak [1] Not so blatant advice: I used to work for Gartner and now I represent SPR. [2] TU-05-1942 "Life-Cycle Strategies for Legacy Languages", J. Duggan, Gartner, Stamford, CT, 1998. Em 06/12/2010 10:38, Guillermo Polito < guillermopolito@gmail.com > escreveu: JAjajaja, It's not that Indexes are not trustable...  They are measured in a way Smalltalk will never be recognized as popular: - searches in yahoo - open source projects in some webs - people asking for job The only one that surprized me is the book's one.  But 1) the data is not taken from amazon and I don't know this Powell's Books library :P. 2) It's true that there is a stupid amount of java, c#, c++ books... Maybe we can think a not so stupid index. Cheers On Mon, Dec 6, 2010 at 4:12 AM, laurent laffont wrote: And I've just seen the bottom of the message :), it seems http://langpop.com/ agree with TIOBE. On Mon, Dec 6, 2010 at 8:09 AM, laurent laffont wrote: On Mon, Dec 6, 2010 at 6:51 AM, James Ladd wrote: While pleading for Smalltalk support with a developer from a popular and great IDE company, I got the following response (below) Is there anything I can do/show to prove or disprove the popularity of Smalltalk? According to TIOBE, Smalltalk is as popular as Erlang and more popular than Scala http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html But that's only numbers and I don't trust it :) May be your developer from a "popular" IDE company should define what "popular" means... Laurent Rgs, James.

...

Hello James.

...

About Smalltalk plugin. Weel, I’m not sure Smalltalk has a big audience now. I’ve never heard about commercial products based on Smalltalk. Here, some statistics http://langpop.com/

Em 06-12-2010 13:38, csrabak@bol.com.br escreveu:

James,

The point of your post will surely be answered by other, and I'm sure you'll find good stuff in STIC and ESUG websites.

However, the purpose of yours surprises me: why do you think that having "a popular and great IDE company" "supporting" Smalltalk is of any help? In the past there were "big companies" "supporting" smalltalk and the result was no good. If one reads some of smalltalk history he'll see a spectacle of greed & other bad doings and nasty mistakes by corporations.

The biggest problem with smalltalk itself was that it was far ahead its time. Now it's not. Further than that, when one sees things like CogVM coming to life (which enhances performance of applications) and things being developed in seaside and related tools (pier, magritte, etc) it becomes clear the advantages of adopting smalltalk, despite some issues are still recurrent like: the lack of a "foundation classes" definition (thus much of trunk/pharo/etc changing overtime and requiring constant attention and maintenance by developers) and lack of documentation (which is consequence of first issue).

Decoupling the Smalltalk environment from the "IDE" will make a Frankenstein which will make the acronym 'IDE' look like an oxymoron... There are some implementations decoupled from IDEs. But in the end of the day everybody needs a browser, an inspector, a debugger, a workspace, a Transcript, etc... And nobody really needs to develop a "windows native", "X Windows native", "aqua/OS-X/iOS native" version of the same application (at least not that frequently). Anyways, if the intention is running an application with the "native interface" deactivated it's always possible to execute smalltalk headless.

Regards CdAB

Regards,

-- Cesar Rabak

Em 06/12/2010 03:51, James Ladd < james_ladd@hotmail.com > escreveu:

While pleading for Smalltalk support with a developer from a popular and great IDE company, I got the

following response (below)

Is there anything I can do/show to prove or disprove the popularity of Smalltalk?

Rgs, James.

...

...

Hello James. About Smalltalk plugin. Weel, I’m not sure Smalltalk has a big audience now. I’ve never heard about commercial products based on Smalltalk. Here, some statistics http://langpop.com/

On 6 December 2010 23:22, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi James,     a good list of enterprise projects is here http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=successes.  The high-lights are JP Morgan, and Texas Instruments/Adventa.  But also try and dig up stuff on OOCL's ISIS 2 shipping app and Deutche Bahn's schduling application (computes schedules for the entire German railway system). If you dig you'll find lots of enterprise applications written in Smalltalk.  When I started working for ParcPlace Systems companies like JPMorgan didn't allow us to name then since using Smalltalk was such an important competitive advantage.  That shot a lot of feet, indiscriminately amongst both corporate user and vendo aliker.

That's kind of fun. It reminds me the fisherman, who i met once on the lake, and when i said that i came here just for one day as a guest of my really far relatives, then he smiled and started saying everything about fishing, and saying that at his place, a fish catching goes like on conveyor, but for all people who passed by, he was making a bored face and saying that , ohhh.. no fish damn it.. no fish.. bad place, reaallyy bad one :) -- Best regards, Igor Stasenko AKA sig.

Sorry if I'm late on this thread, only wanted to say that lot of times in similar discussions I said that "fortunately" Smalltalk is not very popular (In terms that not tons of people and companies are using it). Each one can make its own interpretation :) Just my 0,02. 2010/12/6 Eliot Miranda <eliot.miranda@gmail.com>:

On Mon, Dec 6, 2010 at 2:38 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 6 December 2010 23:22, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

Hi James,     a good list of enterprise projects is

here http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=successes.  The high-lights are JP Morgan, and Texas Instruments/Adventa.  But also try and dig up stuff on OOCL's ISIS 2 shipping app and Deutche Bahn's schduling application (computes schedules for the entire German railway system). If you dig you'll find lots of enterprise applications written in Smalltalk.  When I started working for ParcPlace Systems companies like JPMorgan didn't allow us to name then since using Smalltalk was such an important competitive advantage.  That shot a lot of feet, indiscriminately amongst both corporate user and vendo aliker.

That's kind of fun. It reminds me the fisherman, who i met once on the lake, and when i said that i came here just for one day as a guest of my really far relatives, then he smiled and started saying everything about fishing, and saying that at his place, a fish catching goes like on conveyor, but for all people who passed by, he was making a bored face and saying that , ohhh.. no fish damn it.. no fish.. bad place, reaallyy bad one :)

it's great for the fisherman, but really bad for the bait shop... :) :( :/ best Eliot

...

-- Best regards, Igor Stasenko AKA sig.

On 12/21/2010 09:05 AM, Sean P. DeNigris wrote:

Eliot Miranda-2 wrote:

...

When I started working for ParcPlace Systems companies like JPMorgan didn't allow us to name then since using Smalltalk was such an important competitive advantage.

Julian Fitzell says that this is still the case @ http://vimeo.com/17503969

Sean

I can confirm that this is still true today for GemStone... Dale