[HN Gopher] Lisp, Smalltalk, and the power of symmetry (2014)
___________________________________________________________________
Lisp, Smalltalk, and the power of symmetry (2014)
Author : behnamoh
Score : 55 points
Date : 2022-05-29 19:58 UTC (3 hours ago)
(HTM) web link (insearchofsecrets.com)
(TXT) w3m dump (insearchofsecrets.com)
| didibus wrote:
| I'm not sure that objects are data, depending on how data is
| defined, and I'd like to link to a very interesting discussion
| between Alan Kay, one of the creator of Smalltalk and Rich Hickey
| creator of Clojure (a lisp), discussing between themselves the
| merits of data and the meaning of data:
| https://news.ycombinator.com/item?id=11945722
| layer8 wrote:
| Objects, as seen from the outside, are entities with an
| identity and with behavior (hopefully associated with some
| interface contract). In addition, state may be part of the
| observable behavior of objects (and of their internal
| implementation). Data has no identity and no behavior, it is an
| immutable value. (Mutable data structures are actually
| objects.) Of course, you can realize objects in terms of data
| (e.g. machine code is data, and state is commonly represented
| by data), and conversely you can create objects that behave
| like data (like an immutable data structure), that is, realize
| data in terms of objects. That doesn't mean that objects are
| data or vice versa.
| dgb23 wrote:
| I also thought about the same issue, the term "data" was used a
| bit sloppily in the article. Similarly the quote from pg
| explains programming Lisp as manipulating ASTs, which isn't
| true in a strict sense, more precise: you manipulate a
| representation that is much closer to an AST.
|
| But I don't think these make the larger points any weaker.
| dang wrote:
| Discussed at the time:
|
| _Lisp, Smalltalk, and the Power of Symmetry (2014)_ -
| https://news.ycombinator.com/item?id=14333157 - May 2017 (58
| comments)
| sillysaurusx wrote:
| Any chance we could hear you talk about Lisp for a bit? I
| learned a lot from your thread-local comment:
| https://news.ycombinator.com/item?id=11240681
|
| I was hoping you've stumbled on more ideas in the subsequent
| years. It's surprisingly hard to come up with simple + general.
|
| Ever since you mentioned thread-locals, I've been seeing the
| pattern everywhere. Our current C++ codebase passes around a
| "Chip" object (basically, a global configuration holding the
| current settings for the compiler), and it's remarkable how
| many lines of code it ends up touching.
|
| And it's not so easy to port your idea to C++ using
| thread_local. It turns out that Racket thread cells !=
| thread_local storage. The key difference is that when you spawn
| a new thread, the new thread needs to _inherit the current
| value_ -- thread_local doesn 't automatically give that!
|
| And storing the current "Chip" as a global doesn't quite work
| either. If we spin up two different compilation threads for two
| different chips, each thread needs to see its own Chip
| independently of the other. We sidestep that for now by
| explicitly passing a Chip to any new threads, but it's not a
| general solution like your idea was. The moment I realized
| that, I thought wistfully about your comment from 6 years ago,
| and I've wanted to bug you ever since for "more like that,
| please."
| mathgenius wrote:
| I have this idea that the dichotomy between functional &
| imperative (OOP?) programming is the "same as" the dichotomy in
| mathematics between algebra and geometry. Some more discussion of
| this here [1].
|
| [1] https://www.quora.com/Why-is-functional-programming-seen-
| as-...
| dgb23 wrote:
| Even in a somewhat flexible language like JavaScript, it is often
| painful when you are limited by the lack of this kind of
| flexibility. The code is _right there_, you can look at it, but
| you cannot do anything with it. (Exceptions exist where an API
| provides a sane data representation but that is rare.)
|
| As a JS programmer by day and a Clojure hobbyist it feels like
| being a ghost in one of these movies, where they cannot interact
| with the world directly anymore. It's very frustrating. I
| sometimes think about all of the unnecessary work that is being
| done, the proliferation of libraries, tools and "transpilers"
| just because we lack this basic thing.
|
| I have never played with Smalltalk or some of its dialects or
| descendants. But judging from articles like this one, I have the
| feeling that I will end up liking it and then feel even more
| constrained by mainstream languages.
| smackeyacky wrote:
| As a former professional Smalltalk developer, I would caution
| against the experience of greybeards who wax lyrical about the
| incredible power of Lisp and Smalltalk, because even in their
| heyday that power was largely illusory.
|
| Firstly, anybody who encountered these environments early in
| their career will always be misty eyed about them.
|
| Secondly, ask them how big the team was they were working in and
| what the mechanism was they were using to deploy their programs.
| Smalltalk in particular is particularly difficult to package up
| into a deployable program that somebody else can run, and
| collaborating on development is fraught with code sharing issues
| you just don't get with less exciting environments like .NET or
| Python or Javascript/Node.
|
| In a modern context, Smalltalk and Lisp make little to no sense,
| especially when you have available a rich system of code being
| shared in more prosaic environments. It's a modern miracle that
| you can build what you need without re-inventing the wheel. There
| is no better time to be a programmer than now.
|
| Lisp and Smalltalk may well be great for reinventing wheels, for
| writing un-readable self modifying code and as a challenging
| intellectual exercise, but all your productivity just went out
| the window.
| rscho wrote:
| > Lisp and Smalltalk may well be great for reinventing wheels,
| for writing un-readable self modifying code and as a
| challenging intellectual exercise, but all your productivity
| just went out the window.
|
| This assessment seems very unfair to the current environments
| of both languages. Perhaps you ought to delve in a second time?
| mtlmtlmtlmtl wrote:
| This is a very insightful comment, thank you. I have much the
| same experience from the Lisp of side of things.
|
| I will say though, these languages have their niches where they
| really shine.
|
| The oft understated power of Lisp is in creating software that
| is infinitely configurable assuming you know a bit of Lisp.
| Extensions are a first class citizen in Lisp programs. The
| configuration is just some lisp code that's compiled into the
| running program upon loading. The config can even redefine
| existing functions. One time I used the config file to fix an
| actual bug in a program that was abandoned by the maintainer.
| Of course, only programmers want this functionality, and so its
| usefulness is limited to things like Emacs. But it still has
| its place.
| neilv wrote:
| Sounds like you're evaluating software configuration management
| for Smalltalk from before that was hardly a thing for any
| development platform?
|
| Decades ago, Smalltalk implementations would let you dump some
| part of a system (say, the part that held your application) to
| a human-readable ASCII file (which is pretty Git-able), and
| also load that. If you were using it today, while we're using
| Git, I can't think of a reason a Smalltalk system couldn't have
| more tight integration with Git.
|
| Regarding Lisps, I'm not sure which school of thought you're
| coming from, but there are multiple. To someone without
| firsthand experience, the things you might've heard someone
| say, like "Foo is great because code and date are the same darn
| thing", or "Foo is great because it's dynamic up the wazoo",
| not only aren't necessarily the strengths that others would
| claim, or they might not mean the same thing.
|
| For example, imagine some kinds of syntactic extension in
| Lisps, in which some region of syntax isn't a function call.
| The region is clearly delimited, and it has an identifier right
| there that can be looked up to tell you the behavior. Someone
| without experience with that, but who has used an unfortunate
| kind of "DSL" in some other language, or, worse, has
| experienced surprise "operator" overloading in a different
| language, or who's seen unfortunate choices of when to
| introduce languages and when not, might think this Lisps thing
| is more of the same thing, when it's not.
| smackeyacky wrote:
| Envy/Developer was in heavy use where I worked, and it was
| pretty great but still nothing like the packagement
| management tools we now have.
|
| I'd say the change log in something like VisualWorks was
| definitely not git-able in any way that would facilitate
| merging of several developers code. In fact it was extremely
| difficult to keep images in sync without something like
| Envy/Developer.
|
| Lisp to me is like a fascinating fossil.
| neilv wrote:
| When I used VisualWorks Smalltalk in the early '90s, you'd
| use a menu item to write a human-readable ASCII
| serialization of some part of the system (not changelog) to
| the host filesystem. And it'd be diffable and mergeable and
| loadable.
|
| Doing Git with just that seems only a little different than
| what we'd do with a collection of source files today in
| some other language, including branches and merges.
|
| At the same time, one commercil site I worked at was doing
| its SCM for C code using kludge scripts over SCCS to an NFS
| volume. The next was putting C and C++ into Apollo DSEE and
| making SPARCstations jump through hoops to use that
| (because ancient DSEE on some Apollo DN10ks for SCM and
| CI/CD was better than the state of the art almost everyone
| else was using) and my advanced R&D group had just gotten
| DSEE-descendant Atria ClearCase for greenfield work in C++
| from our Sun and HP workstations. The next site was using
| some dumpster fire of `.BAT` scripts over Perforce(?) for
| Windows NT-dominated C++ development.
|
| I'd say VisualWorks Smalltalk's wasn't the problem for team
| development at the time. The state of practice of
| everything else was more the problem.
| Jtsummers wrote:
| Pharo, at least, has very tight integration with git via
| Iceberg. Other variants have had (not from personal
| experience, only reading what others wrote) very good or at
| least decent (that is, no worse than the rest of industry)
| version control at least back to the 90s.
| protocontrol wrote:
| Although it's true that today it is easy for everyone to write,
| even those who have no experience or have had a disappointing
| experience, the effects of what they write are often not
| measurable. That is, it is easier to measure the resources
| needed to write than to measure its effects.
|
| Smalltalk is a tool for the creative spirit. It's a very
| powerful tool for those who have something inside and want to
| develop it. On the other hand, nowadays, the alternatives that
| are massively propagated have other characteristics. They are
| for those who feel better (or calmer) absorbing what someone
| else has done. They are for those who hide behind the phrase
| "it is better to ride on the shoulders of others" trying to
| show wisdom, but in reality revealing dependency and
| unproductivity.
|
| The problem with Smalltalk is that in computing, the "creative
| spirit" is a dying breed. Smalltalk is for the creative. Most
| think that creating is expensive and settle for copying
| (imitating) or using (claiming to re-use!).
|
| Whoever thinks someone has something to contribute, let him use
| a Smalltalk, whoever doesn't, let him buy the latest.
| smackeyacky wrote:
| Contribute to what? If you have something that is
| fundamentally difficult to share (like a Smalltalk image)
| what are you contributing to other than entropy?
| dgb23 wrote:
| A provocative quote from the article:
|
| > Languages such as Java, C++, and even Python seem to think that
| "object-oriented" means mostly "classes and inheritance." Which
| is sort of like saying that "driving" means mostly "buttons and
| pedals."
| trashburger wrote:
| It's true. The aforementioned languages not only boil down
| Smalltalk's object system into a basic "code sharing" scheme,
| they also perpetuate the unnecessary class and instance
| dichotomy. There is no reason an "instance" cannot be a "class"
| by itself. Self (a successor to Smalltalk) gets rid of this
| dichotomy by assuming a prototype-based object system instead
| of Smalltalk's classes. In Self, a prototype can be copied and
| that copy can then be used as its own prototype (this is used
| heavily in its UI toolkit Morphic).
___________________________________________________________________
(page generated 2022-05-29 23:00 UTC)