6 ms·
I think of it as one of the defining features of Smalltalk, not Lisp, although there is plenty of cross-pollination. https://en.wikipedia.org/wiki/Smalltalk#Im
by ianthehenry 5y ago
I think of it as one of the defining features of Smalltalk, not Lisp, although there is plenty of cross-pollination.
https://en.wikipedia.org/wiki/Smalltalk#Image-based_persistence https://en.wikipedia.org/wiki/Smalltalk#Image-based_persiste...
Janet's object system seems to be modeled after ideas first popularized in the Self language -- a Smalltalk derivative -- so there could be some direct inspiration there.
https://en.wikipedia.org/wiki/Self_(programming_language) https://en.wikipedia.org/wiki/Self_(programming_language)
- pjmlp 5y agoLisp systems had it first, specially Lisp Machines, that is where Smalltalk got its idea from. Xerox PARC was pursuing three workstation based OSes in parallel, based on Lisp, Smalltalk and Mesa (later evolved into Cedar). So the ideas regarding images, REPL with typo suggestions, OS wide debugging, code browser,.... were available across them all.
- lispm 5y agoLISP I from 1960. http://bitsavers.org/pdf/mit/rle_lisp/LISP_I_Programmers_Manual_Mar60.pdf http://bitsavers.org/pdf/mit/rle_lisp/LISP_I_Programmers_Man... page 67: SET card '...the state of the memory as it stands is read out onto tape 8 as the new "base" image for the memory...'
- coldtea 5y agoDamn, why don't we have programming environments with such capabilities today? (the kind @pjmlp mentioned "images, REPL with typo suggestions, OS wide debugging, code browser", etc." and so on) Not in the @pjmlp kind of availability ("Why you say that? There's this commercial language envinronment from a company in rural Austria that all of 100 companies use and all of 1000 people ever heard of that gives you exactly that! A 2-person department in the basement, right across the toilets in Jane Street uses it for something. And somebody made a weather balloon controller with it. Plus some mid-90s research team had this in some research language that has these features, that over 10K students have installed!"). Not even in the Pharo, SBCL, etc. kind of availability. It would nice to have it in the "competes with Java, C#, Python, Javascript, PHP" or at least Go and Rust, for popularity, adoption, libraries, websites and sources devoted to it, job opportunities, vendor support, enterprise adoption, and such" kind of availability...
- igouy 5y ago> Damn, why don't we have programming environments with such capabilities today? Do you use any of the image based programming environments that we do have? Pharo? VM Smalltalk?
- pjmlp 5y agoBecause those features cost money to develop, and plenty of developers nowadays want to be paid, while refusing to pay for the work of others. So you get what is possible with long nights, weekends and abandoned university thesis after graduation, instead.
- coldtea 5y ago>Because those features cost money to develop, and plenty of developers nowadays want to be paid, while refusing to pay for the work of others. Yes, but v8, Grail, the JVM, .NET takes lots of money to develop as well. Even Swift (despite Apple being stingy, so that is probably just a 5 person team force-fed Jolt Cola) costs a lot. But companies seem to pay for those, but not for those other styles/features. To be frank, even if we had this technology, but it was a closed source, proprietary affair, I wouldn't want it anyway. That's another must-have feature in 2021 - and it's not just about "not wanting to pay" (I pay for IDEA subscription, for example). It's about what such a license would mean for corporate adoption, ability to tinker with it, reliance on a single vendor, and so on.
- mumblemumble 5y agoMy take is that this feature is fundamentally at odds with how most programming languages work. For starters, I think that it's probably no accident that you generally only see these image-based development features in dynamically typed languages. For image-based development to make sense, you really want to have long-lived interactive sessions. In Smalltalk, they are effectively endless, and can span multiple decades and branch among thousands of people. In a static language, though, you've got an incentive to keep your interactive sessions short and do most of your development outside of it, because code changes inside the interactive session can lead to weird chicken-and-egg problems. Second, there are some real ergonomic challenges. It's easy to get into a state where what you're doing isn't reproducible, because there's not necessarily any paper trail on how to rebuild the current state from scratch. This is a famous criticism of Microsoft Excel - arguably the world's most widely used fully interactive development environment along these lines - and a major reason why a major project at of one of my previous jobs was to replace one department's suite of heavily scripted Excel spreadsheets and replace it with a C# application. The company was rightly concerned that they were one file corruption away from a major business disruption. Similar criticisms, albeit on a less operatic scale, are often leveled against Jupyter notebooks, which aren't quite the same thing, but to retain many relevant features.