kirby urner wrote: > On 8/9/06, Arthur <[EMAIL PROTECTED]> wrote: > Yeah, because after years of OO in commerce and industry, it's not > this big elitist thing any more to have mastery of that jargon. > Smalltalkers were impressive, in their day and age, to the great > unwashed. But no longer. In and of itself, just knowing OO is not a > mark of anything special. Knowing a dead language implementation of > the paradigm is also not a turn on for young people.
While you can repeat "Smalltalk is a dead language" until as many people believe it as "Iraq had WMD" (i.e. too many :-), but Smalltalk remains quite a live language, thought smaller in adoption than many others and often a "secret weapon". http://www.cincomsmalltalk.com/blog/blogComments?entry=3331578947 "Old" might be more appropriate. :-) Or maybe, "mismanaged", or "less popular". Unfortunately (for me :-), general consulting rates have fallen for it from the heydays of the mid 90s when I did it commercially, as have the number of new gigs. Still, VisualWorks Smalltalk as a cross-platform stable environment useful for mission critical software where performance matters has never been surpassed IMHO (although Python comes closer every day, but will never match it for syntax reasons IMHO). While there are other Smalltalks, http://wiki.cs.uiuc.edu/VisualWorks/Overview+of+different+implementations+of+Smalltalk the flagships in the mid 1990s, mainly VisualWorks, and secondly Digitalk, determined much of the landscape. Hard to even remember what that landscape was like before so many free and open source projects became popular, like Python (but also CommonLisp variants, Ruby, Perl, even GCC, and so on). Rumor has it VisualWorks missed its biggest chance when Sun wanted to license it for their set top box work, and PPD wanted too much in run-time fees, and so Sun turned to what became Java instead. The chance not being to make money from Sun, but instead to have forestalled the development of Java. Short-sighted greed. Sigh. If VisualWorks had been open sourced instead of sold for a song to Cincom, I maintain ParcPlace/Digitalk/ObjectShare might still be a going concern with consulting, the way, say, the Zope Corp is. And surprise, I (and others) advocated that in 1999. :-) See my post here: http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/3b3a67ab0ab756e0/6d08b70aa9f6aea1?lnk=st&q=&rnum=1&hl=en#6d08b70aa9f6aea1 One snippet of my post there back in 1999 (which also pertains to Python): =================== "Because of these factors, I think there is much residual anger at ObjectShare. After all, it is unpleasant to think about how the most advanced development tool and OO language on the planet has been mismanaged and mismarketed into relative obscurity over the past twenty years. It has caused real suffering to programmers forced to take work in other (painful) languages like C++ or Java or VB. Nonetheless, Smalltalk is still in my opinion the best OO language (although Python is easier to learn for C/C++ coders and more modular). I've been having more success lately getting people to consider Python for places where Smalltalk might be the better tool and price is not a factor. The reason for this has to do with the license and availability of source (and smaller download footprint). It also (sadly) has to do with it looking like C (although I see no reason Python could not run on a Smalltalk VM as a combines Smalltalk/Python product).(*) It also has something to do with the community surrounding Python. This is a bunch of people who are using Python every day in mission critical applications (like web servers, data reformatting, spacecraft launch operations, industrial facilities, and complex simulations). They make sure it works, and have a great set of add-ons. This is all enhanced by the fact that Python supports modules well (each with its own namespace). Squeak has much potential, but is not used as much (at all?) in mission critical applications. It also has a license that makes it awkward to use in embedded systems (GPL actually is better in that respect). VW NC has potential, but will forever be hampered by not being a completely open solution (unlike Squeak or Python). The same thing happened with the ST/V free release, where without an open VM, interest in working with it has been marginal (compared to Squeak). I think it will be difficult if not impossible for ObjectShare to overcome this two decade legacy by conventional marketing tactics. A name change is not sufficient. My suggesting to ObjectShare is that since the bulk of their revenues (73%) is now from service, make VisualWorks open source under a Python-like license. http://www.opensource.org Then users will be assured of indefinite support of the product. Source code escrow as many big users have is not adequate because no one at a client's staff can keep current with the source. ObjectShare will be in a great position to increase its service revenue, and achieve growth and investors like Red Hat. Right now, VW has a huge support burden by being multi-platform (keeping engineering expertise available for all those ports). An open source VW will remove a huge cost for ObjectShare, as well as result in more ports to other systems, all increasing the value of the ObjectShare brand for services and custom development. " ================== Well, too bad ParcPlace/Digitalk/ObjectShare did not follow that advice and chose to go out of business instead. http://wiki.cs.uiuc.edu/VisualWorks/ObjectShare Cincom (the purchaser of the VisualWorks asset) benefited from that decision, as likely did their customers, though I think in balance the Smalltalk community as a whole suffered. As I see it, the Smalltalk community wanted (and still wants) an open source "VisualWorks" which was cross-platform and stable enough to build neat stuff on (including the in 1999 under development "Van Gogh" system, a native widget integration portable across Windows, Mac OS and X Windows/UNIX). But what they got was an antiquated and problematically-licensed Squeak with various limitations and instabilities (which the Squeak community is still struggling with, although admirably succeeding anyway). Squeak unfortunately diverted attention from the truly free GNU Smalltalk which was both better engineered and better licensed IMHO, and which otherwise might have gone a lot further without Squeak and Disney stealing the limelight. So anyway, if Smalltalk is a "wounded" language, I'd say it has little to do with the language or leading (proprietary) implementations, and more to do with mismanagement and missing the "open source" wave by the key players. And with several commercial versions out there, a free versions had a harder time getting traction. Python defined itself, and was always free, so in that sense, the Python community never had a diversion of attention the Smalltalk community did. Anyway, I don't want to drift too far off-topic. Suffice to say, if there is any truth to Smalltalk being a "dead" language, it has more to do with companies mismanaging the technology, and not the technology itself. Python has been well managed as a labor-of-love by someone who cares about it for itself (Guido) and as a community Python could ride the free and open source software wave without distracting conflicts with "commercial Python vendors". Squeak tried, but was both a latecomer and not completely free, and had some other difficulties (including for a long time a core team with priorities other than stability or supporting industrial use). So, for those reasons, I think it quite valid for Python people to look to Smalltalk and its successors (like Self) for ideas, both about technology and about education -- even if one accepts that a new free stand-alone Smalltalk (even a better Squeak, and even if pushed by an entity with deep pockets) will have a tough climb gaining adoption at this point in time. And in my own case, the commercial viability of Python (i.e. because it is free, has a Java version, looks a lot like C, etc.) also makes it of value to learn and use for consulting because at the same time it is "not too shabby" a system. :-) And similar factors make Python a good language for people to teach with -- both easy to get started with and potentially a useful job skill. I think the one thing that might resurrect Smalltalk in widespread popularity is a "killer app" which is open ended and scriptable. Croquet may well be that. So we'll have to see. For me, when I went to port Squeak to the Newton (never finished for a variety of reasons) http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-June/002775.html what happened was that I discovered NewtonScript instead and became enamored of the Prototype-oriented NewtonScript programming I was doing to try to support porting a Class-oriented Squeak system (NewtonScript was an offspring of Self), and I have been dissatisfied with plain Smalltalk and classes ever since. :-) And that dissatisfaction flows over to a dissatisfaction with Python with classes, which PataPata has been an experiment to see if a prototype programming paradigm is a good idea in a Python setting. Anyway, I think I've said enough on this for now, so back to programming. I have a (limited, quirky, experimental) Smalltalk parser and interpreter and related (wx) development tools I wrote in Python in 2004 lying around on my hard disk, and with this discussion I'm thinking of adding it to PataPata just for fun. It generated Pointrel triads for a backend (quirky, but my thing) and I'm experimenting with changing it over to spitting out Python code. And example of its output from today: =========================================== |x y z| x := 1. y := 0.5. z := x sin + y cos; rounded + 1.0 sin; rounded. ------------------------------------------- x = LiteralNumber(1) y = LiteralNumber(0.5) _t1 = send_unary(x, "sin") _t2 = send_unary(y, "cos") _t3 = send_unary(y, "rounded") _t4 = send_binary(_t1, "+", _t3) _t5 = send_unary(LiteralNumber(1.0), "sin") _t6 = send_unary(LiteralNumber(1.0), "rounded") z = send_binary(_t4, "+", _t6) return z =========================================== Not sure if I will proceed on integrating that or not. It's not going to be that well performing of course, but perhaps might be useful for learning Smalltalk syntax on the Python platform. Might not be that bad under Jython if it some day compiled Smalltalk to Java source or bytecodes though, although there is already Bistro for that: http://www.ddj.com/dept/java/184405578 But Jython and Self-like hybrid on the JVM with 3D etc. might make a nice synergy. Jython to suck people in and Smalltalk-ish syntax and tools to do really big projects in. :-) Here is something I wrote on that in 1996 (was that really ten years ago? my how time flies). "Squeak and the Babel of programming languages" http://www.create.ucsb.edu/squeak/9612.html#Letter94 So perhaps it might be possible to rethink that now with Python or Jython playing the coordinating role and delivering the core object model and VM interface. On the other hand, this dialog here over the past few months has made it clear how languages are very tied to communities (and libraries), so just learning the syntax or how to use it under another system may not be popular (except as a mind stretching exercise). Still, "mind stretching" is what a lot of education is about. :-) --Paul Fernhout (*) In 2004, L. Peter Deutsch worked on Python on VisualWorks as "pycore": http://webpages.charter.net/allanms/2004/08/you-dont-tug-on-supermans-cape.html _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
