[HN Gopher] Design Principles Behind Smalltalk (1981)
___________________________________________________________________
Design Principles Behind Smalltalk (1981)
Author : joubert
Score : 118 points
Date : 2020-06-12 07:07 UTC (1 days ago)
(HTM) web link (www.cs.virginia.edu)
(TXT) w3m dump (www.cs.virginia.edu)
| saadalem wrote:
| What if all Smalltalk objects had an URL? It could provide simple
| (and complex) network services to any computer on the Internet.
| There is a profound lack of ambition around software and
| Operating Systems.
| jasim wrote:
| If you're tired of hearing about the virtues of Smalltalk (like I
| was at one point) and ask "if it is so good, why isn't it
| popular?", then watch @deech's talk (Aditya Siram) - "What FP can
| learn from SmallTalk" -
| https://www.youtube.com/watch?v=baxtyeFVn3w
|
| I think it is the most accessible explanation of the marvel of
| Smalltalk, for those who were not lucky to work with it during
| the late 80-90s.
|
| Also I think Ruby is the mainstream language that is closest to
| Smalltalk today, with the idea that everything is an object and
| late-binding as much as possible.
|
| One thing I can't help point out is that Smalltalk / Alan Kay's
| vision of interconnected objects forming a recursive computing
| system is not the only "true" vision of OO out there. From Simula
| thru C++ and then Java and C# also are object-oriented (or class-
| oriented for those who care about the distinction), but they are
| statically typed. It is also OO because OO is a word, not a
| mathematical definition, and when people talk about OO, there is
| enough similarity between all these variations that we consider
| all of them to be in the same camp. Plus with the growing move
| towards strict static typing even in interpreted languages, which
| I think is driven by actual industry needs and programmer
| preferences than external marketing, it is becoming a disservice
| to think of statically typed OO languages as being somehow
| inferior to the true ideal of object-oriented programming.
| cxr wrote:
| At the risk of putting readers off by the title, there's a
| video essay on YouTube called "Object-Oriented Programming is
| Bad"[1]. It's both thoughtful and thought-provoking, although I
| don't agree with the conclusion. Steve Naroff (from
| Stepstone/NeXT/Apple) did a recent-ish set of interviews with
| the Computer History Museum[2][3] and referenced that video a
| bit (and extemporized about objects in small parts throughout).
| Side note: Naroff and Brad Cox are set to present a paper on
| Objective-C at this year's HOPL[4]. I wish it were as readily
| available as Allen Wirfs-Brock's JS paper for the same
| conference[5][6].
|
| 1. https://www.youtube.com/watch?v=QM1iUe6IofM
|
| 2. https://www.youtube.com/watch?v=ljx0Zh7eidE
|
| 3. https://www.youtube.com/watch?v=vrRCY6vwvbU
|
| 4. https://hopl4.sigplan.org/track/hopl-4-papers#List-of-
| Accept...
|
| 5. http://www.wirfs-brock.com/allen/posts/866
|
| 6. https://zenodo.org/record/3707008#.XtoRR-TEklQ
| panic wrote:
| The HOPL paper is available here:
| https://dl.acm.org/doi/abs/10.1145/3386332 (the PDF link even
| works without an institutional login!)
| cxr wrote:
| Thanks a ton! Earlier this week it didn't look like it was
| available. https://news.ycombinator.com/item?id=23436517
|
| Looks like there's another Smalltalk paper, too:
|
| https://dl.acm.org/doi/abs/10.1145/3386335
| Konohamaru wrote:
| OO was the best programming paradigm until people recognized
| the power of concurrency. Even in the usecase of GUI
| programming, where OO is supposed to shine the brightest, OO is
| a failure because interactive programs are extremely
| concurrent. Even back then when everything was executed in
| serial GUI frameworks were designed concurrently in crummy
| languages never designed to support concurrent programming such
| as C. Or worse, C++.
|
| And functional programming is no good __as a general
| programming paradigm __because:
|
| 1. Little of computing--almost nothing--is declarative. That
| means functional programming's non-general by definition.
|
| 2. Programming cannot be married to mathematics despite what
| formal proof proponents and people who think naming their
| language "Pascal" is a good idea think. It will always be an
| arranged and sham marriage.
|
| 3. Thinking being able to easily execute your declarative
| programs in parallel means you'll never have to think
| concurrently and can just outsource everything to Hadoop only
| means you can't understand the difference between parallelism
| and concurrency.
| discreteevent wrote:
| OO has had most success in GUI programming. As for
| concurrency, Erlang seems to do ok and its creator called it
| "possibly the only object-oriented language"
| jcelerier wrote:
| > Even in the usecase of GUI programming, where OO is
| supposed to shine the brightest, OO is a failure because
| interactive programs are extremely concurrent. Even back then
| when everything was executed in serial GUI frameworks were
| designed concurrently in crummy languages never designed to
| support concurrent programming such as C. Or worse, C++.
|
| I must say that I have trouble reconciling this with the fact
| that every single GUI program running on my computer right
| now is written mostly in C++ with a bit in C for my WM and a
| bit of Rust for Firefox.
| jbverschoor wrote:
| Messagepassing and poking around in objects is awesome.
|
| But more from a user developer point of view. Power user..
| power users aren't here anymore
| throwaway_pdp09 wrote:
| > OO was the best programming paradigm
|
| No, it depends on what you're doing. Always does, always
| will.
|
| > Even in ... GUI programming, ... OO is a failure because
| interactive programs are extremely concurrent
|
| Seems to work well for me on windows. What's the problem
| precisely?
|
| > And functional programming is no good as a general
| programming paradigm because ... Little of computing--almost
| nothing--is declarative
|
| That's just wrong.
|
| > Programming cannot be married to mathematics...
|
| You give no evidence despite it being a long association.
|
| > Thinking being able to easily execute your declarative
| programs in parallel means you'll never have to think
| concurrently
|
| Yes, because concurrency only becomes an obvious issue when
| state is involved. So FP sidesteps that by not having
| interacting state. I have some criticisms of FP but this is
| plain silly.
|
| You're just dissing stuff here. It's annoying.
| Konohamaru wrote:
| > Little of computing--almost nothing--is declarative...
| That's just wrong.
|
| * Artificial general intelligence * Operating systems *
| Video games * Emulators for hardware * Interpreters *
| Debuggers * Word editors * Image editors * Graphical user
| interfaces * Robotics * Web browsers * Servers
|
| Basically everything that makes computing interesting is
| non-declarative and concurrent. Financial math on K street,
| parser combinators, and SQL queries are the declarative
| segment of programming.
| throwaway_pdp09 wrote:
| OK, good comeback. It's forcing me to be precise.
|
| Declarative/imperative are models, not necessarily
| implementations (although they often are treated as model
| x = implementation x). You need to separate the two
| conceptually, but in implementation you can do both.
| Anything you can do declaratively you can do imperatively
| and the reverse.
|
| As such it makes it meaningless to say that almost
| nothing is declarative because how you choose to create
| it is a choice. How well it runs is another matter
| because real hardware is relentlessly state-y, but that's
| an implementation issue. And that's fine, and sometimes
| imperative stuff is just cleaner.
|
| But you can write a web browser or a GUI or whatever
| declaratively, but underneath it will be imperative
| because that's hardware.
|
| Declarative vs imperative is a choice, not necessarily a
| 'natural' thing, (depending on the problem, I'd say a web
| page renderer is distinctly stateless - take some static
| HTNL, render it, where's the state?). A web server can be
| stateless too, a request comes in, a web page goes out. I
| need someone else to speak for others, pretty sure
| stateless GUIs have been written.
|
| Any big data cruncher that works on petabytes, purely
| with output coming from input deterministically is
| effectively stateless.
| jolux wrote:
| Nothing _is_ declarative or imperative outside of a
| certain implementation of a solution. All of the things
| named trivially have declarative solutions because of
| Turing completeness. Whether or not a paradigm lends
| itself easily to something is a bit of a different
| question, but I think a lot of people tend to say "oh,
| that's obviously stateful and imperative" merely because
| they haven't thought about the problem in a different
| way.
| Konohamaru wrote:
| Turing machines only model mathematical functions. They
| cannot model anything on my list. That's why computer
| scientists invented I/O automata in an attempt to build a
| theoretical model that handles some of those items on my
| list.
|
| > "oh, that's obviously stateful and imperative" merely
| because they haven't thought about the problem in a
| different way.
|
| No I am not a conventionalist.
| throwaway_pdp09 wrote:
| > Turing machines only model mathematical functions. They
| cannot model anything on my list.
|
| Since turing machines are turing complete, and existing
| general purpose CPUs are turing complete, this is
| trivially incorrect.
|
| > That's why computer scientists invented I/O automata
| ... those items on my list
|
| wat?
| nextos wrote:
| Ruby is a joy to use and relatively close to Smalltalk in many
| many ways.
|
| I wish Ruby had taken Python's spot. When Rails exploded ~2006,
| I thought it'd become a mainstream language. But sadly it has
| never been very popular for non-web things, if we exclude
| Japan.
|
| One reason is probably that the standard Ruby implementation
| (MRI) was really slow till recently. Smalltalk, on the other
| hand, had extremely good VMs that served as embryo for the JVM.
|
| I've used Ruby for many big projects (but never used Rails!)
| and it has scaled really well for large and exotic things such
| as abstract interpreters.
| codetrotter wrote:
| Speaking of Ruby, there is this book that I read a few years
| ago (five years ago, in fact - time flies), that was using
| Ruby when explaining the things it was talking about.
|
| Personally I don't use Ruby and prefer Python instead, but
| the book was very enjoyable nonetheless so I would recommend
| that book to anyone, even to people like me who don't really
| like Ruby in general and don't really want to read or write
| Ruby in general.
|
| Stuart, T., 2013. Understanding Computation: From Simple
| Machines To Impossible Programs. O'Reilly.
|
| Book website: https://computationbook.com/
| joshhogg wrote:
| This books looks super interesting. Did you find any of it
| applicable to particular problems you are working on or was
| it good general knowledge?
| codetrotter wrote:
| As good general knowledge yes
| AdieuToLogic wrote:
| Another good "non-rails" Ruby book is "Enterprise
| Integration with Ruby"[0]. Unfortunately, it's a bit dated
| (2006), so I am sure some of what Schmidt details is no
| longer supported/valid. Still, a cool book IMHO.
|
| 0 - https://www.amazon.com/Enterprise-Integration-Ruby-
| Maik-Schm...
| radiowave wrote:
| Smalltalk prizes interactivity, in the manner that arises from
| being able to make small, incremental adjustments to code while
| it (and it's state) remain in memory.
|
| Its rejection of static typing is not axiomatic, merely an
| expedient way of achieving those interactivity goals. Could the
| two things be reconciled? I don't know, but I think at least
| that it shouldn't be _unthinkable_.
|
| As an aside, static type systems which can be mutated during
| runtime are astonishingly commonplace. They're very crude, and
| tend to be called "relational databases", and doing those
| mutations is a major pain because in spite of all that's
| elegant about relational algebra, actual SQL is a fucking
| abomination. (And this is coming from a full-on Postgres
| fanboy.)
|
| On your comment about the similarity of Ruby, I know what you
| mean, and yet I regard Ruby as being basically _nothing_ at all
| like Smalltalk. That 's because I'm principally thinking in
| terms of the development culture, tools, and working practices,
| and _not_ thinking in terms of the implementation of the VM or
| the object model, or the names of certain methods.
|
| So similarity between languages is a tricky thing to nail down,
| not least because in the case of a gestalt system like
| Smalltalk, "programming language" is actually a tricky thing to
| nail down.
| AdmiralAsshat wrote:
| I'd be much happier if someone could instead just provide a
| version of Smalltalk that everyone can agree on.
|
| "Use Squeak!"
|
| "No, Squeak is old! Use Pharo!"
|
| "Pharo doesn't adhere to the Smalltalk standard. Just use gnu-
| smalltalk in a terminal!"
|
| Never have I seen such a self-defeating community. If the
| Smalltalk community wants it to be anything more than a
| historical curiosity, I beg it to form some kind of standards
| committee and agree on a common implementation so that I can
| _learn_ Smalltalk without worrying that I 'm studying a dialect
| that is not mutually intelligible to the other implementations.
| radiowave wrote:
| Ah, you mean like a version of Python that everyone can agree
| on!
|
| Joking aside, it's an entirely understandable sentiment, but
| Smalltalk is not only an old language, but also one that
| lives in a symbiotic relationship with its tools (which defy
| the normal notions of language standardisation).
|
| As things stand, if you want a standard, what you're likely
| to get is a time-capsule. Pharo in particular does _not_ want
| to be a time-capsule, and while it 's certainly been a source
| of frustration to me that Pharo has existed in such a state
| of flux for so much of its life, I understand that the change
| is necessary, and I remain cautiously hopefuly about the
| direction they're taking.
|
| I'm not a daily user of Pharo, so while I have a rough idea
| that it _is_ becomming more settled as time passes, I 'm not
| an authority here.
| jecel wrote:
| The Smalltalk community is an artifact of the pre-Internet
| days. See Forth or Lisp for the same result. Communication
| was slow, in the form of publications and you couldn't get
| your hands on actual code (which probably wouldn't run on any
| of your machines anyway).
|
| See the many Unix clones before Linux. The difference is that
| Linux came along when you had GNU code to avoid having to
| implement ls, ps, etc yourself, you had many people with 386
| PCs and you had the Internet to work together without having
| to be all in the same room (not to mention not having to set
| up a company to sell CD-ROMs, though other people did that
| for Linux).
|
| By the time languages like Python and Ruby came along it was
| a different world and they could be more Linux-like in terms
| of community and less
| QNX/Coherent/Idris/BSD/Irix/AIX/Solaris/...
|
| Putting a splintered community back together is not an easy
| task.
|
| Note that Squeak, Pharo and Cuis deviate from the ANSI
| Smalltalk standard in the same ways (Traits, {....} syntax
| for runtime collections).
| Viliam1234 wrote:
| > No component in a complex system should depend on the internal
| details of any other component.
|
| Unfortunately, the internal details of other components are
| important for performance. It is not enough to know that
| something is e.g. an ordered collection; I also need to know
| whether accessing items randomly has an O(1) or O(n) cost.
| Increasing the complexity from linear to quadratic is not a minor
| detail that a faster processor would solve.
|
| But when you start caring about performance, suddenly you don't
| deal with ordered collections, but with arrays, linked lists,
| red-black trees, and whatever. Then you also get unspecified
| ordered collections returned from other modules, and you wonder
| whether it is okay to use them as they are, or whether you should
| pay a one-time price to convert them to a more efficient
| collection. And somewhere, a new programmer is crying: "I just
| wanted to create a list containing dozen numbers, why do I have
| to deal with all this complexity?"
| jbverschoor wrote:
| What I miss these days is interaction with applications. Yes,
| rest-APIs are fun and all. And both Apple and Microsoft have
| their component model out there, but other developers don't take
| the time.
|
| That, combined with the Superbad tools of patching things
| together make it almost useless these days.
|
| It's unfortunate, because there's so much you can do with good
| interoperability.
| madmaniak wrote:
| Principle 1 "If a system is to serve the creative spirit, it must
| be entirely comprehensible to a single individual."
|
| Globally we go in every aspect against this principle going into
| narrow specialisations. Such a movement is made on a purpose by
| the flow of money of central printers/powers, and the result is
| according to the principle - luck of creative spirit of single
| individuals. The tools which we are learning and the way we are
| trained is against creativity.
|
| In last 10y perspective is visible how the industry is mislead in
| wrong directions by the biggest players. So don't ask why we
| don't use Smalltak-like technology in 40y.
| coliveira wrote:
| To expand on your comment, the reason why we don't use simple
| and understandable tools like Smalltalk is that the industry is
| not interested on this kind of simplicity. For them it is much
| better to pay thousands of people to work on different,
| unrelated things and them put these things together at all
| levels: hardware, OS, software, etc. The resulting system is
| impossible to understand by a single person, and works only
| because of the continuous struggle of thousands of people to
| make it work. But this is positive for the industry behind this
| architecture: every year they will create new components to fix
| flaws, introduce new ones, and keep the wheel of the technology
| industry running.
| carapace wrote:
| VPRI (Alan Kay's research institute) had a project called STEPS
| that's worth looking into. "From the desktop to the metal in
| 20,000 lines of code." They pretty much did it.
| coliveira wrote:
| Smalltalk can be described concisely as a graphical UNIX: a small
| set of computational mechanisms, designed to be general and
| interoperate for the construction of larger systems.
| Unfortunately, the GUI industry was inspired but never decided to
| use smalltalk itself as its foundation since C/UNIX already
| existed, providing higher performance for the hardware available
| at the time.
| d3ckard wrote:
| Very interesting read, though it hurts me to see optimism in this
| paper mostly unwarranted from today's perspective.
| shawnz wrote:
| Was it unwarranted?
|
| > While the presentation frequently touches on Smalltalk
| "motherhood", the principles themselves are more general and
| should prove useful in evaluating other systems and in guiding
| future work.
|
| Indeed the principles of Smalltalk went on to guide the design
| of many future languages
| mucholove wrote:
| The best Smalltalk is Objective-Smalltalk.
|
| It's a beautiful way to go up and down the ladder of inference.
|
| Basically--Objective-Smalltalk is based on Objective-C which is a
| superset of C. It's like having the two worlds coming together at
| the same time.
|
| Does it miss some of the beauty of a totally integrated system
| like Squeak? Sure. But that's kind of the beauty too. Can we make
| an Objective-Smalltalk takeover?
|
| http://objective.st
| cxr wrote:
| I was recently re-watching the old demo of 280 North's Atlas,
| an Interface Builder-inspired tool. And when I think about it,
| it also seems a little strange that object lovers and all
| today's disaffected Mac fans could pick up the pieces of
| GNUStep and start building out a usable replacement for
| themselves as a reaction against the deterioration and
| inevitable demise of the Mac, but that isn't materializing.
| There's something, I think, in the Mac developer psyche that
| says they're responsible for building their own discrete little
| apps and doing a lot of polishing on them, but they're
| completely uninvolved in shaping or otherwise working on the
| environment/platform itself. This is the difference between Mac
| folks and Smalltalkers.
|
| https://vimeo.com/11486446
| mucholove wrote:
| Necessity is the mother of invention! If the demise of the
| Mac / Cocoa API's is nigh--expect there to be some work on
| it.
|
| This guy is doing some interesting work: https://mulle-
| objc.github.io
|
| One more factor: my guess is that GNUstep picked the LGPL--
| which although more permissive than the GPL--turns away the
| money / status seeking Mac folks.
| cxr wrote:
| GNUstep being LGPL has as much adverse impact on developers
| as Apple's implementation being proprietary. (I.e., none.)
| It's the _LGPL_ after all, not the GPL.
|
| GNUstep has also moved to GitHub and seems to favor the the
| MIT license nowadays where possible (e.g., libobjc2)[1][2].
|
| 1. https://github.com/gnustep/libobjc2
|
| 2. http://etoileos.com/dev/licensing/
| e12e wrote:
| Always thought the ideas behind lively kernel was interesting -
| web browser/js engine as the run time, webdav as the persistence
| layer.
|
| https://lively-kernel.org/
|
| Looks like they are on the third iteration now:
|
| https://github.com/LivelyKernel/lively4-core
|
| https://lively-kernel.org/lively4/lively4-core/start.html
|
| Apparently now using git for persistence.
| ChrisMarshallNY wrote:
| Smalltalk became Objective-C.
|
| Objective-C has informed Swift.
|
| Long live Smalltalk.
| wool_gather wrote:
| If Swift didn't have a non-negotiable -- because of its
| deployment on Apple platforms -- requirement for strong interop
| with ObjC, I firmly believe it would have been even more like
| Rust than it already is.
|
| The flexibility that's enabled directly by ObjC's simplicity is
| just not a goal for Swift.
| ChrisMarshallNY wrote:
| I've never encountered a language as flexible as Swift.
| ibiza wrote:
| Each link in this lineage is tenuous. Objective-C took
| Smalltalk's call syntax, its class def (in a sense?), and its
| late fn binding, but little else. It certainly didn't take what
| made Smalltalk, Smalltalk. Full disclosure: I really like
| _both_ languages.
|
| I struggle to find the mapping between Objective-C and Swift,
| other than "same company" and must preserve backwards
| compatibility.
|
| Smalltalk became Squeak. Long live Squeak. :)
| ChrisMarshallNY wrote:
| I think that Swift got a lot of its "philosophical" structure
| from ObjC.
|
| After Swift was released, I understood why ObjC 2.0 was
| written the way that it was. It was modified to allow the
| standard libraries and SDKs to transition to Swift.
|
| I remember coming from C++ (CodeWarrior/PowerPlant), and
| encountering ObjC, and going "Whiskey Tango Foxtrot?".
|
| After a while, though, I got used to it, and actually started
| to enjoy ObjC, in a way that C++ never got me.
|
| I enjoy Swift, even more.
|
| After years of writing code in languages I didn't really like
| (C++/PHP), Swift is something that I actually enjoy. I
| suspect that Smalltalk, and its affect, are responsible for
| the "enjoyment" factor of Swift.
|
| I consider most of the lineage to be "in spirit," more than
| "in detail."
|
| It's quite easy to shoot holes, if we get particular.
| superdisk wrote:
| Swift basically stripped out what was left of Smalltalk from
| Objective C.
___________________________________________________________________
(page generated 2020-06-13 23:00 UTC)