11 ms·
Bits of History, Words of Advice
- deleted 6y ago[deleted]
- mellosouls 6y agoAs the article itself points out, Smalltalk may not have succeeded as an active language in the sense of market share, but its influence (and that of the environment from which it came) on later languages and development paradigms seems very significant and it's still regularly fondly referenced in many coding blogs and articles. In spirit at least, it seems a resounding success.
- Rochus 6y agoThe influence is generally overestimated. C++ and Java were mostly inspired by Simula 67, which actually was also an inspiration for Smalltalk. Although there had been a few articles before, a broader public did not have access to Smalltalk until the mid-1980s.
- projektfu 6y agoIt never forced anyone to use it. C was forced into use by the popularity of unix. Java by its association with the browser at the time. Nobody would have used objective C if Mac OS X had been based on C++ (BeOS). Ruby would be a niche if it weren’t for rails. Javascript, obviously, is necessitated by the browser.
- cies 6y agoYou mean it lacked a killer application: https://en.wikipedia.org/wiki/Killer_application https://en.wikipedia.org/wiki/Killer_application
- k__ 6y agoI had th impression Java really had something going for it. It used OOP and was leaning heavier on the code-side than Smalltalk, which had this in-place modification of a already running system. I think Java went a step back so people would understand it better.
- projektfu 6y agoIt had a lot of hype. I think a big part of the hype at the time was web related, but it was also immediately popular with schools. Schools liked that it was easy enough to spend less time teaching the language and more on the concepts. It also helped that it was going to be industrially important.
- brazzy 6y agoI think the two big factors for Java's success were these: * OOP in a C-like syntax without the complexity and traps of C++, this made it attractive as a teaching language and ensured a steady supply of Java developers * Cross-plattform-ness, reasonable performance, easy multitasking, and the Servlet API made it the ideal successor to Perl as the default option for web development, leading to ubiquitous industry adoption.
- dahfizz 6y agoSo then, maybe a better question to ask is Why does smalltalk not have a killer application? It was used to pioneer GUIs back in the 60's, why didn't it maintain that popularity?
- protomyth 6y agoYou need developers for that killer app and most killer apps don't come out of big companies. The vendors made sure the little developer wasn't welcome.
- projektfu 6y agoPartly because it couldn’t be democratized back then. HyperCard achieved a lot of the Smalltalk dream for individual programmer/users.
- giancarlostoro 6y agoYou could also argue Java was forced on people once more thanks to Android which makes the Oracle v. Google lawsuit funnier to me.
- mumblemumble 6y agoJava, I don't think it was association with the browser. I admittedly was still in school at the time, so maybe I'm missing something, but it always seemed to me that everyone regarded Java applets as more of a cute toy than a serious technology. However, Java did solve one really annoying problem that's hard to properly appreciate if you didn't leave any of your own blood behind in the 1990s: Cross-platform development. There were so many operating systems and architectures back then, and none of them had really risen to prominence as a general-purpose option, so most shops were working with a pretty decent variety of different platforms. At one point I worked at a desk that had three different computers with different processor architectures and operating systems (and therefore basically no software in common) sitting on the same desk, and all three were needed for some purpose or other. Into that environment comes a new language/platform that offers write-once-run-anywhere with decent (if not great) performance, and one of the first standard libraries that might be recognized as reasonably mature by modern standards.
- projektfu 6y agoThe batteries included approach makes a big difference in adoption. So far as I know there was nothing in particular making people use Python, it was just fun.
- ema 6y agoWould smalltalk been as successful as ruby is now if DHH had written rails in it?
- scroot 6y agoIt's possible. But the mainstream culture of computing is still so entrenched in the division of user/programmer and in the use of text editing as a primary interface that I suspect it would not have caught on in the same way.
- projektfu 6y agoThat’s a great question. Seaside was really good at handling application flow through pages, seamlessly allowing the back button to work, by being based on closures and continuations. If that had been paired with the new ideas about convention over configuration and if a good object database were freely available, I think DHH might have chosen it had he been aware. DSL like things and magical code are possible in Smalltalk but the system is more reified in its final view. You could have class methods initializing the relationships, etc, but afterward those methods and variables would be visible parts of the system. Then tearing them down might not be as easy as removing a line of code like it is in a language like Ruby where the state is discarded at the end of a run.
- jodrellblank 6y agoFrom the comments on the article "This reminds of The Lisp Curse. It's so easy to make a slightly different and potentially slightly better Smalltalk that many people end up trying. The resulting noise makes it difficult for substantial improvements to be recognized as such." - this is another way of talking about being forced to use it; it might be possible to build a better JavaScript or Visual Basic or Bash, but if you try the dominant one which is tightly coupled with a large popular system will have a lot more momentum. The force drags people to it, and stops it splintering into twisty maze of implementations all alike.
- __d 6y agoObjective-C was the language of NeXTSTEP, which was one of the most productive programming environments of its era (early 1990's). In companies where custom, in-house software development was required, NeXT, NeXTSTEP, and Objective-C did quite well. The whole macOS thing happened about 10 years after the first successes of Objective-C, when it was well on the path to obscurity due to the failure of NeXT's hardware, and then operating system businesses. But this also kinda proves your point ... it was NeXTSTEP that made Objective-C succeed (both the first time, and then again with macOS/iOS).
- projektfu 6y agoObjective C had fewer users than Smalltalk before Apple bought NeXT. Hardly a success in the sense we’re saying. It was a very nice system compared to its contemporaries. MacOS 10.1/Cocoa was a lot more fun than anything Microsoft offered.
- cies 6y agoThe article does not mention Smalltalk's uncommon syntax as a deal breaker. Not many langs with uncommon (not C-like) syntaxes have managed to become widely used. I think that that is known to those who ordered investment in Java and C#. To me Smalltalk feels too integrated, which is a problem for me. I like a language that's small in it's (open source) core, with lots of (competing) integrations (IDE, testing, profiling) available. It helps me not to feel locked-in to an ecosystem.
- p_l 6y agoPeople overestimate C syntax importance, especially earlier on - when a lot of development was in non-C languages.
- mpfundstein 6y agoso which language besides python is really really successful and doesn't bave C syntax?
- shakna 6y agoDepends what you mean by successful. If you're willing to accept heavily entrenched ("a lot of development" as in the parent), then languages like Fortran and COBOL are highly successful. They underlie an enormous amount of infrastructure in the world.
- jmull 6y agoSQL
- arexxbifs 6y agoFortran, Cobol, Algol, Pascal, Basic, Rexx, Ruby and Lisp have all experienced success relative to the size of the software industry during their peaks - perhaps most notably Visual Basic and Turbo Pascal.
- dragonwriter 6y ago
- deleted 6y ago[deleted]
- Razengan 6y agoThe formatting of this page is weird; some lines wrap, others don’t. Even in Reader Mode there’s spurious line breaks.
- frou_dh 6y agoThird from bottom says you shouldn't do this: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- Razengan 6y agoAh I somehow assumed the author may have posted this because of the blogspot link.
- programmer_dude 6y agoThis is not helpful. It's good to know if it's just me or others have the same issue.
- zerr 6y agoComplexity associated with those stateful images contributed as well, I believe.
- mikl 6y agoFrom my understanding, to adopt Smalltalk, I’d have to give up my editor, my SCM, my code review practises, my deployment strategies, my whole way of working. Learning a new language is already a big ask. If you then also require the would-be adopter to change everything around the language, everything about how they work, don’t be surprised if people choose something else. I think a modern parallel is darklang.com. It might be great, but it faces the same resistance for the same reasons. You can do some amazing things if you integrate everything into a big monolith, but that also makes it impossible to adopt a technology part-way.
- cmrdporcupine 6y agoIndeed, for Smalltalk-80 and its cousins at least. There were/are versions of Smalltalk that integrated better with the OS, but classic Smalltalk's vision was always to _be_ the OS and surrounding tools, really. Perhaps Smalltalk was too far ahead of its time at the time it initially appeared. The computing machinery of the age couldn't run it efficiently enough. If they had, it just might have displaced everything else. At the time there really were no IDEs, no good SCM, no review tools, etc. And so it could have made that world in its image, which at the time was frankly superior. But for the broader point, yes -- Smalltalk does not play well with others. I'm sure it can be made to, but that was not its first instinct.
- non-entity 6y agoI'd almost be willing, but im still not sure I "get" smalltalk. I mean sure, I've started to understand why people talk so highly of the language but the whole sandboxxed environment feels like a outdated relic from the time it was created and makes it look today like nothing more than a toy. It feels like a concept that just doesn't realistically fit in the world of software today. I want to like Smalltalk but I just can't ever see it being an option even for most of my side projects.
- ragnese 6y agoI don't know. A bunch of people are writing Electron apps. That's surely also a sandbox, right?
- ChrisMarshallNY 6y agoI enjoyed his prose. Mr. Bracha is an opinionated chap that is not afraid to back up his [well-informed] opinions in a rather pithy manner. I think that SmallTalk's contribution to ObjC was nice. It was weird to encounter, at first, but I got used to it. He has a point about the people charging for it. The same thing happened to XSLT. XSLT 1.5 is the free version; supported by many languages and libraries. XSLT 2.0, however, is where the action is at, and that is only supported by Saxon, a paid library. I'm not sure if that has changed, as I haven't messed with that Pandora's Box in a number of years.
- jrochkind1 6y agoI love ruby. Which happens to be a smalltalk-inspired language, although different enough that the particular analysis in the OP doens't apply, I don't think. (ObjC is also a smalltalk-inspired language, but also same I think). I am worried that rubyists are gonna end up talking about what happened so ruby shrank for decades too. :(
- x87678r 6y agoIt failed because it was too expensive. 25 years ago I was looking at job in an elite project that ran smalltalk. I didn't get it but liked the language enough to investigate using it in my next job. The cost was crazy, like 1-2 months wages which was hard to justify when hardly anyone else used it. If it were the same price as C++ environments/libraries (yeah remember when you had to pay for container libraries) it would have been a hugely successful language.
- leoc 6y agoAnd then the buyer likely had the cost of extra RAM on top of that...
- protomyth 6y agoYeah, try to be a small developer in the 90's and deal with the Smalltalk companies. If you made it in the door now deal with runtime fees.
- Rochus 6y agoI don't think it's the main reason. I rather share these views: http://www.wirfs-brock.com/allen/posts/914 http://www.wirfs-brock.com/allen/posts/914. Smalltalk beyond that suffers from the same issues as any dynamically typed language. You quickly lose track when projects get bigger and many problems that a compiler could easily find are discovered much later. I used ST in the nineties and then switched completely to C++ and other languages. Recently, I started using ST again, when I built the two Smalltalk-80 interpreters; from my point of view, it feels quite similar to JS or Lua, but is even more inefficient, since even control structures and loops are dynamic objects.
- grandinj 6y agoLanguages are more than just syntax and ideology. The entire ecosystem of the language and how it interacts with surrounding software is important. You can have an awesome language with lousy interaction, and it's dead in the water. Conversely, you can have a mediocre language with a great ecosystem, and it takes over the world.
- leoc 6y agoBut Smalltalk was likely the king of language ecosystem, and even more so of language interaction, at around the time when Java first appeared. And probably its only serious rivals for that crown were even more high-end and even more now-dead, like Lisp-machine Lisps. It didn't have great integration with native OS environments, but early Java wasn't spectacular in that department either.
- geophile 6y agoIn the mid 90s I was at an OO database company, and we were expanding into tools. The decision was made to produce a Smalltalk binding and build tools for that language. That was well underway when Java was released. And you could hear the air go out of the Smalltalk tires. Java was another OO language, it was designed for “applets” that would run in the browser, and it was created by Sun Microsystems, who built the most popular computers of the day. Nearly everyone who was interested in Smalltalk turned to Java and never looked back.
- darksaints 6y agoI have always noticed the fondness with which some people talk about smalltalk. For a language that practically doesn't exist anymore, I find that odd...especially considering the number of languages that people despise but still exist and are regularly used. I don't really have much love for the combination of dynamic types and object orientation in general, but could someone explain what they got from smalltalk that they don't currently have via Ruby, Python, or other currently popular languages of similar discipline? I've seen lots of explanations as to why it failed...but why do people still talk about it like they miss it?
- pixelrevision 6y agoThe big thing I find fascinating about it is the live environment. You can explore and change every single piece of code while it’s running. There’s really nothing else out there that does this except maybe lisp and even there you give up having the GUI to explore with.
- travisgriggs 6y ago* The IDE/Debugger rocked. It was the killer app. You could explore/understand code in a way that I have yet to see rivaled in any other environment. I have used PyCharm/XCode/Studio/VSCode/Emacs/Vim at regular levels. * BlockClosures. Reified and used ubiquitously. Did I mention reified? Since the language had no control flow builtins/keywords, it was all done in the library. And since Closures were fully first class objects that you could explore, understand, and extend, you could write control flow to your hearts content. * Simplicity. You didn't have to have a PHD in parsing to deal with the AST for Smalltalk. Building your own AST walker was a mid level exercise. I once saw a comparison between the Ruby AST and the Smalltalk AST. The Ruby one was like 10 times more complex to deal with all of the edge cases. I added a goto implementation for a lark in an afternoon. I wouldn't even know where to start to add goto to Python. An absurd example of course, but it highlights that you didn't feel like Dan Ingalls and the other inventors of Smalltalk controlled your destiny. They wanted you to go places with it.
- aliswe 6y agoThe article may be good, but the website, mobile adapted, it was not.
- PeterStuer 6y agoSmalltalk environments felt too much like a 'boil the ocean' approach in a world that was just starting to produce software that was distributed to and operated by non-programmers. Most of its adherents developed on Apple's early Macintosh line. One of the core tenants of the Mac was intuitive usability. The Mac developer's 'Bible' was the Inside Macintosh series that featured Object Pascal (Think Pascal was a realy good IDE for it's time) and the MacApp library and resources that made it fairly easy to produce software that adhered to Apple's then state-of-the-art UX guidelines. Smalltalk at that crucial point in time was of in it's own (academic) world, with its own windows and menus that didn't feel at all like the rest of the Mac's software. While this would soon be possible, it was too late and did not offer enough of an advantage to get the Macintosh developer community to turn away from Object Pascal. That would only be achieved by years of C/C++ programmers pushing for that language's adoption across all platforms.
- travisgriggs 6y agoSmalltalk enthusiast for twenty years here. I jumped out of the balloon almost ten years ago now and sold my soul to the mediocrity of pragmatic polyglotism. I miss Smalltalk. I miss it's clean syntax. Were there times when keyword syntax got odd, yes. But less so than list base call syntax (and even weirder with the hybrid list(keyword) keyword messages. Was everything's done via messages all the way down always the bees knees. There were some edge cases (zip?) were it was difficult to figure out where the behavior really should be bound. But the trade off was simplicity and consistency. None of this why is len() a function and upper() a method nonsense. I miss the simple syntax and pervasive use of Smalltalk closures. I miss the tooling. The RefactoringBrowser was one of the most amazing code environments out there. I found code faster. I authored code faster. I changed code faster. What have I appreciated as I've wandered through the wreckage of modern in use systems? Namespaces. There were some Smalltalk experiments here, but they were late and varied. My favorite was probably that of Smalltalk/X. I mostly like pythons namespaces: "we should do more of those". Not a fan of pythons shadowing rules though and have never decided whether it's namespaces and shadowing are codependent or independent. I kind of like typing. I remember I was skeptical of Strongtalk typing at first, but I've come to appreciate that style of annotation. Where typing always seems to break down for me is containers. I am just not a fan of generics. They are to typing what preprocessers end up becoming, a sort of "deep state Illuminati" of the program. Gilad hinted at a proposed solution to this a while back, but I never saw a follow up. And of course cheep tooling. I don't mind paying for things. But Smalltalk business model was about platform entrapment. There was no incremental. No choice. You had to choose the whole party up front.
- indymike 6y agoSmalltalk never evolved towards practical. It did so much on it's own because it had to: there were no windowing graphical operating systems, so it was invented and included. There was no SCM, and so it was invented and included. There were no object oriented IDEs with object inspectors, so it was invented and included. The problem is, the first implementation of an idea is rarely the best, or the one that wins in the market. There's entire parts of our industry that just peeled off a piece invented by Smalltalk and made a better general purpose one. Great article.
- taylodl 6y agoI worked for a firm that tried to use Smalltalk to deliver commercial software running on Windows in the early 90's. From a learning standpoint, I learned a lot. From a business standpoint this is what we ran into compared to this article: Lack of a Standard. Didn't really bother us. FYI we were using Digitalk Smalltalk. People in those days didn't have the expectation of changing their toolset without incurring problems. Business Model. At that time people paid for software. The free (as in beer) software distribution model didn't yet exist. The tools were expensive but they were justified by programmer productivity. To that end, the tools made programmers very productive. It's one of the best environments I've ever worked in - and that was over 25 years ago! Performance. Ah - this is where we started having problems. At that time Smalltalk hadn't yet optimized integer arithmetic and as a result simple numerical operations were slow. The garbage collector was also difficult - when it ran it would essentially hang your machine for several minutes. That would improve over the years but it was bad early on. Performance was the deciding factor in our not using Smalltalk. Interaction with the outside world. Digitalk took care of this. It was workable, i.e. this isn't where we had problems or concerns. Deployment. Digitalk was capable of producing a Windows executable file. There were two problems though: 1) it made a guess as to which classes should be included in the executable artifact (you could manually adjust), this made automated testing extremely important because you would need to test a release candidate and 2) it employed it's own windowing system which it would embed in the executable. It never looked like a native Windows application. The marketing folks and product line managers didn't like that aspect of Smalltalk. Bottom line - poor performance and a poor end-user experience killed Smalltalk for us as it did for many others at the time. You know the saying you only get one chance to make a first impression? That goes for programming languages as well. A LOT of developers gave Smalltalk a go in the early 90's and ran into these issues. Though these issues would later be resolved by then the perception damage had been done and everyone had moved on. It's interesting that Smalltalk is one of the most influential languages that never caught on.
- projektfu 6y agoDolphin Smalltalk was beautiful in this regard. Reasonably fast, native windows, easy deployment.
- cmrdporcupine 6y agoThe author seems to know (well, was involved in) the history of Self and Strongtalk but seems disappointed that the people involved went on to work on and perfect what they see as inferior technology (Java, JavaScript). In reality I think if we do an honest accounting of the situation we can see that these have been the more pragmatic engineering solutions for their times, and so that's where the $$ was. I worked in Java for years, but didn't particularly like it, but it is, I think, what the marketplace needed and could handle at the time. And I think JS/ECMAScript etc. is a reasonable practical solution for the imperfect world that evolved out of Internet/browser tech. Unlike the author I don't think Sun's fortunes would have been any different if Self/Strongtalk or some other Smalltalk-world inspired/derived tech had been pushed hard. The market didn't need or want it. IBM did a similar pivot with their VisualAge line, and they did it for pragmatic reasons. Finally, let's look at the bigger picture: in the end, what we have with the browser + modern JS on V8/SpiderMonkey etc. is a dynamic object oriented programming language that allows for dynamic manipulation of its environment, is accessible to any user, can be edited and inspected live, can present interactive media to users, and has a large community of authors. Is this really that far off from what Alan Kay and Dan Ingalls originally wanted? Purists will gag, but I think as much as I hate front end dev in JS that there's actually a lot here that is Smalltalk inspired. EDIT: I spent much of the 90s and early 2000s cringing at what was evolving. I was really into PL research and really liked the Self-inspired world of prototype OO languages. I really dug LambdaMOO and spent time writing my own shared-world multi-author persistent-world object oriented virtual machine type systems. But there's no way any of that would pay the bills. I still avoid JS work really, but I can see the niche that this filled. It's imperfect ... but that's the world. I'm grateful to V8 & friends for making it suck a lot less. And that work in V8 is a direct descendant of some of the really neat pioneering stuff in the 80s&90s. There's a good response the original article here: http://www.wirfs-brock.com/allen/posts/914 http://www.wirfs-brock.com/allen/posts/914
- kuharich 6y agoPrior comments: https://news.ycombinator.com/item?id=23301722 https://news.ycombinator.com/item?id=23301722
- Rochus 6y agoHere is the worth reading response by Allen Wirfs-Brock who "was there pretty much at the beginning": http://www.wirfs-brock.com/allen/posts/914 http://www.wirfs-brock.com/allen/posts/914
- mcguire 6y ago"And yet, today Smalltalk is relegated to a small niche of true believers. Whenever two or more Smalltalkers gather over drinks, the question is debated: Why?" "...Interaction with the outside world." This. So. Much. This. I was a (junior) member of the team that made (part of) the prototype for the OS/2 Workplace shell, in (IIRC) Digitalk Smalltalk. Doing anything outside the Smalltalk image was incredibly painful. Want to share your work with the team? File it out (and make sure you get all of it) and give the file to the Keeper of the Golden Image, who will file it in to the image. Then pass the image around. Want to send the prototype to someone who didn't have a license for a (rather useless) support library from the trainers who taught the team Smalltalk? File our code out, file it into a virgin image, run through the test suite to make sure you had everything, reimplementing anything that used that library. Shouldn't take you more than a couple of days. Did I mention this was a prototype of a GUI? Make those FFI calls using the really sketchy api. When I started, there was a bug that would randomly cause the prototype to crash. No one could ever figure out what caused it, beyond the FFI interface. At some point, it escaped the prototype and would cause the image to crash without running the prototype. Sure, Strongtalk and Newspeak may have improved some or all of everything, but by that point the bridge had been burned. Their one opportunity had been wasted. I never saw or heard of either in the wild. "The Smalltalk image provided a much better Docker than Docker." And then there's that kind of thing.