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 <[hidden email]> 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/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
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 <[hidden email]> 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 _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by 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 <[hidden email]> There was an interesting post on comp.lang.smalltalk which, although -- André de Camargo Fernandes _______________________________________________ Beginners mailing list [hidden email] 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 _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
On Wed, Nov 18, 2009 at 3:18 AM, Ralph Johnson <[hidden email]> wrote: Smalltalk didn't die. It's growth was killed. The dream of taking +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 In 1985, some of the people in this community didn't exist! Gulik. -- http://gulik.pbwiki.com/ _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by Benjamin L. Russell
That's right. Smalltalk hasn't died. I am fortunate enough to be part of a team developing financial software for many years using Smalltalk.
People have predicted Smalltalk's death about as often as Apple's death. I think comparisons between Smalltalk and Java have to take marketing into account. Paying Smalltalk work is harder to find. Here's an interesting twist. Companies looking for skilled Object Oriented developers, if they understand what they need, will seek programmers with Smalltalk experience. - Steve On Nov 17, 2009, at 8:18 AM, Ralph Johnson <[hidden email]> wrote: 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 _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
On 18.11.2009, at 13:41, Steve Wessels wrote:
> > That's right. Smalltalk hasn't died. I am fortunate enough to be part of a team developing financial software for many years using Smalltalk. > > People have predicted Smalltalk's death about as often as Apple's death. > > I think comparisons between Smalltalk and Java have to take marketing into account. > > Paying Smalltalk work is harder to find. Here's an interesting twist. Companies looking for skilled Object Oriented developers, if they understand what they need, will seek programmers with Smalltalk experience. > > - Steve To what extent do you think the following applies (in reverse) to Smalltalk? "If you program in the most popular programming language, your skill in that particular language is a commodity. If you program only in the most popular programming language, you have made yourself a commodity. A commodity can only compete on location and price, and location doesn't really get you much on the Internet. This means that only people with a poor understanding of economics program in [the most popular programming language]." (http://gilesbowkett.blogspot.com/2009/01/why-hacker-news-thinks-php-won.html) - Bert - _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Steve Wessels wrote:
> That's right. Smalltalk hasn't died. I am fortunate enough to be part of a team developing financial software for many years using Smalltalk. > > People have predicted Smalltalk's death about as often as Apple's death. > > I think comparisons between Smalltalk and Java have to take marketing into account. > > Paying Smalltalk work is harder to find. Here's an interesting twist. Companies looking for skilled Object Oriented developers, if they understand what they need, will seek programmers with Smalltalk experience. > > Speaking as a long-term script kiddie who likes to collect languages, I can tell you that the main reason(s) why *I* find Smalltalk difficult to use involve(s): lack of documentation, lack of well-documented example code, lack of compsci teaching materials written with Smalltalk for the example code, etc. Notice a trend? Smalltalk may have been designed to be easy to learn and use, but it has never been adopted by the pedagogical community of teachers and how-to book-writers, so naturally new programmers (from whom experienced programmers grow) are never attracted to it. The main issue is lack of ways for new programmers (experienced in other languages or otherwise) to learn not just the syntax of the language, but how to DO stuff with it. E.G.: I can't grab the Unix Programming or Unix Network Programming books by Stevens and work through Smalltalk equivalents of the example code. There's no Data Structures in Smalltalk books, nor Algorithm Analysis in Smalltalk books, nor build your own virtual world from scratch using Smalltalk and OpenGL, or Game AI in Smalltalk, or... There IS a Numerical Methods book in Smalltalk, but that's hardly beginner/intermediate level, IMHO. You get the idea. All the reference material for Smalltalk is geared for complete beginners, or for people who are exceedingly experienced. No middle ground. And some of the most interesting (sounding) aspects of Smalltalk, such as the Teatime architecture, are hardly covered in ways that relative newcomers can understand (speaking as a relative newcomer with a 2 year AAS degree and a couple decades intermittent experience programming). Smalltalk (e.g. Squeak) may not be fast enough to be used in high-end production implementations, but surely it could be the language-of-choice for learning new aspects of compsci and programming. After all, many of these "new aspects" of compsci and programming were originally developed/matured using Smalltalk. Why should people have to go to a less versatile language in order to actually learn to use the results of Smalltalk-based research? Lawson _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
I agree 100% It seems like most of the documentation is a tutorial or
example but not a straight forward explanation of how to use it. Everything ends up being trial and error. I enjoy the language very much and would be tempted to use it again but realistically a good comprehensive guide would be great. Also, a nice document that describes each class and its methods (beyond just the comments included in the class definite itself) would be a huge help. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Lawson English Sent: Sunday, November 22, 2009 8:20 PM To: A friendly place to get answers to even the most basic questions about Squeak. Subject: Re: [Newbies] [semi-OT] (fwd) Re: What Killed Smalltalk? Steve Wessels wrote: > That's right. Smalltalk hasn't died. I am fortunate enough to be part of a team developing financial software for many years using Smalltalk. > > People have predicted Smalltalk's death about as often as Apple's death. > > I think comparisons between Smalltalk and Java have to take marketing into account. > > Paying Smalltalk work is harder to find. Here's an interesting twist. Companies looking for skilled Object Oriented developers, if they understand what they need, will seek programmers with Smalltalk experience. > > Speaking as a long-term script kiddie who likes to collect languages, I can tell you that the main reason(s) why *I* find Smalltalk difficult to use involve(s): lack of documentation, lack of well-documented example code, lack of compsci teaching materials written with Smalltalk for the example code, etc. Notice a trend? Smalltalk may have been designed to be easy to learn and use, but it has never been adopted by the pedagogical community of teachers and how-to book-writers, so naturally new programmers (from whom experienced programmers grow) are never attracted to it. The main issue is lack of ways for new programmers (experienced in other languages or otherwise) to learn not just the syntax of the language, but how to DO stuff with it. E.G.: I can't grab the Unix Programming or Unix Network Programming books by Stevens and work through Smalltalk equivalents of the example code. There's no Data Structures in Smalltalk books, nor Algorithm Analysis in Smalltalk books, nor build your own virtual world from scratch using Smalltalk and OpenGL, or Game AI in Smalltalk, or... There IS a Numerical Methods book in Smalltalk, but that's hardly beginner/intermediate level, IMHO. You get the idea. All the reference material for Smalltalk is geared for complete beginners, or for people who are exceedingly experienced. No middle ground. And some of the most interesting (sounding) aspects of Smalltalk, such as the Teatime architecture, are hardly covered in ways that relative newcomers can understand (speaking as a relative newcomer with a 2 year AAS degree and a couple decades intermittent experience programming). Smalltalk (e.g. Squeak) may not be fast enough to be used in high-end production implementations, but surely it could be the language-of-choice for learning new aspects of compsci and programming. After all, many of these "new aspects" of compsci and programming were originally developed/matured using Smalltalk. Why should people have to go to a less versatile language in order to actually learn to use the results of Smalltalk-based research? Lawson _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by Benjamin L. Russell
Squeak by Example is a great place to start, and it is free. After that, An Introduction to Seaside is very good. The Design Patterns Smalltalk Companion puts now-commonplace concepts into context. Chamond Liu's book is also very good. Then for some polish, check Kent Beck's Smalltalk Best Practice Patterns.
cheers, tim -original message- Subject: RE: [Newbies] [semi-OT] (fwd) Re: What Killed Smalltalk? From: Christine Wolfe <[hidden email]> Date: 11/22/2009 9:31 PM I agree 100% It seems like most of the documentation is a tutorial or example but not a straight forward explanation of how to use it. Everything ends up being trial and error. I enjoy the language very much and would be tempted to use it again but realistically a good comprehensive guide would be great. Also, a nice document that describes each class and its methods (beyond just the comments included in the class definite itself) would be a huge help. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Lawson English Sent: Sunday, November 22, 2009 8:20 PM To: A friendly place to get answers to even the most basic questions about Squeak. Subject: Re: [Newbies] [semi-OT] (fwd) Re: What Killed Smalltalk? Steve Wessels wrote: > That's right. Smalltalk hasn't died. I am fortunate enough to be part of a team developing financial software for many years using Smalltalk. > > People have predicted Smalltalk's death about as often as Apple's death. > > I think comparisons between Smalltalk and Java have to take marketing into account. > > Paying Smalltalk work is harder to find. Here's an interesting twist. Companies looking for skilled Object Oriented developers, if they understand what they need, will seek programmers with Smalltalk experience. > > Speaking as a long-term script kiddie who likes to collect languages, I can tell you that the main reason(s) why *I* find Smalltalk difficult to use involve(s): lack of documentation, lack of well-documented example code, lack of compsci teaching materials written with Smalltalk for the example code, etc. Notice a trend? Smalltalk may have been designed to be easy to learn and use, but it has never been adopted by the pedagogical community of teachers and how-to book-writers, so naturally new programmers (from whom experienced programmers grow) are never attracted to it. The main issue is lack of ways for new programmers (experienced in other languages or otherwise) to learn not just the syntax of the language, but how to DO stuff with it. E.G.: I can't grab the Unix Programming or Unix Network Programming books by Stevens and work through Smalltalk equivalents of the example code. There's no Data Structures in Smalltalk books, nor Algorithm Analysis in Smalltalk books, nor build your own virtual world from scratch using Smalltalk and OpenGL, or Game AI in Smalltalk, or... There IS a Numerical Methods book in Smalltalk, but that's hardly beginner/intermediate level, IMHO. You get the idea. All the reference material for Smalltalk is geared for complete beginners, or for people who are exceedingly experienced. No middle ground. And some of the most interesting (sounding) aspects of Smalltalk, such as the Teatime architecture, are hardly covered in ways that relative newcomers can understand (speaking as a relative newcomer with a 2 year AAS degree and a couple decades intermittent experience programming). Smalltalk (e.g. Squeak) may not be fast enough to be used in high-end production implementations, but surely it could be the language-of-choice for learning new aspects of compsci and programming. After all, many of these "new aspects" of compsci and programming were originally developed/matured using Smalltalk. Why should people have to go to a less versatile language in order to actually learn to use the results of Smalltalk-based research? Lawson _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
All true, but, as I said, there are assumptions: Squeak/Pharo By Example
is for total newcomers to programming, or for very experienced programmers looking for a fast intro where they can "read between the lines" for intermediate/advanced info. Design Patterns is hardly intermediate either, I haven't seen Chamon Liu's book. BUT, where are the books/tutorials/material to show you how to go a step beyond SbyE's Morphic discussion? how to make a simpleSliderMorph move another morph across the screen isn't immediately obvious, for example. a simple drawing app example doesn't seem to exist. the various advanced technologies that Squeak et al. use are not accessible to the newcomer, regardless of experience, at least IMHO. The Seaside book is geared towards people with a great deal of web programming experience. Most people with a great deal of web programming experience aren't attracted to relatively unused technologies, and newcomers to web programming have a hard time understanding how to accomplish things using Seaside because they don't know how to accomplish anything web-programming related yet. There is no Squeak equivalent of the Python Cookbook targeted at the same level that the Python book is targeted at. Likewise, the discussions of Squeak's libraries assume experience experience far beyond what Python's library documentation assumes or assume no experience at all. Etc. The point is that if you want Smalltalk to be used, you have to make available the same type and level of teaching materials that other, more popular, languages have available. L. Tim Johnson wrote: > Squeak by Example is a great place to start, and it is free. After that, An Introduction to Seaside is very good. The Design Patterns Smalltalk Companion puts now-commonplace concepts into context. Chamond Liu's book is also very good. Then for some polish, check Kent Beck's Smalltalk Best Practice Patterns. > > cheers, > tim > > -original message- > Subject: RE: [Newbies] [semi-OT] (fwd) Re: What Killed Smalltalk? > From: Christine Wolfe <[hidden email]> > Date: 11/22/2009 9:31 PM > > I agree 100% It seems like most of the documentation is a tutorial or > example but not a straight forward explanation of how to use it. Everything > ends up being trial and error. I enjoy the language very much and would be > tempted to use it again but realistically a good comprehensive guide would > be great. Also, a nice document that describes each class and its methods > (beyond just the comments included in the class definite itself) would be a > huge help. > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Lawson > English > Sent: Sunday, November 22, 2009 8:20 PM > To: A friendly place to get answers to even the most basic questions about > Squeak. > Subject: Re: [Newbies] [semi-OT] (fwd) Re: What Killed Smalltalk? > > Steve Wessels wrote: > >> That's right. Smalltalk hasn't died. I am fortunate enough to be part of >> > a team developing financial software for many years using Smalltalk. > >> People have predicted Smalltalk's death about as often as Apple's death. >> >> I think comparisons between Smalltalk and Java have to take marketing into >> > account. > >> Paying Smalltalk work is harder to find. Here's an interesting twist. >> > Companies looking for skilled Object Oriented developers, if they understand > what they need, will seek programmers with Smalltalk experience. > >> >> > > Speaking as a long-term script kiddie who likes to collect languages, I > can tell you that the main reason(s) why *I* find Smalltalk difficult to > use involve(s): lack of documentation, lack of well-documented example > code, lack of compsci teaching materials written with Smalltalk for the > example code, etc. Notice a trend? > > Smalltalk may have been designed to be easy to learn and use, but it has > never been adopted by the pedagogical community of teachers and how-to > book-writers, so naturally new programmers (from whom experienced > programmers grow) are never attracted to it. > > The main issue is lack of ways for new programmers (experienced in other > languages or otherwise) to learn not just the syntax of the language, > but how to DO stuff with it. > > E.G.: I can't grab the Unix Programming or Unix Network Programming > books by Stevens and work through Smalltalk equivalents of the example > code. There's no Data Structures in Smalltalk books, nor Algorithm > Analysis in Smalltalk books, nor build your own virtual world from > scratch using Smalltalk and OpenGL, or Game AI in Smalltalk, or... There > IS a Numerical Methods book in Smalltalk, but that's hardly > beginner/intermediate level, IMHO. > > You get the idea. All the reference material for Smalltalk is geared for > complete beginners, or for people who are exceedingly experienced. No > middle ground. > > > And some of the most interesting (sounding) aspects of Smalltalk, such > as the Teatime architecture, are hardly covered in ways that relative > newcomers can understand (speaking as a relative newcomer with a 2 year > AAS degree and a couple decades intermittent experience programming). > > Smalltalk (e.g. Squeak) may not be fast enough to be used in high-end > production implementations, but surely it could be the > language-of-choice for learning new aspects of compsci and programming. > After all, many of these "new aspects" of compsci and programming were > originally developed/matured using Smalltalk. Why should people have to > go to a less versatile language in order to actually learn to use the > results of Smalltalk-based research? > > > > Lawson > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners > > _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by LawsonEnglish
On Sun, Nov 22, 2009 at 5:19 PM, Lawson English <[hidden email]> wrote:
When I first encountered Smalltalk, it was through the course material for CS 497 and Ralph Johnson was the instructor. It was an intermediate undergraduate and graduate course on object oriented programming (OOP). Thus, it wasn't a course for the entry level computer science student but it should have been because I learned more in this course than any of my other computer science courses. The course used the following textbooks:
Design Patterns by Ralph Johnson et al Smalltalk Best Practice Patterns by Kent Beck Design Patterns: The Smalltalk Companion by Alpert et al (optional but well worth it) At this time, Ralph Johnson makes the course notes available online as well as videos of some of the lectures. One of the most important things that learned from this course was about be resourceful. Next, I prefer using VisualWorks Smalltalk and they have
some of the best documentation that you'll find and this includes many screencasts created by James Robertson. Smalltalk may have been designed to be easy to learn and use, but it has never been adopted by the pedagogical community of teachers and how-to book-writers, so naturally new programmers (from whom experienced programmers grow) are never attracted to it. I agree with you 100% that they are not enough how-to books out there. It would be nice to see the following O'Reilly titles on the books shelves: Learning Smalltalk
Smalltalk Cookbook The Smalltalk Programming Language I feel that these three titles would set the tone for other books to following. The main issue is lack of ways for new programmers (experienced in other languages or otherwise) to learn not just the syntax of the language, but how to DO stuff with it. I would have to disagree with the above statement because Smalltalk has excellent support for data structures by using their various collection classes. For example, Set Bag Array Interval OrderedCollection SortedCollection LinkedList Dictionary If the above doesn't fit your needs, then you can get yourself a copy of "Introduction to Computer Algorithms" by Cormen at al, one of the best books that you'll find on the subject, and implement the data structures you need by converting the psuedo code to Smalltalk following the collection semantics of the Smalltalk collections. Next, if you need to do stuff with OpenGL, there's a reference for it and many Smalltalk environment support a Smalltalk binding for it. OpenGL is OpenGL no matter which language you choose to use but it will have a different looking language API for interacting with it. Thus, you'll need to familiarize yourself with the environments API. In school, I also spent much time in the VR lab and most of the libraries were C/C++ based but it should be a straight forward process to create a Smalltalk language binding for it as well. In short, you can leverage the existing
de facto libraries out there in C based languages and access them from Smalltalk API. You get the idea. All the reference material for Smalltalk is geared for complete beginners, or for people who are exceedingly experienced. No middle ground. The one quality about being resourceful is being able to ask questions. Thus, if you have a question about something that pertains to Smalltalk, please feel free to post to the mailing list.
And some of the most interesting (sounding) aspects of Smalltalk, such as the Teatime architecture, are hardly covered in ways that relative newcomers can understand (speaking as a relative newcomer with a 2 year AAS degree and a couple decades intermittent experience programming). Smalltalk (e.g. Squeak) may not be fast enough to be used in high-end production implementations, but surely it could be the language-of-choice for learning new aspects of compsci and programming. After all, many of these "new aspects" of compsci and programming were originally developed/matured using Smalltalk. Why should people have to go to a less versatile language in order to actually learn to use the results of Smalltalk-based research? Smalltalk is a general purpose object oriented programming language that began its existence in the research lab. However, it's fast enough to be used in high-production system deployments. I'll let you look up the high profile companies that are using Smalltalk. The important point here is to not feel that you need to write everything in pure Smalltalk but instead leverage other technologies to reach your architectural goals.
Just my 2 cents, -Conrad
_______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Conrad Taylor wrote:
> On Sun, Nov 22, 2009 at 5:19 PM, Lawson English <[hidden email] > <mailto:[hidden email]>> wrote: > > Steve Wessels wrote: > > That's right. Smalltalk hasn't died. I am fortunate enough > to be part of a team developing financial software for many > years using Smalltalk. > > People have predicted Smalltalk's death about as often as > Apple's death. > > I think comparisons between Smalltalk and Java have to take > marketing into account. > > Paying Smalltalk work is harder to find. Here's an > interesting twist. Companies looking for skilled Object > Oriented developers, if they understand what they need, will > seek programmers with Smalltalk experience. > > > > > Speaking as a long-term script kiddie who likes to collect > languages, I can tell you that the main reason(s) why *I* find > Smalltalk difficult to use involve(s): lack of documentation, lack > of well-documented example code, lack of compsci teaching > materials written with Smalltalk for the example code, etc. Notice > a trend? > > > When I first encountered Smalltalk, it was through the course material > for CS 497 and Ralph Johnson was the instructor. It was an > intermediate undergraduate and graduate course on object oriented > programming (OOP). Thus, it wasn't a course for the entry level > computer science student but it should have been because I learned > more in this course than any of my other computer science courses. > The course used the following textbooks: > > Design Patterns by Ralph Johnson et al > Smalltalk Best Practice Patterns by Kent Beck > Design Patterns: The Smalltalk Companion by Alpert et al (optional > but well worth it) I tried to find that course. The video links still exist, but the videos themselves seem to be offline. Darn. Lawson _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by Ralph Johnson
>>>>> Ralph Johnson <[hidden email]>:
> 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 mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by LawsonEnglish
To continue and extend my rant in response to this thread, here are
examples of Books I'd Like to See for Squeak/Pharo: Books like these: http://www.greenteapress.com/semaphores/downey05semaphores.pdf http://www.greenteapress.com/compmod/ http://beej.us/guide/bgnet/ Articles like these: http://www.amk.ca/python/howto/sockets/ http://nehe.gamedev.net/ http://rubylearning.com/satishtalim/ruby_threads.html and http://rubylearning.com/satishtalim/ruby_socket_programming.html http://www.boddie.org.uk/python/XML_intro.html interfaces like these: http://www.spiderland.org/ etc. Without these kinds of materials available specifically oriented towards squeak/pharo use, your average beginning/intermediate programmer is NOT going to find squeak/pharo all that attractive. Another area lacking (where squeak should shine above all others) is in the voice-over demo/tutorial on youtube arena. A youtube video of VNC-based pair-programming on a beginning/intermediate level problem using squeak could be very compelling, I think. This would be the poor man's version of my idea about a web-cast of a live pair-programming session. Actually doing the live webcast, complete with mutli-channel chat/feedback/comments/questions and then making it available the way Metanomics interviews are, would be a very good teaching/marketing tool for Smalltalk. A primitive example of this is found about 2 minutes into this science friday video: http://www.youtube.com/watch?v=4fWPwOLJFA8 People have devised web-page playback of the video synced with the local chat discussion without the distracting superposition of the text chat on top of the video image, which could be very useful in a teachingseminar context, I believe. Lawson Lawson English wrote: > Steve Wessels wrote: >> That's right. Smalltalk hasn't died. I am fortunate enough to be >> part of a team developing financial software for many years using >> Smalltalk. >> >> People have predicted Smalltalk's death about as often as Apple's death. >> >> I think comparisons between Smalltalk and Java have to take marketing >> into account. >> >> Paying Smalltalk work is harder to find. Here's an interesting >> twist. Companies looking for skilled Object Oriented developers, if >> they understand what they need, will seek programmers with Smalltalk >> experience. >> >> > > Speaking as a long-term script kiddie who likes to collect languages, > I can tell you that the main reason(s) why *I* find Smalltalk > difficult to use involve(s): lack of documentation, lack of > well-documented example code, lack of compsci teaching materials > written with Smalltalk for the example code, etc. Notice a trend? > > Smalltalk may have been designed to be easy to learn and use, but it > has never been adopted by the pedagogical community of teachers and > how-to book-writers, so naturally new programmers (from whom > experienced programmers grow) are never attracted to it. > > The main issue is lack of ways for new programmers (experienced in > other languages or otherwise) to learn not just the syntax of the > language, but how to DO stuff with it. > > E.G.: I can't grab the Unix Programming or Unix Network Programming > books by Stevens and work through Smalltalk equivalents of the example > code. There's no Data Structures in Smalltalk books, nor Algorithm > Analysis in Smalltalk books, nor build your own virtual world from > scratch using Smalltalk and OpenGL, or Game AI in Smalltalk, or... > There IS a Numerical Methods book in Smalltalk, but that's hardly > beginner/intermediate level, IMHO. > > You get the idea. All the reference material for Smalltalk is geared > for complete beginners, or for people who are exceedingly experienced. > No middle ground. > > > And some of the most interesting (sounding) aspects of Smalltalk, such > as the Teatime architecture, are hardly covered in ways that relative > newcomers can understand (speaking as a relative newcomer with a 2 > year AAS degree and a couple decades intermittent experience > programming). > > Smalltalk (e.g. Squeak) may not be fast enough to be used in high-end > production implementations, but surely it could be the > language-of-choice for learning new aspects of compsci and > programming. After all, many of these "new aspects" of compsci and > programming were originally developed/matured using Smalltalk. Why > should people have to go to a less versatile language in order to > actually learn to use the results of Smalltalk-based research? > > > > Lawson > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners > _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
2009/12/12 Lawson English <[hidden email]>:
> To continue and extend my rant in response to this thread, here are examples > of Books I'd Like to See for Squeak/Pharo: [examples snipped] > Without these kinds of materials available specifically oriented towards > squeak/pharo use, your average beginning/intermediate programmer is NOT > going to find squeak/pharo all that attractive. For what it's worth, the only one of those that would be of the remotest interest to me would be the XML one. I think you're falling into the trap of thinking everybody is programming the same sorts of systems that you are. -- Tim Rowe _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Free forum by Nabble | Edit this page |