15 ms·

What Killed Smalltalk?

104 points by Garbage 11y ago

acqq 11y ago
> Not everything has to have a visual metaphor. This is again a case of pushing some idealistic principle too far, in my opinion. True. But, for example, GNU Smalltalk doesn't need GUI? https://www.gnu.org/software/smalltalk/manual/html_node/Tutorial.html https://www.gnu.org/software/smalltalk/manual/html_node/Tuto... One maintained Smalltalk implementation with GUI that can be tried: http://squeak.org/ http://squeak.org/ "Squeak is an open-source Smalltalk programming system with fast execution environments for all major platforms. It features the Morphic framework, which promotes low effort graphical, interactive application development and maintenance." For other opinions about the death of Smalltalk, there was a link to c2 resources called WhyIsSmalltalkDead on the HN just 4 days ago: https://news.ycombinator.com/item?id=10071681 https://news.ycombinator.com/item?id=10071681 What I certainly agree is that the successful language has to be able to interact with as much as possible on the host system, as efficient and as flexible. Note that we still use Fortran code, for example, for numeric libraries https://en.wikipedia.org/wiki/LAPACK https://en.wikipedia.org/wiki/LAPACK and that C easily links and calls Fortran routines.
- detaro 11y ago
  You can run squeak in the browser: http://bertfreudenberg.github.io/SqueakJS/ http://bertfreudenberg.github.io/SqueakJS/ Another one is http://pharo.org/ http://pharo.org/ (haven't tried it) But I've worked with Squeak quite a bit in university, and the consensus generally was: The language is really nice, and a joy to use for many things. The environment is awful and makes working with it a pain, and since everything is integrated so closely there are no obvious ways around that.
- bfung 11y ago
  Doesn't seem as dead as the article suggests. In addition to squeak: http://pharo.org/ http://pharo.org/ http://www.strongtalk.org/ http://www.strongtalk.org/ One of the more impressive things I've seen in the past (like 5 years ago?) was DabbleDB (https://en.wikipedia.org/wiki/Dabble_DB https://en.wikipedia.org/wiki/Dabble_DB), also written in smalltalk (the company / app was acquired, see https://news.ycombinator.com/user?id=avibryant https://news.ycombinator.com/user?id=avibryant)
- david-given 11y ago
  Also see Amber, which is not technically a Smalltalk but fakes it very convincingly. It runs in a web browser, compiling to Javascript. http://amber-lang.net/ http://amber-lang.net/ Load up that page and press the button, and a Smalltalk IDE will pop up for you to play with. (It sounds like an amazing way to write web apps, actually, as it supports writing changes back to the server; but the backend infrastructure is heavier-weight than I'm happy with.)
mmagin 11y ago
It always seems like languages that typically are used in an all-encompassing environment are at a disadvantage when it comes to widespread adoption compared to languages that anyone can just start using in their existing OS, with their existing GUI, editor, etc.
- DonaldFisk 11y ago
  Visual C++? Or Visual Basic?
  - rhodysurf 11y ago
    Visual C++ came after regular C++
  - goldfire 11y ago
    Are you suggesting those as counterexamples? Neither one is an example of an "all-encompassing environment." "Visual C++" no longer exists, it's just part of Visual Studio now. When it did exist, it was merely an IDE for regular C++, not any kind of separate environment. Visual Basic was a package including a GUI toolkit, a programming language, and an IDE for developing ordinary Windows applications. These tools were deployed and used as ordinary Windows applications. There was no separate computing environment with its own windowing system, data storage mechanisms, UI conventions, etc. And the current Visual Basic .NET isn't even that anymore; it's just another .NET language now, where you can swap out the IDE or GUI framework for whatever is available (including none at all if you like, you don't need either one to have a useful VB.NET program).
vezzy-fnord 11y ago
Given Maxime's background notable background in JIT and optimizing compiler research, I'm quite disappointed that her argument for Smalltalk's failure is the simplistic and routinely thrown around canard of "pragmatism". Why condemn Smalltalk for its idealistic vision when a lot of functional languages that are so trending are just as idealistic? (A few notes: there are implementations of Smalltalk these days which do not involve graphical environments. GNU Smalltalk is the most advanced. The assertion that textual mediums for writing code are always superior over visually enhanced ones isn't an argument so much as a culture war. It's also self-evidently of little weight, as the benefits of having a full-fledged Smalltalk VM are immediately visible. Furthermore, the idea of Smalltalk as the hermit kingdom that locks you in to its toolset isn't as true anymore like it was in the past. Tools like Monticello can interact reasonably well with the outside world: https://stackoverflow.com/questions/8244502/version-control-for-smalltalk-seaside https://stackoverflow.com/questions/8244502/version-control-...)
- sanderjd 11y ago
  > the benefits of having a full-fledged Smalltalk VM are immediately visible. I'm not so sure they are. I've personally never been able to wrap my head around how I would use any of the Smalltalk environments I've played with to create and distribute something useful to a real person, entirely due to the necessity of "a full-fledged Smalltalk VM". It seems too all-or-nothing; maybe it would work well as an entire OS, but it doesn't work great at the application level.
  - AceJohnny2 11y ago
    From trying multiple times to give Smalltalk a spin, this has been my thought as well. It has a bootstrap problem, where it's hard to integrate it with the rest of the software ecosystem. I'm sure there are solutions to that, but they aren't advertized as well.
  - pjmlp 11y ago
    You could generate an executable with a pruned image. At least with the commercial Smalltalks.
gmfawcett 11y ago
The final comments about Scheme seem like a digression from the thesis. Scheme is almost the antithesis of Smalltalk, in that only an essential core language is provided. I suppose she's arguing that "good is somewhere between Smalltalk and Scheme" but the closing came across as offtopic, as if she were surprised to find that a language famed for its minimalism was actually minimalist.
ch4s3 11y ago
Wow that Robert Martin talk has not aged well. I couldn't imagine that being a talk at Rails Conf now. Good info, but it feels a bit off 6 years later.
- billsix 11y ago
  What changed in the subsequent 6 years?
kachnuv_ocasek 11y ago
>Scheme doesn’t include the most basic string routines. Whoa, really? Racket, arguably the most popular Scheme implementation, seems to have a nice standard library with tons of implemented SRFIs. Also, it seems to be gaining popularity (albeit slowly) not only for itself but for Lisps in general.
- tachyonbeam 11y ago
  Racket is its own language now, it isn't Scheme per-se. They've split apart because of disagreements over which direction the language should take.
  - pmelendez 11y ago
    True... it does include R5RS though, and I think it does include lot of libraries for that too.
- xrange 11y ago
  ...is this the string library you are referring to? http://docs.racket-lang.org/reference/strings.html http://docs.racket-lang.org/reference/strings.html ...or something more extensive?
  - sigzero 11y ago
    I am not sure what you are getting at? More extensive? Those are basic string functions.
    - xrange 11y ago
      One man's paltry can be another man's extravagant. If you are coming from R5RS, then that Racket library would be a breath of fresh air. If you are coming from Perl, then maybe not so much.
      - elibarzilay 11y ago
        That's the first time I hear of Racket being accused of being too small... Looking at http://perldoc.perl.org/index-functions-by-cat.html#Functions-for-SCALARs-or-strings http://perldoc.perl.org/index-functions-by-cat.html#Function... I count about 30 functions (including regexp ones); looking at the racket page I count over 50. Also, I once got the snow yellow at over 3 meters.
xrange 11y ago
So I was interested when someone noted that apparently Pharo/Squeak stumble when it comes to unicode: https://www.reddit.com/r/programming/comments/3ha1gu/why_arent_people_using_smalltalk/cu5pf24 https://www.reddit.com/r/programming/comments/3ha1gu/why_are... ...it seems like that could potentially lead people to be skeptical about an environment/language that is touted as being highly productive, with automated refactoring ease, unit testing, test driven development, and turtles-all-the-way-down, etc.
WalterGR 11y ago
Also see Why is Smalltalk Dead? https://news.ycombinator.com/item?id=10071681 https://news.ycombinator.com/item?id=10071681 87 points 5 days ago 61 comments (http://c2.com/cgi/wiki?WhyIsSmalltalkDead http://c2.com/cgi/wiki?WhyIsSmalltalkDead)
cwp 11y ago
Sigh. Nothing killed Smalltalk. It's not dead. Neither is Scheme. Yeah, both of those languages have pretty small communities, but that's viable in the Internet Age. Heck, even Self, which nobody ever used for actual shipping software (as far as I know), still has some life in it. The latest release was last year and runs on Linux, Mac OS X. (What, no Solaris support?) http://blog.selflanguage.org/2014/01/12/self-mallard-4-5-0-released/ http://blog.selflanguage.org/2014/01/12/self-mallard-4-5-0-r... Compared to Self, Smalltalk and Scheme are downright mainstream, and used in all sorts of production software. This is important if you're planning on inventing a new programming language. The chances that you create the next Javascript or Java are slim to none. Those languages are platforms that are backed by large companies. Languages invented by enthusiastic geeks can succeed, but they don't take over the world. Even when success does come, it's after decades as niche languages with tiny communities. If you consider Smalltalk and Scheme dead, be prepared to have your language be stillborn.
- wvenable 11y ago
  > Languages invented by enthusiastic geeks can succeed, but they don't take over the world. Ruby, Python, and Lua are all obvious counter-examples to the idea that enthusiastic geeks cannot create languages that are many orders of magnitude more successful than SmalllTalk and Scheme. Even CoffeeScript, if you can call it a complete language, is in the realm of that success. The only language that has come out recently that is successful purely because of the backing of a large company is Swift.
  - cwp 11y ago
    Actually, those are the very languages I had in mind. Perl too. Yes, they have many more active developers than Smalltalk. But you know what? I was part of the Ruby community before Rails, and it was tiny. That was after it had been around for 10 years. So I'll say it again. If you want to create a new language, go for it! But I wouldn't sneer at Smalltalk and Scheme in the process. Those communities are relatively small, but they're still huge compared to your brand-new language, and they will be for decades. And if you judge language success by innovation and influence rather than developers... well, you have even bigger shoes to fill.
_ph_ 11y ago
While the article raises a few good points, I got distracted by the statements about Scheme at the end of the article. Yes r5rs might be overly minimal, but all real-world scheme implementations contain the usual basic tool functions like string parsing. The performance quoted of a minute for parsing a megabyte sized file can only mean two things: either a defunct scheme was used or the program used contained major flaws - this can happen if you are new to a language, but this is not a useful measure of the language. Even garden-variety byte code interpreters should do this in seconds.
- xrange 11y ago
  My favorite scheme antecdote: http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=0006XQ http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=...
david-given 11y ago
Smalltalk is a lovely, lovely language. It's fantastically simple --- it's got about four syntactic elements: you can call methods, you can declare and assign variables, you can create closures (called blocks in the Smalltalk world), and you can return from methods. That's about it. There's no control flow --- you do that through passing blocks into methods. You can learn the entire language in five minutes. Of course, learning the library is another matter. But it's always depressed me that nearly forty years later, our high-tech and ultrafast dynamic languages still cannot hold a candle to Smalltalk for clarity, simplicity and usability. (And the way that every time they invent a new feature, chances are Smalltalk had it in 1980. Better.)
- jasoncapriati 11y ago
  I'm intrigued. Can you point to a book or guide that expands this further, is beginner friendly and not 300 pages? Thanks!
  - david-given 11y ago
    Amber has a really nice interactive tutorial: http://amber-lang.net/learn.html http://amber-lang.net/learn.html It's actually running in your browser, and the whole thing is a live coding environment in disguise. Well worth a play.
    - rufugee 11y ago
      First thing I get when clicking "DoIt" in Chrome or Firefox is "Parse error on line 1 column 47 : Unexpected character null". Edit: turns out, I should've looked more closely. You're supposed to select particular text before pressing the button. If you do this it works. Still, they might want to consider a more friendly error message ;)
      - david-given 11y ago
        I think what it's trying to tell you is that you haven't selected any text inside the edit window. (I agree it's a terrible error message.)
WaxProlix 11y ago
> For instance, Smalltalk had the ability to suspend running programs into a saved image, and resume execution later at the saved point. I'm curious - is this just a continuation? Or is it baked into the language, like exception handling or something? Any smalltalkers want to expound or link to relevant docs/tutorials?
- arnsholt 11y ago
  You could call it a continuation, I guess, but continuations don't generally persist between separate invocations of your programming. The image is a file that can be passed around and when you open/execute (or whatever you want to call it), the program resumes where you left off. This is how most Lisp applications are distributed as well. Starting from a clean image (that is, one containing only the language standard library) you build up the initial state of your app by compiling the source files, and then dump the whole shebang as an image.
- david-given 11y ago
  It's baked into the VM. When they say that in Smalltalk, everything's an object, they're seriously not kidding. Everything is an object, including compiled code, stack frames, execution contexts, threads, etc. A traditional Smalltalk system uses an object table, where all object pointers are really references to a slot in the table; this allows the garbage collector to move objects around in memory easily. This means that it becomes trivial to dump everything out to disk, reload it later, update the object table, and suddenly the entire state of your system is restored (ignoring host OS resources, of course, but traditionally Smalltalk didn't use an operating system). I did have a handy sample for GNU Smalltalk that would snapshot an image containing a running thread which, when the thread was reloaded, would seamlessly resume but, er, I seem to have lost it.
- cwp 11y ago
  Yes, it is a continuation, although it's more comprehensive than call/cc. When you save a Smalltalk image it serializes not only the call stack but the entire heap. It's rather like a core dump that can resume executing. It's typically implemented in the VM as a primitive function kind of like posix fork(). When it returns, the entire state of the program has been saved to disk. The return value is a boolean, which tells you if you're returning from the original call, or resuming from the saved image. Classical Smalltalk dialects didn't have continuations as a flow control construct, but they did have reified stack frames, so it was possible to implement Scheme-style continuations in a few lines of code.
area51org 11y ago
don’t perform very well (see CPython, Ruby) Sigh. I really wish that smart people would stop spreading myths. Ruby, at least, performs quite well. The "Ruby is slow" days are years behind us.
- matthewmacleod 11y ago
  I'm like the biggest Ruby fan out there, but c'mon – that's just not true! Ruby is great at many things, and it has adequate performance for many situations -'Fast Enough', as DHH said. And with liberal use of C extensions, I've used it in some high-performance scenarios where the expressiveness was more beneficial than the complexity of using extensions. But it's really not fast – up to 100x slower than Java (http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=yarv&lang2=java http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...) or 30x slower than Javascript on V8 (http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=yarv&lang2=v8 http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...). I know these are micro benchmarks, but they're useful for comparison. Some of this is down to the nature of the Ruby interpreter and will improve with time (and with implementations like JRuby). Some of it is down to the highly dynamic nature of the language. The point remains though – if you need high performance for a particular task, Ruby may not be the best option.
  - cuillevel3 11y ago
    Ruby isn't that much slower than other slow languages. But compared to the fast ones it is really really slow.
    - igouy 11y ago
      There's a chart for that -- http://benchmarksgame.alioth.debian.org/u64/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64/which-programs-a... -- but the question is always really really slow to do what exactly?
- xrange 11y ago
  >Ruby, at least, performs quite well. Are you talking absolute performance (as in machines are faster now, so speed has become less important) or relative performance (compared to performing the same task with a different interpreter/complier)? https://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=sbcl&data=u32 https://benchmarksgame.alioth.debian.org/u32/benchmark.php?t...
brudgers 11y ago
The premise that Smalltalk was driven by idealism over pragmatics is suspect. We got GUI's and personal computers and object oriented languages and IDE's because Smalltalk sliced the envelope with it's cutting edge approach. Martin's talk was more than 35 years after the first release of Smalltalk...it's older than C. A discussion about all the problems Uncle Bob avoids by not using C would be both longer and duller...his talk describes why he didn't choose Smalltalk when he replaced the pain that C++ inherited from C...that 20 years after Smalltalk was invented he found a better option funded by Sun, isn't all that surprising.
DonaldFisk 11y ago
Smalltalk is no more visual or tied to GUIs than C++ is. There's at least one variant, GNU Smalltalk, which doesn't have an IDE. Squeak is a rather nice IDE, though, and makes a good point in the way it blurs the boundary between programming language and operating system. We've had Lisp Machines; I think a Smalltalk machine would be cool. You can visualize the space of programming languages as having local maxima where, if you modify the language in any way, you make it worse. I think Smalltalk occupies one such local maximum, Prolog another. Others are less clear-cut. Of course, being good doesn't equate with being popular. Java is a Smalltalk-C hybrid and is very popular. It aimed very well at the average programmer, and hit its target.
- lispm 11y ago
  we had Smalltalk machines. The same hardware which ran Xerox' Lisp Machine OS also ran Smalltalk. The processor microcode was different and it booted into Smalltalk on the metal.
skywhopper 11y ago
I really enjoyed learning and toying around with Smalltalk and Scheme. What killed it for me was that for all the fun abstractions, they were so isolated in their own environment and disconnected from the operating system that it was not apparent how you would use them for anything real. Processing files, connecting to databases and other network resources, and interacting with the user are core practical services that need to be front and center to get new users to connect to your language, but if those elements are ghettoized into awkward libraries that don't work as elegantly as the abstract parts of the language then you aren't going to get traction, except for very specialized purposes.
d0m 11y ago
My personal opinion is what killed most very good languages is the "elite" and "math" aspect of them. By elite I mean people who thought they were so much superior to everyone else (And they were!), that they'd left the beginners and inexperienced programmers out of the discussions and decisions. But guess what, high level people who make decisions aren't always the best programmers, so C++ won because they had better sales people and were more beginners and sales friendly. By "Math", I mean that most functional books and tutorials used to only focus on physics or maths aspect of the language, or AI.. whereas the languages who seemed to have won the war (Think Perl, PHP at the time, or Python/Ruby) were much more practical in how the language can be used to solve day-to-day pragmatic problems. I think it's changing.. and it's really nice to see amazing concepts from LISP in the mainstream/hipsters languages..
- coldtea 11y ago
  >so C++ won because they had better sales people and were more beginners and sales friendly. Actually C++ is far worse for beginners than Smalltalk (which is casually used as a teaching language to kids, as Squeek etc). The comment about "math" and "elite" show no familiarity with Smalltalk or the environment back then. What you say might be true for Haskell, or even CL, but it doesn't have anything to do with Smalltalk.
- mscharrer 11y ago
  I really like C++, but I think it mainly won because it was friendly to the huge number of programmers that already had years of experience with C at the time. Easy use of existing C projects was also a huge benefit.
dxedxaede 11y ago
How to determine the aliveness/deadness of a language: 1. Work out what you want to build, and functionalities that you would require. 2. Do a search for libraries in language X. If success, go to 3 else it is dead for you - look at another language. 3. Look for adequate documentation and an active, helpful community. If success, go to 4 else it is dead for you - look at another language. 4. Try building a quick and simple application. If you found it enjoyable and offers something other tools you already know don't, go to 5 else it is dead for you - look at another language. 5. Build something more substantial. If you still find it enjoyable, go to 6 else it is dead for you - look at another language. 6. Congratulate yourself that you have discovered an enjoyable and useful tool. And that you took the time and effort to explore the language yourself and made an informed decision, and not just read someone's opinion and went with it. You may also start to suspect most opinions are from people who never actually used the language for anything more that what you just did, or inherited a dreadful codebase. I did all this and I found myself using Pharo about three years ago. I still am, and I enjoy it tremendously. Also, (Pharo) Smalltalk is the most alive language I have ever used.
- claystu 11y ago
  What have you built with Pharo? (Genuine question...)
  - dxedxaede 11y ago
    Libraries to access Pin (pin.net.au), Stripe (not yet complete), Twilio (almost complete). My own bindings to SQLite. Libraries to write Latex files. Currently writing web server proxies for accessing Australian government mandated web services. None are yet released, but I am aiming to make a commercial service out of them so they may never be open sourced.
    - ZacDavies 11y ago
      Pin employee here, if you've built something that supports us we'd love to add it to our integrations page.
sebastianconcpt 11y ago
I don't like the culture of killing things and saying that things are dead when they still have individuals extracting value from it. I also don't find particularly strong or appealing, the Tyranny of the Majority friendly Argumentum Ad Populum nor the Keynesian Beauty Contests as drivers for design language (actually for nothing in life and not only language design). On the other hand, I do find interesting that the User Experience gets used on language and frameworks and tooling design. While Smalltalk never really rocked it at UI and UX, it was good enough to inspire Steve Jobs to do the GUI of a system right (in terms of UX) on the mackintosh. Regardless of comunity size, I still want to see what's the next thing that will create such degree of positive influence in these days and for the next decadeds. Good luck
notdeadSTer 11y ago
I generally like Uncle Bob, but he isn't a Smalltalker and didn't demonstrate any insight into Smalltalk's unpopularity in that talk. Worse, this is hardly the first or only time a prominent Rubyist ignorant of Smalltalk has publicly attacked it. Sarah Mei did so in a talk two years ago, mocking it for not having any conferences of its own (ESUG, Pharo Days, and Smalltalks apparently don't count), and she and Steve Klabnik recently had fun tweeting anti-Smalltalk quips back-and-forth. Given that most of the non-awful stuff (where "awful" means, for example, syntax too complicated to be described by a CF grammar or horrible performance) they like about Ruby was lifted directly from Smalltalk, you'd expect Rubyists to be extremely deferential and respectful towards Smalltalk and Smalltalkers, but they aren't. Instead they're arrogant and condescending despite being ignorant, validating all of the well-earned stereotypes of Rubyists. As for why Smalltalk "died" (cf. pharo.org) I would say it was too expensive, both in licensing terms and hardware costs. You could outfit entire teams with Borland or MS tools for the price of a single seat license for Smalltalk. Some vendors would charge (and still charge) a percentage of your revenue forever, which is insane. Then Java came along, and it was free. Smalltalk also missed out on the open source revolution, not having viable libre implementations (Pharo, GNU) until relatively recently.
- igouy 11y ago
  >>You could outfit entire teams with Borland or MS tools for the price of a single seat license for Smalltalk in the 80s or 90s.<< Different Smalltalk implementations, different prices: https://books.google.com/books?id=wJswszKTwl4C&pg=RA1-PA43&lpg=RA1-PA43&dq=digitalk+smalltalk&source=bl&ots=SugTPceBnI&sig=zqNnQvhFkVy5_jufBts_MKtd9-Q&hl=en&sa=X&ei=_lx5VJrUJcX4igLj-oHgAQ#v=onepage&q=digitalk%20smalltalk&f=false https://books.google.com/books?id=wJswszKTwl4C&pg=RA1-PA43&l... >>Then Java came along, and it was free.<< Free and The-Future-of-the-Internet TM. ---- There is an important technical / licensing / business problem with Smalltalk that has not been mentioned -- lack of library standardization. Apart from a few core classes, each Smalltalk implementation had different class names and method names for things that once-upon-a-time were special but quickly became commonplace -- like windows and menus and … So you could never hire a "Smalltalk" developer: you hired a VW developer or a Smalltalk/V developer or a VA developer and waited for them to get up to speed with an unfamiliar environment.
peter303 11y ago
Although Smalltalk was early computer language from the 1970s, it could not run efficiently on most computers until the 32bit CPUs came along in the 1990s. By then the simple C language and it's OOP hybrids dominated the coding world. Smalltalk came on the scene before computer operating systems were well developed as we know them now. Hence Smalltalk did a little bit of everything- code, GUI, OS, IDE. This an advantage in providing an unified API to all these services. However all these services are not as well developed inside Smalltalk as in the layered systems we have now.
- igouy 11y ago
  May 1988, Smalltalk/V286 was viable on commodity hardware. http://sdmeta.gforge.inria.fr/FreeBooks/SmalltalkVTutorial/SmalltalkVTutorial.pdf http://sdmeta.gforge.inria.fr/FreeBooks/SmalltalkVTutorial/S...
- rjsw 11y ago
  The Apple Macintosh was released in 1984, Smalltalk ran on it fairly soon after this. The problem was that it wasn't available to the general public, only to universities.
  - igouy 11y ago
    Apparently $150 to businesses. "Apple Team Developing Maclike Smalltalk" https://books.google.com/books?id=Dj8EAAAAMBAJ&pg=PA28&lpg=PA28&dq=digitalk+v/mac&source=bl&ots=Bn3PgQSKCY&sig=lInMZS7XOC7cwGNfB7Cnjigluik&hl=en&sa=X&ved=0CDAQ6AEwA2oVChMIpMHs_JK9xwIViy6ICh2NVgtq#v=onepage&q=digitalk%20v%2Fmac&f=false https://books.google.com/books?id=Dj8EAAAAMBAJ&pg=PA28&lpg=P...
    - rjsw 11y ago
      Ok. My memory of it was from a bit earlier, I first saw it sometime in 1986. You would have had to add the cost of APDA membership to the $150 stated in your link. I found an OOPSLA conference report that described seeing a demo of the Apple Smalltalk+MacApp product. I also found a flyer for Smalltalk-80 on the IBM AT for $1000 from around the same date.
wangii 11y ago
Languages thrive or die. The successful ones are those enable(d) less capable people at the time to do fashionable works as good as, or even better than the professionals. It has nothing to do with anything other than marketing strategy: find a under served market segment and empower idiots to do mediocre+ works with little efforts. In order to achieve so, language designers have to break old paradigms, simply because if they don't, the less capable people at the time just don't understand, nor capable of (otherwise, they would be professionals).
- igouy 11y ago
  It's less dramatic -- languages thrive or fade away ;-)
- 59nadir 11y ago
  > The successful ones are those enable(d) less capable people at the time to do fashionable works as good as, or even better than the professionals. It has nothing to do with anything other than marketing strategy: find a under served market segment and empower idiots to do mediocre+ works with little efforts. In order to achieve so, language designers have to break old paradigms, simply because if they don't, the less capable people at the time just don't understand, nor capable of (otherwise, they would be professionals). Most of the (most) popular languages aren't revolutionary and they're also weak in terms of level of abstraction. Reading your comment, one would assume that Lisp, batteries included-Schemes, Python, Ruby, Perl, Haskell, etc. are topping the charts. In reality, though, people are mostly using Java, C, C++, C# and yes... Python is very popular. It's outrun completely by languages that require far more work to do less, however. I don't know if I'm misreading your comment, but the above seems to stand in contrast to your point. The most popular languages are the ones with a lower level of abstraction, less expressive power and that require a programmer to write/manage more to do less, meaning they make more effort for these 'mediocre+' results. A point can be made that you think less while using these languages, but what time you don't spend on thinking is spent on writing (and then debugging) and I guess this is the 'less capable' part of your post, but this doesn't cover the fact that the languages that've enabled people to leapfrog business professionals (think Ruby + Rails being used to leapfrog professionals in web development) have almost nothing in common with the top list of used programming languages. The most used programming languages remain and have pretty much always been languages that use C syntax and don't actually push the envelope too much. Some rankings will have PHP and JS up there with the rest of them, but these fall neatly into the fold and are about as 'lame' as the rest of the top (with JS trying to walk lately).
amiramir 11y ago
I programed in Smalltalk-80 from 1990-1995. I used it at Morgan Stanley to build a derivative trading system that was distributed between London and NYC. It was running on networed Sun Sparcstations. Traders would collaborate on the same trading "book" across different machines. One of the big battles of getting the system installed was persuading traders to make room and to use a mouse to control the system. St-80 was a great system and by way my favorite programming experience. I remember visiting Jim Gosling to hear about Oak (which subsequently became Java) and thinking that it was neat but a pale imitation of Smalltalk. What "killed" Smalltak were a thousand cuts. A huge problem was the fact that hardware in those days was slow. Our production machines had a 25 Megahertz processor which had problems with the interpreted language that was also painting a GUI. For a long time St-80 would just take 100% of the puny cpu even when there was nothing going on. Eventually there was 4-line event driven patch that cleared that up but that did not help when the program actually did some work. For finance double-dispatch arithmetic made things worse since even a simple addition would result in a bunch of message sending that was cute and pure but slow. The monolithic image was an issue too since shipping and delivering production code was hard. There were source control system but ultimately the image was a hug blob that had to be shipped around. Another issue was the windowing system. Smalltalk was its own universe and basically grew out of being the whole environment for a machine (e.g. Xerox Star). There were no namespaces so it was hard to segments certain kinds of code and you'd end up fiddling with the innards of St which may have unintended consequences. It did not integrate with the window managers of the day (e.g. Motif) and could not use native widgets so we had to try to style our widgets to look like the window manager. I think the folks at ParcPlace were great inventors and engineers (Peter Deutsch is a god) but they were not fast enough to respond to the pressures of the market. I wonder what would happen if Gigahertz machines were avaible for Smalltalk and if ParcPlace had managed to make their system have a decent package manager and to call native widgets. It was also hard to find engineers since C/C++ was there flavor de jour. At Morgan Stanley there was also APL/A+/J but ultimately Java took the world over and now then Javascript which started off as an interpreted language with a lot less that St-80 but some times timing is everything. Moore's law helps too. With all that said St-80 is still the gold standard of my programming life which included other fun systems such as Interlisp-D and NextStep.
- 11y ago
ljw1001 11y ago
Smalltalk's death had almost nothing to do with the language itself. It died for four reasons: #1 was price, and especially requiring companies to pay royalties on the software they write with your tools, #2 was the epic mismanagement at ParcPlace/Digitalk (including the merger of the two), #3 is that Smalltalk was (when the web took off) pretty damn bad for writing server-side Web applications, because of the threading model and blocking IO, and #4 concerns about security: the lack of high quality libraries for things like encryption, for one thing, and more fundamentally, the way you can do _anything_ once you're in the VM.) The last one is the only one that's related to the tech itself. If IBM had open-sourced VisualAge when they decided to dump it, it would probably be fairly popular now.

104 points by Garbage 11y ago

acqq 11y ago

> Not everything has to have a visual metaphor. This is again a case of pushing some idealistic principle too far, in my opinion. True. But, for example, GNU Smalltalk doesn't need GUI? https://www.gnu.org/software/smalltalk/manual/html_node/Tutorial.html https://www.gnu.org/software/smalltalk/manual/html_node/Tuto... One maintained Smalltalk implementation with GUI that can be tried: http://squeak.org/ http://squeak.org/ "Squeak is an open-source Smalltalk programming system with fast execution environments for all major platforms. It features the Morphic framework, which promotes low effort graphical, interactive application development and maintenance." For other opinions about the death of Smalltalk, there was a link to c2 resources called WhyIsSmalltalkDead on the HN just 4 days ago: https://news.ycombinator.com/item?id=10071681 https://news.ycombinator.com/item?id=10071681 What I certainly agree is that the successful language has to be able to interact with as much as possible on the host system, as efficient and as flexible. Note that we still use Fortran code, for example, for numeric libraries https://en.wikipedia.org/wiki/LAPACK https://en.wikipedia.org/wiki/LAPACK and that C easily links and calls Fortran routines.

detaro 11y ago
You can run squeak in the browser: http://bertfreudenberg.github.io/SqueakJS/ http://bertfreudenberg.github.io/SqueakJS/ Another one is http://pharo.org/ http://pharo.org/ (haven't tried it) But I've worked with Squeak quite a bit in university, and the consensus generally was: The language is really nice, and a joy to use for many things. The environment is awful and makes working with it a pain, and since everything is integrated so closely there are no obvious ways around that.
bfung 11y ago
Doesn't seem as dead as the article suggests. In addition to squeak: http://pharo.org/ http://pharo.org/ http://www.strongtalk.org/ http://www.strongtalk.org/ One of the more impressive things I've seen in the past (like 5 years ago?) was DabbleDB (https://en.wikipedia.org/wiki/Dabble_DB https://en.wikipedia.org/wiki/Dabble_DB), also written in smalltalk (the company / app was acquired, see https://news.ycombinator.com/user?id=avibryant https://news.ycombinator.com/user?id=avibryant)
david-given 11y ago
Also see Amber, which is not technically a Smalltalk but fakes it very convincingly. It runs in a web browser, compiling to Javascript. http://amber-lang.net/ http://amber-lang.net/ Load up that page and press the button, and a Smalltalk IDE will pop up for you to play with. (It sounds like an amazing way to write web apps, actually, as it supports writing changes back to the server; but the backend infrastructure is heavier-weight than I'm happy with.)

mmagin 11y ago

It always seems like languages that typically are used in an all-encompassing environment are at a disadvantage when it comes to widespread adoption compared to languages that anyone can just start using in their existing OS, with their existing GUI, editor, etc.

DonaldFisk 11y ago
Visual C++? Or Visual Basic?
- rhodysurf 11y ago
  Visual C++ came after regular C++
- goldfire 11y ago
  Are you suggesting those as counterexamples? Neither one is an example of an "all-encompassing environment." "Visual C++" no longer exists, it's just part of Visual Studio now. When it did exist, it was merely an IDE for regular C++, not any kind of separate environment. Visual Basic was a package including a GUI toolkit, a programming language, and an IDE for developing ordinary Windows applications. These tools were deployed and used as ordinary Windows applications. There was no separate computing environment with its own windowing system, data storage mechanisms, UI conventions, etc. And the current Visual Basic .NET isn't even that anymore; it's just another .NET language now, where you can swap out the IDE or GUI framework for whatever is available (including none at all if you like, you don't need either one to have a useful VB.NET program).

vezzy-fnord 11y ago

Given Maxime's background notable background in JIT and optimizing compiler research, I'm quite disappointed that her argument for Smalltalk's failure is the simplistic and routinely thrown around canard of "pragmatism". Why condemn Smalltalk for its idealistic vision when a lot of functional languages that are so trending are just as idealistic? (A few notes: there are implementations of Smalltalk these days which do not involve graphical environments. GNU Smalltalk is the most advanced. The assertion that textual mediums for writing code are always superior over visually enhanced ones isn't an argument so much as a culture war. It's also self-evidently of little weight, as the benefits of having a full-fledged Smalltalk VM are immediately visible. Furthermore, the idea of Smalltalk as the hermit kingdom that locks you in to its toolset isn't as true anymore like it was in the past. Tools like Monticello can interact reasonably well with the outside world: https://stackoverflow.com/questions/8244502/version-control-for-smalltalk-seaside https://stackoverflow.com/questions/8244502/version-control-...)

sanderjd 11y ago
> the benefits of having a full-fledged Smalltalk VM are immediately visible. I'm not so sure they are. I've personally never been able to wrap my head around how I would use any of the Smalltalk environments I've played with to create and distribute something useful to a real person, entirely due to the necessity of "a full-fledged Smalltalk VM". It seems too all-or-nothing; maybe it would work well as an entire OS, but it doesn't work great at the application level.
- AceJohnny2 11y ago
  From trying multiple times to give Smalltalk a spin, this has been my thought as well. It has a bootstrap problem, where it's hard to integrate it with the rest of the software ecosystem. I'm sure there are solutions to that, but they aren't advertized as well.
- pjmlp 11y ago
  You could generate an executable with a pruned image. At least with the commercial Smalltalks.

gmfawcett 11y ago

The final comments about Scheme seem like a digression from the thesis. Scheme is almost the antithesis of Smalltalk, in that only an essential core language is provided. I suppose she's arguing that "good is somewhere between Smalltalk and Scheme" but the closing came across as offtopic, as if she were surprised to find that a language famed for its minimalism was actually minimalist.

ch4s3 11y ago

Wow that Robert Martin talk has not aged well. I couldn't imagine that being a talk at Rails Conf now. Good info, but it feels a bit off 6 years later.

billsix 11y ago
What changed in the subsequent 6 years?

kachnuv_ocasek 11y ago

>Scheme doesn’t include the most basic string routines. Whoa, really? Racket, arguably the most popular Scheme implementation, seems to have a nice standard library with tons of implemented SRFIs. Also, it seems to be gaining popularity (albeit slowly) not only for itself but for Lisps in general.

tachyonbeam 11y ago
Racket is its own language now, it isn't Scheme per-se. They've split apart because of disagreements over which direction the language should take.
- pmelendez 11y ago
  True... it does include R5RS though, and I think it does include lot of libraries for that too.
xrange 11y ago
...is this the string library you are referring to? http://docs.racket-lang.org/reference/strings.html http://docs.racket-lang.org/reference/strings.html ...or something more extensive?
- sigzero 11y ago
  I am not sure what you are getting at? More extensive? Those are basic string functions.
  - xrange 11y ago
    One man's paltry can be another man's extravagant. If you are coming from R5RS, then that Racket library would be a breath of fresh air. If you are coming from Perl, then maybe not so much.
    - elibarzilay 11y ago
      That's the first time I hear of Racket being accused of being too small... Looking at http://perldoc.perl.org/index-functions-by-cat.html#Functions-for-SCALARs-or-strings http://perldoc.perl.org/index-functions-by-cat.html#Function... I count about 30 functions (including regexp ones); looking at the racket page I count over 50. Also, I once got the snow yellow at over 3 meters.

xrange 11y ago

So I was interested when someone noted that apparently Pharo/Squeak stumble when it comes to unicode: https://www.reddit.com/r/programming/comments/3ha1gu/why_arent_people_using_smalltalk/cu5pf24 https://www.reddit.com/r/programming/comments/3ha1gu/why_are... ...it seems like that could potentially lead people to be skeptical about an environment/language that is touted as being highly productive, with automated refactoring ease, unit testing, test driven development, and turtles-all-the-way-down, etc.

WalterGR 11y ago

Also see Why is Smalltalk Dead? https://news.ycombinator.com/item?id=10071681 https://news.ycombinator.com/item?id=10071681 87 points 5 days ago 61 comments (http://c2.com/cgi/wiki?WhyIsSmalltalkDead http://c2.com/cgi/wiki?WhyIsSmalltalkDead)

cwp 11y ago

Sigh. Nothing killed Smalltalk. It's not dead. Neither is Scheme. Yeah, both of those languages have pretty small communities, but that's viable in the Internet Age. Heck, even Self, which nobody ever used for actual shipping software (as far as I know), still has some life in it. The latest release was last year and runs on Linux, Mac OS X. (What, no Solaris support?) http://blog.selflanguage.org/2014/01/12/self-mallard-4-5-0-released/ http://blog.selflanguage.org/2014/01/12/self-mallard-4-5-0-r... Compared to Self, Smalltalk and Scheme are downright mainstream, and used in all sorts of production software. This is important if you're planning on inventing a new programming language. The chances that you create the next Javascript or Java are slim to none. Those languages are platforms that are backed by large companies. Languages invented by enthusiastic geeks can succeed, but they don't take over the world. Even when success does come, it's after decades as niche languages with tiny communities. If you consider Smalltalk and Scheme dead, be prepared to have your language be stillborn.

wvenable 11y ago
> Languages invented by enthusiastic geeks can succeed, but they don't take over the world. Ruby, Python, and Lua are all obvious counter-examples to the idea that enthusiastic geeks cannot create languages that are many orders of magnitude more successful than SmalllTalk and Scheme. Even CoffeeScript, if you can call it a complete language, is in the realm of that success. The only language that has come out recently that is successful purely because of the backing of a large company is Swift.
- cwp 11y ago
  Actually, those are the very languages I had in mind. Perl too. Yes, they have many more active developers than Smalltalk. But you know what? I was part of the Ruby community before Rails, and it was tiny. That was after it had been around for 10 years. So I'll say it again. If you want to create a new language, go for it! But I wouldn't sneer at Smalltalk and Scheme in the process. Those communities are relatively small, but they're still huge compared to your brand-new language, and they will be for decades. And if you judge language success by innovation and influence rather than developers... well, you have even bigger shoes to fill.

_ph_ 11y ago

While the article raises a few good points, I got distracted by the statements about Scheme at the end of the article. Yes r5rs might be overly minimal, but all real-world scheme implementations contain the usual basic tool functions like string parsing. The performance quoted of a minute for parsing a megabyte sized file can only mean two things: either a defunct scheme was used or the program used contained major flaws - this can happen if you are new to a language, but this is not a useful measure of the language. Even garden-variety byte code interpreters should do this in seconds.

xrange 11y ago
My favorite scheme antecdote: http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=0006XQ http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=...

david-given 11y ago

Smalltalk is a lovely, lovely language. It's fantastically simple --- it's got about four syntactic elements: you can call methods, you can declare and assign variables, you can create closures (called blocks in the Smalltalk world), and you can return from methods. That's about it. There's no control flow --- you do that through passing blocks into methods. You can learn the entire language in five minutes. Of course, learning the library is another matter. But it's always depressed me that nearly forty years later, our high-tech and ultrafast dynamic languages still cannot hold a candle to Smalltalk for clarity, simplicity and usability. (And the way that every time they invent a new feature, chances are Smalltalk had it in 1980. Better.)

jasoncapriati 11y ago
I'm intrigued. Can you point to a book or guide that expands this further, is beginner friendly and not 300 pages? Thanks!
- david-given 11y ago
  Amber has a really nice interactive tutorial: http://amber-lang.net/learn.html http://amber-lang.net/learn.html It's actually running in your browser, and the whole thing is a live coding environment in disguise. Well worth a play.
  - rufugee 11y ago
    First thing I get when clicking "DoIt" in Chrome or Firefox is "Parse error on line 1 column 47 : Unexpected character null". Edit: turns out, I should've looked more closely. You're supposed to select particular text before pressing the button. If you do this it works. Still, they might want to consider a more friendly error message ;)
    - david-given 11y ago
      I think what it's trying to tell you is that you haven't selected any text inside the edit window. (I agree it's a terrible error message.)

WaxProlix 11y ago

> For instance, Smalltalk had the ability to suspend running programs into a saved image, and resume execution later at the saved point. I'm curious - is this just a continuation? Or is it baked into the language, like exception handling or something? Any smalltalkers want to expound or link to relevant docs/tutorials?

arnsholt 11y ago
You could call it a continuation, I guess, but continuations don't generally persist between separate invocations of your programming. The image is a file that can be passed around and when you open/execute (or whatever you want to call it), the program resumes where you left off. This is how most Lisp applications are distributed as well. Starting from a clean image (that is, one containing only the language standard library) you build up the initial state of your app by compiling the source files, and then dump the whole shebang as an image.
david-given 11y ago
It's baked into the VM. When they say that in Smalltalk, everything's an object, they're seriously not kidding. Everything is an object, including compiled code, stack frames, execution contexts, threads, etc. A traditional Smalltalk system uses an object table, where all object pointers are really references to a slot in the table; this allows the garbage collector to move objects around in memory easily. This means that it becomes trivial to dump everything out to disk, reload it later, update the object table, and suddenly the entire state of your system is restored (ignoring host OS resources, of course, but traditionally Smalltalk didn't use an operating system). I did have a handy sample for GNU Smalltalk that would snapshot an image containing a running thread which, when the thread was reloaded, would seamlessly resume but, er, I seem to have lost it.
cwp 11y ago
Yes, it is a continuation, although it's more comprehensive than call/cc. When you save a Smalltalk image it serializes not only the call stack but the entire heap. It's rather like a core dump that can resume executing. It's typically implemented in the VM as a primitive function kind of like posix fork(). When it returns, the entire state of the program has been saved to disk. The return value is a boolean, which tells you if you're returning from the original call, or resuming from the saved image. Classical Smalltalk dialects didn't have continuations as a flow control construct, but they did have reified stack frames, so it was possible to implement Scheme-style continuations in a few lines of code.

area51org 11y ago

don’t perform very well (see CPython, Ruby) Sigh. I really wish that smart people would stop spreading myths. Ruby, at least, performs quite well. The "Ruby is slow" days are years behind us.

matthewmacleod 11y ago
I'm like the biggest Ruby fan out there, but c'mon – that's just not true! Ruby is great at many things, and it has adequate performance for many situations -'Fast Enough', as DHH said. And with liberal use of C extensions, I've used it in some high-performance scenarios where the expressiveness was more beneficial than the complexity of using extensions. But it's really not fast – up to 100x slower than Java (http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=yarv&lang2=java http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...) or 30x slower than Javascript on V8 (http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=yarv&lang2=v8 http://benchmarksgame.alioth.debian.org/u32/compare.php?lang...). I know these are micro benchmarks, but they're useful for comparison. Some of this is down to the nature of the Ruby interpreter and will improve with time (and with implementations like JRuby). Some of it is down to the highly dynamic nature of the language. The point remains though – if you need high performance for a particular task, Ruby may not be the best option.
- cuillevel3 11y ago
  Ruby isn't that much slower than other slow languages. But compared to the fast ones it is really really slow.
  - igouy 11y ago
    There's a chart for that -- http://benchmarksgame.alioth.debian.org/u64/which-programs-are-fastest.html http://benchmarksgame.alioth.debian.org/u64/which-programs-a... -- but the question is always really really slow to do what exactly?
xrange 11y ago
>Ruby, at least, performs quite well. Are you talking absolute performance (as in machines are faster now, so speed has become less important) or relative performance (compared to performing the same task with a different interpreter/complier)? https://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=sbcl&data=u32 https://benchmarksgame.alioth.debian.org/u32/benchmark.php?t...

brudgers 11y ago

The premise that Smalltalk was driven by idealism over pragmatics is suspect. We got GUI's and personal computers and object oriented languages and IDE's because Smalltalk sliced the envelope with it's cutting edge approach. Martin's talk was more than 35 years after the first release of Smalltalk...it's older than C. A discussion about all the problems Uncle Bob avoids by not using C would be both longer and duller...his talk describes why he didn't choose Smalltalk when he replaced the pain that C++ inherited from C...that 20 years after Smalltalk was invented he found a better option funded by Sun, isn't all that surprising.

DonaldFisk 11y ago

Smalltalk is no more visual or tied to GUIs than C++ is. There's at least one variant, GNU Smalltalk, which doesn't have an IDE. Squeak is a rather nice IDE, though, and makes a good point in the way it blurs the boundary between programming language and operating system. We've had Lisp Machines; I think a Smalltalk machine would be cool. You can visualize the space of programming languages as having local maxima where, if you modify the language in any way, you make it worse. I think Smalltalk occupies one such local maximum, Prolog another. Others are less clear-cut. Of course, being good doesn't equate with being popular. Java is a Smalltalk-C hybrid and is very popular. It aimed very well at the average programmer, and hit its target.

lispm 11y ago
we had Smalltalk machines. The same hardware which ran Xerox' Lisp Machine OS also ran Smalltalk. The processor microcode was different and it booted into Smalltalk on the metal.

skywhopper 11y ago

I really enjoyed learning and toying around with Smalltalk and Scheme. What killed it for me was that for all the fun abstractions, they were so isolated in their own environment and disconnected from the operating system that it was not apparent how you would use them for anything real. Processing files, connecting to databases and other network resources, and interacting with the user are core practical services that need to be front and center to get new users to connect to your language, but if those elements are ghettoized into awkward libraries that don't work as elegantly as the abstract parts of the language then you aren't going to get traction, except for very specialized purposes.

d0m 11y ago

My personal opinion is what killed most very good languages is the "elite" and "math" aspect of them. By elite I mean people who thought they were so much superior to everyone else (And they were!), that they'd left the beginners and inexperienced programmers out of the discussions and decisions. But guess what, high level people who make decisions aren't always the best programmers, so C++ won because they had better sales people and were more beginners and sales friendly. By "Math", I mean that most functional books and tutorials used to only focus on physics or maths aspect of the language, or AI.. whereas the languages who seemed to have won the war (Think Perl, PHP at the time, or Python/Ruby) were much more practical in how the language can be used to solve day-to-day pragmatic problems. I think it's changing.. and it's really nice to see amazing concepts from LISP in the mainstream/hipsters languages..

coldtea 11y ago
>so C++ won because they had better sales people and were more beginners and sales friendly. Actually C++ is far worse for beginners than Smalltalk (which is casually used as a teaching language to kids, as Squeek etc). The comment about "math" and "elite" show no familiarity with Smalltalk or the environment back then. What you say might be true for Haskell, or even CL, but it doesn't have anything to do with Smalltalk.
mscharrer 11y ago
I really like C++, but I think it mainly won because it was friendly to the huge number of programmers that already had years of experience with C at the time. Easy use of existing C projects was also a huge benefit.

dxedxaede 11y ago

How to determine the aliveness/deadness of a language: 1. Work out what you want to build, and functionalities that you would require. 2. Do a search for libraries in language X. If success, go to 3 else it is dead for you - look at another language. 3. Look for adequate documentation and an active, helpful community. If success, go to 4 else it is dead for you - look at another language. 4. Try building a quick and simple application. If you found it enjoyable and offers something other tools you already know don't, go to 5 else it is dead for you - look at another language. 5. Build something more substantial. If you still find it enjoyable, go to 6 else it is dead for you - look at another language. 6. Congratulate yourself that you have discovered an enjoyable and useful tool. And that you took the time and effort to explore the language yourself and made an informed decision, and not just read someone's opinion and went with it. You may also start to suspect most opinions are from people who never actually used the language for anything more that what you just did, or inherited a dreadful codebase. I did all this and I found myself using Pharo about three years ago. I still am, and I enjoy it tremendously. Also, (Pharo) Smalltalk is the most alive language I have ever used.

claystu 11y ago
What have you built with Pharo? (Genuine question...)
- dxedxaede 11y ago
  Libraries to access Pin (pin.net.au), Stripe (not yet complete), Twilio (almost complete). My own bindings to SQLite. Libraries to write Latex files. Currently writing web server proxies for accessing Australian government mandated web services. None are yet released, but I am aiming to make a commercial service out of them so they may never be open sourced.
  - ZacDavies 11y ago
    Pin employee here, if you've built something that supports us we'd love to add it to our integrations page.

sebastianconcpt 11y ago

I don't like the culture of killing things and saying that things are dead when they still have individuals extracting value from it. I also don't find particularly strong or appealing, the Tyranny of the Majority friendly Argumentum Ad Populum nor the Keynesian Beauty Contests as drivers for design language (actually for nothing in life and not only language design). On the other hand, I do find interesting that the User Experience gets used on language and frameworks and tooling design. While Smalltalk never really rocked it at UI and UX, it was good enough to inspire Steve Jobs to do the GUI of a system right (in terms of UX) on the mackintosh. Regardless of comunity size, I still want to see what's the next thing that will create such degree of positive influence in these days and for the next decadeds. Good luck

notdeadSTer 11y ago

I generally like Uncle Bob, but he isn't a Smalltalker and didn't demonstrate any insight into Smalltalk's unpopularity in that talk. Worse, this is hardly the first or only time a prominent Rubyist ignorant of Smalltalk has publicly attacked it. Sarah Mei did so in a talk two years ago, mocking it for not having any conferences of its own (ESUG, Pharo Days, and Smalltalks apparently don't count), and she and Steve Klabnik recently had fun tweeting anti-Smalltalk quips back-and-forth. Given that most of the non-awful stuff (where "awful" means, for example, syntax too complicated to be described by a CF grammar or horrible performance) they like about Ruby was lifted directly from Smalltalk, you'd expect Rubyists to be extremely deferential and respectful towards Smalltalk and Smalltalkers, but they aren't. Instead they're arrogant and condescending despite being ignorant, validating all of the well-earned stereotypes of Rubyists. As for why Smalltalk "died" (cf. pharo.org) I would say it was too expensive, both in licensing terms and hardware costs. You could outfit entire teams with Borland or MS tools for the price of a single seat license for Smalltalk. Some vendors would charge (and still charge) a percentage of your revenue forever, which is insane. Then Java came along, and it was free. Smalltalk also missed out on the open source revolution, not having viable libre implementations (Pharo, GNU) until relatively recently.

igouy 11y ago
>>You could outfit entire teams with Borland or MS tools for the price of a single seat license for Smalltalk in the 80s or 90s.<< Different Smalltalk implementations, different prices: https://books.google.com/books?id=wJswszKTwl4C&pg=RA1-PA43&lpg=RA1-PA43&dq=digitalk+smalltalk&source=bl&ots=SugTPceBnI&sig=zqNnQvhFkVy5_jufBts_MKtd9-Q&hl=en&sa=X&ei=_lx5VJrUJcX4igLj-oHgAQ#v=onepage&q=digitalk%20smalltalk&f=false https://books.google.com/books?id=wJswszKTwl4C&pg=RA1-PA43&l... >>Then Java came along, and it was free.<< Free and The-Future-of-the-Internet TM. ---- There is an important technical / licensing / business problem with Smalltalk that has not been mentioned -- lack of library standardization. Apart from a few core classes, each Smalltalk implementation had different class names and method names for things that once-upon-a-time were special but quickly became commonplace -- like windows and menus and … So you could never hire a "Smalltalk" developer: you hired a VW developer or a Smalltalk/V developer or a VA developer and waited for them to get up to speed with an unfamiliar environment.

peter303 11y ago

Although Smalltalk was early computer language from the 1970s, it could not run efficiently on most computers until the 32bit CPUs came along in the 1990s. By then the simple C language and it's OOP hybrids dominated the coding world. Smalltalk came on the scene before computer operating systems were well developed as we know them now. Hence Smalltalk did a little bit of everything- code, GUI, OS, IDE. This an advantage in providing an unified API to all these services. However all these services are not as well developed inside Smalltalk as in the layered systems we have now.

igouy 11y ago
May 1988, Smalltalk/V286 was viable on commodity hardware. http://sdmeta.gforge.inria.fr/FreeBooks/SmalltalkVTutorial/SmalltalkVTutorial.pdf http://sdmeta.gforge.inria.fr/FreeBooks/SmalltalkVTutorial/S...
rjsw 11y ago
The Apple Macintosh was released in 1984, Smalltalk ran on it fairly soon after this. The problem was that it wasn't available to the general public, only to universities.
- igouy 11y ago
  Apparently $150 to businesses. "Apple Team Developing Maclike Smalltalk" https://books.google.com/books?id=Dj8EAAAAMBAJ&pg=PA28&lpg=PA28&dq=digitalk+v/mac&source=bl&ots=Bn3PgQSKCY&sig=lInMZS7XOC7cwGNfB7Cnjigluik&hl=en&sa=X&ved=0CDAQ6AEwA2oVChMIpMHs_JK9xwIViy6ICh2NVgtq#v=onepage&q=digitalk%20v%2Fmac&f=false https://books.google.com/books?id=Dj8EAAAAMBAJ&pg=PA28&lpg=P...
  - rjsw 11y ago
    Ok. My memory of it was from a bit earlier, I first saw it sometime in 1986. You would have had to add the cost of APDA membership to the $150 stated in your link. I found an OOPSLA conference report that described seeing a demo of the Apple Smalltalk+MacApp product. I also found a flyer for Smalltalk-80 on the IBM AT for $1000 from around the same date.

wangii 11y ago

Languages thrive or die. The successful ones are those enable(d) less capable people at the time to do fashionable works as good as, or even better than the professionals. It has nothing to do with anything other than marketing strategy: find a under served market segment and empower idiots to do mediocre+ works with little efforts. In order to achieve so, language designers have to break old paradigms, simply because if they don't, the less capable people at the time just don't understand, nor capable of (otherwise, they would be professionals).

igouy 11y ago
It's less dramatic -- languages thrive or fade away ;-)
59nadir 11y ago
> The successful ones are those enable(d) less capable people at the time to do fashionable works as good as, or even better than the professionals. It has nothing to do with anything other than marketing strategy: find a under served market segment and empower idiots to do mediocre+ works with little efforts. In order to achieve so, language designers have to break old paradigms, simply because if they don't, the less capable people at the time just don't understand, nor capable of (otherwise, they would be professionals). Most of the (most) popular languages aren't revolutionary and they're also weak in terms of level of abstraction. Reading your comment, one would assume that Lisp, batteries included-Schemes, Python, Ruby, Perl, Haskell, etc. are topping the charts. In reality, though, people are mostly using Java, C, C++, C# and yes... Python is very popular. It's outrun completely by languages that require far more work to do less, however. I don't know if I'm misreading your comment, but the above seems to stand in contrast to your point. The most popular languages are the ones with a lower level of abstraction, less expressive power and that require a programmer to write/manage more to do less, meaning they make more effort for these 'mediocre+' results. A point can be made that you think less while using these languages, but what time you don't spend on thinking is spent on writing (and then debugging) and I guess this is the 'less capable' part of your post, but this doesn't cover the fact that the languages that've enabled people to leapfrog business professionals (think Ruby + Rails being used to leapfrog professionals in web development) have almost nothing in common with the top list of used programming languages. The most used programming languages remain and have pretty much always been languages that use C syntax and don't actually push the envelope too much. Some rankings will have PHP and JS up there with the rest of them, but these fall neatly into the fold and are about as 'lame' as the rest of the top (with JS trying to walk lately).

amiramir 11y ago

I programed in Smalltalk-80 from 1990-1995. I used it at Morgan Stanley to build a derivative trading system that was distributed between London and NYC. It was running on networed Sun Sparcstations. Traders would collaborate on the same trading "book" across different machines. One of the big battles of getting the system installed was persuading traders to make room and to use a mouse to control the system. St-80 was a great system and by way my favorite programming experience. I remember visiting Jim Gosling to hear about Oak (which subsequently became Java) and thinking that it was neat but a pale imitation of Smalltalk. What "killed" Smalltak were a thousand cuts. A huge problem was the fact that hardware in those days was slow. Our production machines had a 25 Megahertz processor which had problems with the interpreted language that was also painting a GUI. For a long time St-80 would just take 100% of the puny cpu even when there was nothing going on. Eventually there was 4-line event driven patch that cleared that up but that did not help when the program actually did some work. For finance double-dispatch arithmetic made things worse since even a simple addition would result in a bunch of message sending that was cute and pure but slow. The monolithic image was an issue too since shipping and delivering production code was hard. There were source control system but ultimately the image was a hug blob that had to be shipped around. Another issue was the windowing system. Smalltalk was its own universe and basically grew out of being the whole environment for a machine (e.g. Xerox Star). There were no namespaces so it was hard to segments certain kinds of code and you'd end up fiddling with the innards of St which may have unintended consequences. It did not integrate with the window managers of the day (e.g. Motif) and could not use native widgets so we had to try to style our widgets to look like the window manager. I think the folks at ParcPlace were great inventors and engineers (Peter Deutsch is a god) but they were not fast enough to respond to the pressures of the market. I wonder what would happen if Gigahertz machines were avaible for Smalltalk and if ParcPlace had managed to make their system have a decent package manager and to call native widgets. It was also hard to find engineers since C/C++ was there flavor de jour. At Morgan Stanley there was also APL/A+/J but ultimately Java took the world over and now then Javascript which started off as an interpreted language with a lot less that St-80 but some times timing is everything. Moore's law helps too. With all that said St-80 is still the gold standard of my programming life which included other fun systems such as Interlisp-D and NextStep.

11y ago

ljw1001 11y ago

Smalltalk's death had almost nothing to do with the language itself. It died for four reasons: #1 was price, and especially requiring companies to pay royalties on the software they write with your tools, #2 was the epic mismanagement at ParcPlace/Digitalk (including the merger of the two), #3 is that Smalltalk was (when the web took off) pretty damn bad for writing server-side Web applications, because of the threading model and blocking IO, and #4 concerns about security: the lack of high quality libraries for things like encryption, for one thing, and more fundamentally, the way you can do _anything_ once you're in the VM.) The last one is the only one that's related to the tech itself. If IBM had open-sourced VisualAge when they decided to dump it, it would probably be fairly popular now.