I really wish there was a fast, minimalist way to get Forthlike simplicity, plus Smalltalk-like separation of objects from each other, in the same VM kernel, that's tiny enough to hold in your head and understand.

At the very least, some way to keep RAM addresses separate from machine integers so a function can't smash the entire RAM / disk.

I want a global shared indie idea-space, where the ideas we're sharing might be functions or objects. "Just don't run code from the Net" is not an option.

Maybe what I really wish is that I personally understood the Smalltalk-80 kernel, or even the Javascript one.

But I worry that Javascript has been performance-optimised now to the point that it's about as complicated and reliable as a Space Shuttle main engine.

I don't even understand Forth or Lisp but I sorta feel like I *could* understand at least the *idea* of Forth or Lisp?

I don't have any clue what the minimal "idea" of Smalltalk or Javascript is. There's just so much in both of them even to start.

@natecull i think the minimal idea of smalltalk is messages. what precisely “objects” are or what they exactly do seems less important than their ability to send and recieve messages and do things in response to messages

@zens

"Does things in response to messages" is not enough of an Idea to build an Implementation, in my opinion, sorry.

I need concrete specifics. I do NOT need abstracts. We have far too many layers of abstraction now that abstraction itself seems to be the enemy, and I want to smash all those away.

That's the Forth-lover in me talking. But when I see actual Forth I think it's smashed one abstraction too many (mainly the one that shields all RAM from being destroyed by a bug anywhere).

@natecull well, say we’re implementing a minimal smalltalk in C. and we just wanna draw a pixel to the display.

we’d have send_msg(DISPLAY_ID, *msg)
where msg is some struct specifying a draw_pixel command and its parameters, and DISPLAY_ID is just a magic number, like, say 5.

the implementation of send_msg can just stick the message on a message queue labelled “5”,
and other routine somewhere else can at its leisure look up the 5 queue, see a request for a pixel, and draw a pixel.

@zens

See, I hear you describe things that are several orders of magnitude more high level than "implementation".

Assume that I'm coming from Retro Forth. Where the very first thing you see and breathe and live in is "exact layout of bytes/words/instructions" and you go up from there, but only a LITTLE up.

What might be a Retro Forth for Smalltalk?

Follow

@natecull @zens

> See, I hear you describe things that are several orders of magnitude more high level than "implementation".

You can explore vpri.org/ and in particular this paper vpri.org/pdf/rn2006001a_colasw

As noted by @zens, in this Smalltalk-like kernel language, the primary pattern is about mesages and late-binding.

The vpri project was an attempt to create a rich computing system, using a minimal amount of code and abstractions. Forth has the same scope, but it is mainly restricted to control systems, while the vpri project was oriented to a complete system with GUI, web and so on.

@mzan @zens

I really like what VPRI was trying to achieve with CoLA and I'm sad that they stopped. :(

Sign in to participate in the conversation
CleverLibre Social

CleverLibre Social is an inclusive social instance for open discussion, learning, and community.
All cultures welcome.
Hate speech and harassment strictly forbidden.