There was an interesting post on comp.lang.smalltalk which, although semi-off-topic (it concerns Smalltalk as a language, rather than Squeak as an implementation specifically), reveals some of the misunderstandings that many industry professionals have toward Smalltalk in general.
The main portion of the message consists of a "(virtual) conversation between a decision maker and a Smalltalk programmer." It seems that many of these misunderstandings (with the exception of the one related to speed, since Squeak is actually quite fast) relate to Squeak as well.
Any comments?
A forwarded copy of that post follows:
On Tue, 17 Nov 2009 00:15:17 +0100, in comp.lang.smalltalk Guido Stepken gstepken@googlemail.com wrote: --8<---------------cut here---------------start------------->8--- Truth schrieb:
After watching http://railsconf.blip.tv/file/2089545/ I have to respond - somewhere. Smalltalk died of a hundred cuts.
Oh, yes, i really enjoyed watching this.
I think, smalltalk died a lack of communication what smalltalk really is:
Smalltalk is a 'reflection language' about and written in itself, represented by a bunch of - RAM floating - 'set of activities' - often miscalled 'objects', communicating like a neuronal network with itself and with its programmers, with the possibility to put/freeze that in a single file, called 'image'.
Just to make that a bit more transparent, here a (virtual) conversation between a decision maker and a Smalltalk programmer:
DM: "Please show me: What have you programmed last years? Where are your libraries? Where's your code contribution?"
- "Sorry, there are no libraries! We have source, yes! My code? Somewhere within the spittoon of Smalltalk - code. There are no libraries. They're called 'image'. Can't say, what code i have contributed in the last years."
"Ok! And where's our data?"
- "Sorry, there is no data!"
"But there must be our data somewhere. Experts say and Oracle sais, we need a 'data warehouse'. We will have to put all our data into a central database!"
- "Sorry - we have no data, no code - we have 'objects'!"
"Ok. I understand. Can you store those 'objects' in Oracle?"
- "Hmmm. No! Does not make any sense."
"I understand. But all the other programmers say, of course, every programming language is about code and data and state variables!"
- "Sorry, no! Smalltalk is a different thing. We even don't have 'states'"
"Ok, I see, we have to change to Java or to C++ to get that mismatch solved."
- "There is no need to switch to other languages. We are quite productive!"
"Ok, maybe. But the board of directors urge me to introduce a central 'data warehouse' on Oracle. Experts say, that's what all companies need nowadays!"
- "No need to introduce Oracle. We even can control a whole production plant with Smalltalk! Statistics included. They're done on the fly."
"Without central data warehouse? Without Crystal Report, SPSS, Excel?"
- "Yes! I can simply code that into Smalltalk"
"But the other programmers say: 'Smalltalk is slow!' You even can't control a production plant with one single C++ programm! You need fast 'real time operating systems' and 'real time program language', all experts say that!"
- "Yes, Smalltalk is much slower. And Smalltalk is no 'real time system'. But it works fine since many years!"
"Hmmm. Sounds very unrealistic! A whole production plant controlled by one pentium processor. Ridiculous! By the way: Does Smalltalk 'scale'?
- "Hmmm. No!"
"Our controlling sais - They need to do their own statistics on Crystal Report, SPSS, Excel. They want to make nice productivity charts! Can they get their own ODBC - Interface - secured by password - to access data within the 'Smalltalk Image'?"
- "Hmmm. No. There is no such interface. But i simply could add some counting variables in Smalltalk."
"No, thanx. Our controlling uses sequel! We have paid a lot to teach them how to make nice production charts with Excel, CR, SPSS and POWERPOINT, of course! Now you say, the have to learn 'Smalltalk'? No! They are no programmers! They are controllers! They have to control you!
Ok. Conclusion: We probably run into many troubles, if we don't switch to a central data warehouse and a modern progamming language, that 'scales', like JAVA or C++. All experts say - we need central data warehouse, advanced controlling in production, near realtime statistics via ODBC-access, RT-OS.
By the way - Can you accellerate Smalltalk code by 'inline assembler', like in C++?"
- "Can you accelerate your brain by 'inline assembler'? Does it scale?"
"You are fired!"
Just my 2ct.
Have fun,
Guido Stepken --8<---------------cut here---------------end--------------->8---
-- Benjamin L. Russell
Benjamin L. Russell wrote:
The main portion of the message consists of a "(virtual) conversation between a decision maker and a Smalltalk programmer." It seems that many of these misunderstandings (with the exception of the one related to speed, since Squeak is actually quite fast) relate to Squeak as well.
Any comments?
If there is a lesson here (I'm not sure there is) then it's this: Don't be an egocentric, moronic programmer who knows everything better. Learn how to explain Smalltalk to your boss in terms (s)he can understand. Explain that the "libraries" are called "classes" and "frameworks", that we call "data" just "objects" because they have both "state" and behavior. Relate the current industry buzzwords to the equivalent Smalltalk concepts. Yes, there are differences, but they are fairly small and not too terribly relevant when push comes to shove.
Pretty much everything in this conversation is overstated and wrong in practice. And if you top off your playing smart-ass with your boss by being unable to explain what you did for the last year it shouldn't surprise you that your job security is fairly low. Most managers I've worked with liked predictability, liked stable progress, liked understanding what was done, what is being done, and what needs to be done. Learn how to communicate that in terms your boss can understand.
Cheers, - Andreas
A forwarded copy of that post follows:
On Tue, 17 Nov 2009 00:15:17 +0100, in comp.lang.smalltalk Guido Stepken gstepken@googlemail.com wrote: --8<---------------cut here---------------start------------->8--- Truth schrieb:
After watching http://railsconf.blip.tv/file/2089545/ I have to respond - somewhere. Smalltalk died of a hundred cuts.
Oh, yes, i really enjoyed watching this.
I think, smalltalk died a lack of communication what smalltalk really is:
Smalltalk is a 'reflection language' about and written in itself, represented by a bunch of - RAM floating - 'set of activities' - often miscalled 'objects', communicating like a neuronal network with itself and with its programmers, with the possibility to put/freeze that in a single file, called 'image'.
Just to make that a bit more transparent, here a (virtual) conversation between a decision maker and a Smalltalk programmer:
DM: "Please show me: What have you programmed last years? Where are your libraries? Where's your code contribution?"
- "Sorry, there are no libraries! We have source, yes! My code?
Somewhere within the spittoon of Smalltalk - code. There are no libraries. They're called 'image'. Can't say, what code i have contributed in the last years."
"Ok! And where's our data?"
- "Sorry, there is no data!"
"But there must be our data somewhere. Experts say and Oracle sais, we need a 'data warehouse'. We will have to put all our data into a central database!"
- "Sorry - we have no data, no code - we have 'objects'!"
"Ok. I understand. Can you store those 'objects' in Oracle?"
- "Hmmm. No! Does not make any sense."
"I understand. But all the other programmers say, of course, every programming language is about code and data and state variables!"
- "Sorry, no! Smalltalk is a different thing. We even don't have
'states'"
"Ok, I see, we have to change to Java or to C++ to get that mismatch solved."
- "There is no need to switch to other languages. We are quite
productive!"
"Ok, maybe. But the board of directors urge me to introduce a central 'data warehouse' on Oracle. Experts say, that's what all companies need nowadays!"
- "No need to introduce Oracle. We even can control a whole production
plant with Smalltalk! Statistics included. They're done on the fly."
"Without central data warehouse? Without Crystal Report, SPSS, Excel?"
- "Yes! I can simply code that into Smalltalk"
"But the other programmers say: 'Smalltalk is slow!' You even can't control a production plant with one single C++ programm! You need fast 'real time operating systems' and 'real time program language', all experts say that!"
- "Yes, Smalltalk is much slower. And Smalltalk is no 'real time
system'. But it works fine since many years!"
"Hmmm. Sounds very unrealistic! A whole production plant controlled by one pentium processor. Ridiculous! By the way: Does Smalltalk 'scale'?
- "Hmmm. No!"
"Our controlling sais - They need to do their own statistics on Crystal Report, SPSS, Excel. They want to make nice productivity charts! Can they get their own ODBC - Interface - secured by password - to access data within the 'Smalltalk Image'?"
- "Hmmm. No. There is no such interface. But i simply could add some
counting variables in Smalltalk."
"No, thanx. Our controlling uses sequel! We have paid a lot to teach them how to make nice production charts with Excel, CR, SPSS and POWERPOINT, of course! Now you say, the have to learn 'Smalltalk'? No! They are no programmers! They are controllers! They have to control you!
Ok. Conclusion: We probably run into many troubles, if we don't switch to a central data warehouse and a modern progamming language, that 'scales', like JAVA or C++. All experts say - we need central data warehouse, advanced controlling in production, near realtime statistics via ODBC-access, RT-OS.
By the way - Can you accellerate Smalltalk code by 'inline assembler', like in C++?"
- "Can you accelerate your brain by 'inline assembler'? Does it
scale?"
"You are fired!"
Just my 2ct.
Have fun,
Guido Stepken --8<---------------cut here---------------end--------------->8---
-- Benjamin L. Russell
I guess that what killed smalltalk is that it was too advanced for the time it started. That´s the same that happened to Lisp. Languages ahead of its time, great philosophies, fantastic tools for a programmer work, but way too advanced for its time.
2009/11/17 Benjamin L. Russell DekuDekuplex@yahoo.com
There was an interesting post on comp.lang.smalltalk which, although semi-off-topic (it concerns Smalltalk as a language, rather than Squeak as an implementation specifically), reveals some of the misunderstandings that many industry professionals have toward Smalltalk in general.
The main portion of the message consists of a "(virtual) conversation between a decision maker and a Smalltalk programmer." It seems that many of these misunderstandings (with the exception of the one related to speed, since Squeak is actually quite fast) relate to Squeak as well.
Any comments?
A forwarded copy of that post follows:
On Tue, 17 Nov 2009 00:15:17 +0100, in comp.lang.smalltalk Guido Stepken gstepken@googlemail.com wrote: --8<---------------cut here---------------start------------->8--- Truth schrieb:
After watching http://railsconf.blip.tv/file/2089545/ I have to respond - somewhere. Smalltalk died of a hundred cuts.
Oh, yes, i really enjoyed watching this.
I think, smalltalk died a lack of communication what smalltalk really is:
Smalltalk is a 'reflection language' about and written in itself, represented by a bunch of - RAM floating - 'set of activities' - often miscalled 'objects', communicating like a neuronal network with itself and with its programmers, with the possibility to put/freeze that in a single file, called 'image'.
Just to make that a bit more transparent, here a (virtual) conversation between a decision maker and a Smalltalk programmer:
DM: "Please show me: What have you programmed last years? Where are your libraries? Where's your code contribution?"
- "Sorry, there are no libraries! We have source, yes! My code?
Somewhere within the spittoon of Smalltalk - code. There are no libraries. They're called 'image'. Can't say, what code i have contributed in the last years."
"Ok! And where's our data?"
- "Sorry, there is no data!"
"But there must be our data somewhere. Experts say and Oracle sais, we need a 'data warehouse'. We will have to put all our data into a central database!"
- "Sorry - we have no data, no code - we have 'objects'!"
"Ok. I understand. Can you store those 'objects' in Oracle?"
- "Hmmm. No! Does not make any sense."
"I understand. But all the other programmers say, of course, every programming language is about code and data and state variables!"
- "Sorry, no! Smalltalk is a different thing. We even don't have
'states'"
"Ok, I see, we have to change to Java or to C++ to get that mismatch solved."
- "There is no need to switch to other languages. We are quite
productive!"
"Ok, maybe. But the board of directors urge me to introduce a central 'data warehouse' on Oracle. Experts say, that's what all companies need nowadays!"
- "No need to introduce Oracle. We even can control a whole production
plant with Smalltalk! Statistics included. They're done on the fly."
"Without central data warehouse? Without Crystal Report, SPSS, Excel?"
- "Yes! I can simply code that into Smalltalk"
"But the other programmers say: 'Smalltalk is slow!' You even can't control a production plant with one single C++ programm! You need fast 'real time operating systems' and 'real time program language', all experts say that!"
- "Yes, Smalltalk is much slower. And Smalltalk is no 'real time
system'. But it works fine since many years!"
"Hmmm. Sounds very unrealistic! A whole production plant controlled by one pentium processor. Ridiculous! By the way: Does Smalltalk 'scale'?
- "Hmmm. No!"
"Our controlling sais - They need to do their own statistics on Crystal Report, SPSS, Excel. They want to make nice productivity charts! Can they get their own ODBC - Interface - secured by password - to access data within the 'Smalltalk Image'?"
- "Hmmm. No. There is no such interface. But i simply could add some
counting variables in Smalltalk."
"No, thanx. Our controlling uses sequel! We have paid a lot to teach them how to make nice production charts with Excel, CR, SPSS and POWERPOINT, of course! Now you say, the have to learn 'Smalltalk'? No! They are no programmers! They are controllers! They have to control you!
Ok. Conclusion: We probably run into many troubles, if we don't switch to a central data warehouse and a modern progamming language, that 'scales', like JAVA or C++. All experts say - we need central data warehouse, advanced controlling in production, near realtime statistics via ODBC-access, RT-OS.
By the way - Can you accellerate Smalltalk code by 'inline assembler', like in C++?"
- "Can you accelerate your brain by 'inline assembler'? Does it
scale?"
"You are fired!"
Just my 2ct.
Have fun,
Guido Stepken --8<---------------cut here---------------end--------------->8---
-- Benjamin L. Russell
Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreterhttp://dekudekuplex.wordpress.com/%0ATranslator/Interpreter/ Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Smalltalk didn't die. It's growth was killed. The dream of taking over the world was killed. But there are still people making their living with Smalltalk. It is hard to find good Smalltalk jobs, but they exist.
I've always thought the main problem with Smalltalk was lack of marketing, in the broader sense. In 1995, when Java came out, there was no free Smalltalk that schools could use. I paid something like $3K per year for a site license for VisuaalWorks so I could teach with it, and few schools would do that. It was hard to find Smalltalk programmers, and their salaries were very high, and few schools taught it so companies would train their Cobol programmers in Smalltalk only to find them leaving for higher salaries. Smalltalk did not seem very well supported at all, and when the main Smalltalk company (ParcPlace) seemed to be taken over by dysfunctional pointy-haired managers, companies started to look for other alternatives. Java was their main choice, even though it was five years before it was good enough to build the same systems that they had been building in Smalltalk for a long time.
Things like non-C-like syntax and difficulty of calling C libraries were a part of the problem, but a minor part. I think the bigger issues were business ones. As usual. Technical people think that technology wins or loses because of technical reasons, but they are usually wrong. if you want your technology to win, study marketing and business.
I've been programming in Smalltalk since 1985. I remember 1995 as if it were yesterday.
-Ralph Johnson
On Wed, Nov 18, 2009 at 3:18 AM, Ralph Johnson johnson@cs.uiuc.edu wrote:
Smalltalk didn't die. It's growth was killed. The dream of taking over the world was killed.
+1. I use Smalltalk willingly, therefore it is not dead. It will only be dead when the last contributer stops enjoying it.
I believe the way to make Smalltalk popular is to make it do something that nobody else can that many people need. This is assuming that the basics are there: a good product, good documentation, support, etc.
I've been programming in Smalltalk since 1985. I remember 1995 as if
it were yesterday.
In 1985, some of the people in this community didn't exist!
Gulik.
Ralph Johnson johnson@cs.uiuc.edu:
Smalltalk didn't die. It's growth was killed. The dream of taking over the world was killed. But there are still people making their living with Smalltalk. It is hard to find good Smalltalk jobs, but they exist.
I actually made my living 1993-1995, programming Smalltalk.
beginners@lists.squeakfoundation.org