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. Em 07/12/2010 15:57, Sean P. DeNigris < sean@clipperadams.com > escreveu: This is fun! Thanks for the discussion... csrabak wrote:
Sean, once you really get to metal subtleties and other nuances on the language and syntax appear to bug your team. Have you ever heard of John McSweeney's "Smalltalk âTrapsâ" piece¹?
[ sean isOnChair ] whileTrue: [ sean laugh ]. 7 pages! (actually 6.5 - with embedded images) That actually proves my point vs. entire textbooks ;-) Not to mention that: * the first page and a half's examples are trivial and not exactly "traps" (the fact that self is implicitly returned) * the "10 + (10 negated) negated" "trap" executes intuitively and correctly in Squeak * the example of changing a loop while iterating with do: seems like C++ code translated literally into Smalltalk * the last 1.5 pages are totally contrived (and use global variables which are discouraged anyway; I haven't had to use one yet) - yes, if you *want* to screw up the system, you can: #right basicAt: 1 put: 119; basicAt: 2 put: 114; basicAt: 3 put: 111; basicAt: 4 put: 110; basicAt: 5 put: 103. #right An equivalent argument is: if you hit your laptop repeatedly with a bat, it will not work regardless of what programming language you were using, so you might as well pick any csrabak wrote:
Well, comparing C, even C++ which normally hasn't automatic garbage collection, is somewhat stretching the argument...
Well, that's just the point, isn't it? We're talking about language popularity and those are #2 and #3 on the TIOBE index. csrabak wrote:
even with those "idiosyncrasies" as soon the size of the application grows up, these perks of Smalltalk quickly become less noticeable
I've been using Smalltalk for less than a year, but I'm already more productive by far than in C, C++, or even Ruby, and haven't hit that limit writing software for small businesses. If there is a size at which the benefit lessens, isn't it more likely caused by poor design/devs or any number of factors (don't most large projects fail)? It can't be the same or worse to use a poor library in a dynamic live environment. I recently wrote a simple Ruby bridge and found it liberating to deal with the library in the Smalltalk tools rather than in Ruby's code/run cycle. csrabak wrote:
Smalltalk... programmers attention to avoid the attribution of wrong objects to instance variables as there is no type checking...
I have never encountered this and I've often heard it said by dynamic language experts to be mostly static language paranoia. What is the evidence that this becomes a severe problem in real-life dynamic systems? Sean -- View this message in context: http://forum.world.st/Popularity-or-not-of-smalltalk-tp3073990p3076885.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.