Hacker News Comments on
"Liberating the Smalltalk lurking in C and Unix" by Stephen Kell
Strange Loop Conference
·
Youtube
·
162
HN points
·
3
HN comments
- This course is unranked · view top recommended courses
Hacker News Stories and Comments
All the comments and stories posted to Hacker News that reference this video.⬐ macintuxWorth noting: Alex Miller has announced next year will be the last Strange Loop conference. If you’ve never been, I can’t recommend it highly enough.⬐ Ygg2⬐ jhbadgerDamn shame. Why is it stopping?⬐ macintux⬐ bhrgunathahttps://mailchi.mp/thestrangeloop/strange-loop-2021-cfp-5896...That's a blow, it's such a good conference. This post led me to check and the 2022 videos have started being uploaded to youtube:https://www.youtube.com/playlist?list=PLcGKfGEEONaDO2dvGEdod...
In case anyone is interested in the actual system that Kell talks about, liballocs, it is still being developed eight years later and is on github at:⬐ chasilSmalltalk was originally a language for children, similar to Logo.It is unfortunate that its youth was not thus preserved.
"Smalltalk was created to investigate teaching programming to children. Understandably, it's a very small and simple language, the simplest of the major programming languages."
https://www.codeproject.com/Articles/1241904/Introduction-to...
⬐ AnimalMuppet⬐ retrocryptidIn what sense is Smalltalk smaller than Lisp?⬐ zelphirkaltSmalltalk only has 6 keywords and everything is done via sending messages to objects. How many language constructs and keywords does Lisp have?Ultimately different philosophies are at work. Smalltalk makes many objects and has the power to introspect on them (classes are also objects), Lisp has facilities to introspect and do meta programming using macros, making new keywords, so of course the language will grow. That is the whole point. Growing a language for solving specific problems. Smalltalk makes new objects instead.
⬐ anthk⬐ ergonaughtR5RS Scheme? It's not so big. Common Lisp, OTOH...⬐ MonkeyClubI think the OP is referring to the pseudo-variables, true, false, nil, self, super, and thisContext:https://en.wikipedia.org/wiki/Smalltalk#Syntax
I don’t think they count.
If we’re counting small numbers, Lisp also has a small number of “keywords”, nine:
Others put this number at five or seven. I guess you can express define as a function of label and lambda, so you drop to eight, but I don’t know how you get to seven, let alone five.quote atom eq cons car cdr lambda label define⬐ zelphirkaltNot sure how Smalltalk measures up in that regard, but wouldn't one also need to count things like define-syntax and all things, which are built-in for defining macros? I guess that would only be fair, because that gets Lisps up to the same power level as Smalltalk with its introspection and ability to create classes at runtime, since they are objects as well.Then there are things like "What is the syntax for a vector?" and all kinds of reader syntax with "# + something", depending on the dialect/specific lisp language, I guess.
EDIT: Found this: https://wiki.c2.com/?SmalltalkSyntaxInaPostcard
⬐ MonkeyClubGah, silly me -- I forgot 'cond'!Just throw that into the list, and ditch define.
⬐ mtlmtlmtlmtlCons, car and cdr can be defined in terms of lambda, though it's not exactly an efficient implementation:(define (cons x y) (lambda (f) (f x y))) (define (car c) (c (lambda (x y) x))) (define (cdr c) (c (lambda (x y) y)))⬐ MonkeyClubEfficient or not, it's very pretty, I love its self-referential house-of-cardiness :)The claim in the quote is that Smalltalk is the simplest, not the smallest. That may only beg the question, but yay clarity.⬐ chasil⬐ bumblebritches5If we still had a language as simple as Logo, but as powerful to express objects to a young mind, would be a beautiful thing.We should strive for such simplicity.
⬐ qsortLua? Seems to be working fine in stuff for young people, e.g. Roblox.⬐ alisonatworkWren seems pretty simple to me: https://wren.io/None⬐ chasilHeck, I don't know!I just wish these languages preserved their sense of ingenuity and wonder, before putting on the iron maidens of their frameworks.
I wish there was a C for children, but explaining indirect addressing and the evolution of indexed pointers is a bridge too far.
⬐ coderddHaving read the book Dealers of Lightning about Xerox PARC and Kay,I think Smalltalk 72 was the original smaller simple language, with which children were taught.Then others at Xerox added more professional stuff, the kind programmers would want, which resulted in Smalltalk 76 and so on. These were not as approachable for children anymore allegedly.
Nowadays there's Squeak which is a Smalltalk implementation, which influenced Scratch I think (first version of Scratch was written in Squeak).
Search the internet for Adam Kay's documents on Squeak and educating children, helps to put on context what he had in mind (if you, like me, just install Squeak and expect a stunning tutorial... it's not like that, at least I didn't find).
Kay also said, having an IDE only takes you to the 70s from the 60s too... So there's work to be done yet.
⬐ rileyphoneThere's even a pretty fun documentary on the Squeak project, with Seymour Papert, Alan, and Jerome Bruner. [0] Or, if you want to go further back, read the original "Personal Dynamic Media" papers.Interesting, sure, but isn't this just reinventing image-based development from Smalltalk, FORTH and Lisp Machines?(Don't get me wrong. I think the kid's onto something. Just why only look at Smalltalk? Plenty of other image-based systems from the 70s and 80s.)
⬐ adamnemecekI really can’t wait for the time when something replaces Unix, C, and Smalltalk culturally.⬐ bitwize⬐ anthkRust (and Redox).⬐ keyleOk, I'll bite. What is wrong culturally with our computing history/culture?⬐ adamnemecekIt’s just beating a dead horse. It’s been 50 years dudes. Maybe it’s time to come up with something better.⬐ coderddNot saying I align 100% with this, but certainly gives a perspective on Unix and C: https://www.jwz.org/doc/worse-is-better.html⬐ justoreplynice link (if you are clicking it directly) :)⬐ teddyhBetter link (from the actual author of the text, and without referrer tricks for links from HN): https://dreamsongs.com/RiseOfWorseIsBetter.htmlI would like Smalltalk if I could export the image to an standalone r/o application with ease.⬐ jecel⬐ nishikantamajhiDigitalk's Smalltalk V was pretty good at this. You got a nearly empty v.exe file which called a bunch of .dll files which contained the various parts of the standard image. Anything you did yourself would be added to v.exe so when you were ready to ship you just had to send the client that plus a subset of the .dll files (enough for your application to run, but not the development environment).For a short while in the 1990s Smalltalk V/Win was available at no cost with the name Smalltalk Express.
Hii⬐ spindleI love this video!I'm sad to say that it has nothing at all to do with Smalltalk.
Its topic is an attempt to make all programs that run in Linux (and similar systems) able to access each others' data structures, including each others' functions, using new work built on the debugging facilities that unixes already have. The big picture is that so-called static languages actually provide enough information (via debugging mechanisms) so that OTHER languages can treat them as if they were dynamic languages, and (really fun big picture stuff) can potentially automate discovery of their structure to the extent that all languages can interoperate without FFIs.
⬐ kwhitefootThis sounds like the kind of interoperability that I have been looking for ever since I started programming fifty years ago. I wonder if anything will ever come of it.
Thanks for the link - that looks really interesting! I will have to give it a try to make some informed statement, but I think it's definitely worth looking at. Some parts of Ruby also seem to be inspired by Smalltalk, so that might be a good fit. There's also a Smalltalk-80 VM by Rochus Keller based on the Lua JIT compiler [8] (and a very nice Qt-based Smalltalk browser), that might also go in the same direction.In general, I think there are two major interesting aspects in systems like the Ruby system browser and Smalltalk. On the one hand one can discover the system - you can dig into the implementation without using a disassembler or reverse engineering - and on the other hand it is possible to change the system behavior at runtime (though this is, of course, dangerous).
I would love to see at least the discoverability aspect to be more pervasive in standard operating systems. There are already partial approaches to this, such as DTrace/systemtap and the proc filesystem, but having discoverability as a first class concept - which might fit well to Plan 9's (and to some extent Unix's) "everything is a file" approach - would be nice.
The ability to change the system at runtime is also fascinating. I already mentioned the research of Stephen Kell in another comment [1] and there's a great video of one of his talks [2] in which he shows his approach to dynamically alter a program's behavior on Unix using shared library mechanisms (you can find the code on github [3]). I worked on related ideas in my PhD thesis 15 years ago, maybe it's time to dig these out again ;-).
However, these dynamic modifications should also be safe and accessible. I'm thinking of something related to AppleScript here, which allows to automate/scripts an amazingly large number of functions on OS X. Combining this with a browser that enables a user to discover the accessible OS functionality seems to be a good idea.
The persistent image ideas might also be useful again in the context of persistent main memory systems, which are becoming available now, e.g. with Intel Crosspoint [6]. There's so much prior work in persistent object systems also on the OS side that is almost forgotten nowadays, such as the Eumel/L3 system by Jochen Liedtke [4] (the inventor of the L4 microkernel) and the BirliX OS [5]. Sounds like a good time to re-evaluate these 1980's-era approaches.
I see some more recent work, such as Ksplice [7], as interesting related technology. What is really missing is an integration of many of these ideas into a consistent system.
[1] https://www.cs.kent.ac.uk/people/staff/srk21/ [2] https://www.youtube.com/watch?v=LwicN2u6Dro [3] https://github.com/stephenrkell/liballocs [4] Jochen Liedtke, A Persistent System in Real Use - Experiences of the First 13 Years, Third International Workshop on Object Orientation in Operating Systems 1993 - http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.7112 [5] W. E. Kühnhauser, H. Härtig, O. C. Kowalski, W. Lux, Mechanisms for Persistence and Security in BirliX, International Workshop on Computer Architectures to Support Security and Persistence of Information 1990, https://link.springer.com/chapter/10.1007/978-1-4471-3178-6_22 [6] https://en.wikipedia.org/wiki/3D_XPoint [7] Arnold, Jeff and Kaashoek, M. Frans, Ksplice: Automatic Rebootless Kernel Updates, EuroSys 2009 - https://ksplice.oracle.com/doc/ksplice.pdf
⬐ scroot> However, these dynamic modifications should also be safe and accessible. I'm thinking of something related to AppleScript here, which allows to automate/scripts an amazingly large number of functions on OS X. Combining this with a browser that enables a user to discover the accessible OS functionality seems to be a good idea.I have been thinking a lot lately about HyperCard and Applescript. They represent a line of thinking that has more or less been abandoned by the commercial side of personal computing, which is really too bad. Applescript still exists, sure, but they've really let it die on the vine. Back in the late 90s I hoped they would make the whole front end of the OS in a HyperCard like system, so that everything could be manipulated by the user. Don't like how this part of the Finder works? No problem, just peel back a layer and see what's going on.
⬐ johndoe0815That's definitely a shame - and, as far as I know none of the open source Unix(-like) systems has exposed a similar functionality. I think D-bus should enable something like it, but I haven't had a closer look at that...⬐ endlessvoid94The possibilities of bringing back this way of thinking are tantalizing to me. The intersection of end user programming a discoverable system with the pervasiveness of the cloud could be really awesome. Something like a mashup of Automator, Hypercard, Heroku, and Smalltalk.The only reason this doesn't exist is simply that nobody has decided to build it yet.
⬐ hhas01Working on it…⬐ endlessvoid94⬐ scrootthis is really cool! thank you for sharing> The only reason this doesn't exist is simply that nobody has decided to build it yet.It also takes a lot of time and effort, and so needs to be funded along with minimal interference from the bureaucracy of a business. Smalltalk and Hypercard came out of precisely those kind of environments. Today the goals of businesses are much different -- much more short term and quarterly focused. I don't have much faith that FOSS can come up with it either, since so much depends on part time work of loosely connected people.
I hope I'm wrong though!
> Smalltalk can be described concisely as a graphical UNIXOr Unix as a closet Smalltalk...
"Liberating the Smalltalk lurking in C and Unix" by Stephen Kell
Lately I have been very interested in putting faces and voices to words. After reading this article, which was over my head but I got a little out of it. I ended up reading Stephen Kell's homepage, which is crazy intense as far as academics go. He had a link to a video of his and I appreciated the quality and now have a face and voice to attach to the article, therefore will probably remember it better.tldr; Here is a video of the same guy who wrote this article ==> https://www.youtube.com/watch?v=LwicN2u6Dro
p.s. 5 minutes in and the talk is pretty good.
⬐ ElijahLynnDamn, just over 5 minutes in we have a working live demo that you can also try. You attach gdb to a running process, in this case a GUI clock called xclock.The video I linked to above is a great compliment to the linked article.
⬐ vmorgulisYou can even program in Python in GDG. There is an embedded version of it.
⬐ corysamaIf you found this interesting, you will probably also appreciate Cling - A JITing C++ REPL for LLVM-Clang.⬐ jonsterlingI don't want to liberate the smalltalk, I want to punch it down like a sore thumb.⬐ slashnull⬐ adamnemecekWith what sort of Golden Hammer ?; )If you are running Mac OS X and this is something that intrigues you, you should spend an afternoon or two playing around with F-Script[0]. It's a Smalltalk inspired language the runtime of which can be injected into running processes so that you can dynamically explore the process data structures in memory. For example this screenshot[1] displays the data structures of a running programming that you can explore à la Chrome devtools (the UI is a tad overwhelming at first). There's also this Automator script called F-Script Anywhere which adds an Automator service that let's you inject the F-Scipt runtime into a running process with a single click. It was originally made by Silvio H. Ferreira but I've made some tiny changes to make it run on Mavericks and Yosemite[2].[0] https://en.wikipedia.org/wiki/F-Script_(programming_language...
[1] http://www.fscript.org/images/screenshots/objectBrowser.jpg
⬐ McUsrThe first part doesn't intrigue me at all, because I can easily import an objective C-class into an AppleScriptObjectC app.I guess something like that works for Swift as well.
AppleScript in itself, can't do that, but I can call everything that is in Say Foundation, and the other frameworks (AppleScript version 2.3), and AppleScript is quite SmallTalkish. ;)
⬐ gnaritas⬐ seanmcdirmidSmalltalk'ish!⬐ adamnemecekIf I understand it correctly, you can only do this if you have access to the source, correct?F-Script is also an example of an array programming language in the style of APL. There is a paper on how they combined array and class constructs:
