mu1 VS squeak.org

I got sick of juggling code that migrated from one category to the other, so I wrote a little script that deals with chopping up a large source file into multiple TUs before feeding them to the compiler.

https://github.com/akkartik/mu1/blob/master/build2

More details: https://news.ycombinator.com/item?id=33574154#33575045

This really speaks to me. Modern software is too hard to assemble from source. If you're shipping sources, every moving part you add increases the odds of something going wrong on other people's computers.

It's worth having some skepticism of tools. By making some operations easy, tools encourage them. Build systems make it easy to bloat software. Package managers make it easy to bloat dependencies. This dynamic explains why Python in particular has such a terrible package management story. It's been around longer than Node or Rust, so if they seem better -- wait 10 years!

For many of my side projects I try to minimize moving parts for anyone (usually the '1' is literally true) who tries them out. I work in Unix, and one thing I built is a portable shell script that acts like a build system while being much more transparent about what it does: https://codeberg.org/akkartik/basic-build

When I use this script my build instructions are more verbose, but I think that's a good thing. They're more explicit for newcomers, and they also impose costs that nudge me to keep my programs minimalist.

You can see this build system evolve to add partial builds and parallel builds in one of my projects:

https://github.com/akkartik/mu1/blob/master/build0

https://github.com/akkartik/mu1/blob/master/build1

https://github.com/akkartik/mu1/blob/master/build2

https://github.com/akkartik/mu1/blob/master/build3

https://github.com/akkartik/mu1/blob/master/build4

Each of these does the same thing for this one repo -- build it -- but adding successively more bells and whistles.

I think providing just the most advanced version, build4, would do my users a disservice. It's also the most likely to break, where build0 is rock solid. If my builds do break for someone, they can poke around and downgrade to a simpler version.

Totally agreed!

Here's a prototype from a few years ago where I tried to make this easier: https://github.com/akkartik/mu1#readme (read just the first few paragraphs)

I still think the full answer lies in this direction.

Also, it's not really an "operating system", nor was it implemented by the ST. It's just part of Squeak (you got the name right), the "engine" Scratch 1.x was made with (which lets you edit the code in the same window it's running in).

Just downloaded https://squeak.org/ to play around with this concept.

I wonder if there is already a modern tool/suite for Node/Python inspired by Smalltalk...

AFAIK the major SmallTalk distributions are https://squeak.org/ and https://pharo.org/. I've heard that Pharo is more complex and "practical", while Squeak is more educational and beginner-friendly. But both stick to their roots with "everything is an object or method", extreme reflection, and integrated runtime/IDE.

Your concept looks nice, it reminds me a bit of the Lisperati: https://www.hackster.io/news/the-lisperati1000-is-a-cyberdec...

So, did you consider Lisp or maybe Smalltalk? Plan 9 or Inferno might also be options.

Plan 9 comes in different variants, the "classic" one (with a Raspberry Pi port by Richard Miller) or 9front, an Inferno porting tutorial can be found at https://github.com/yshurik/inferno-rpi

Lisp and Smalltalk can run with or without Linux underneath, e.g. on the Raspberry Pi.

Bare-metal Lisp is available with interim: http://interim-os.com

Finally, bare-metal Smalltalk is available in my crosstalk system: https://github.com/michaelengel/crosstalk

Of course, Lisp and Smalltalk can also run hosted under Linux, e.g. using Squeak (https://squeak.org), Pharo (https://pharo.org) or InterLisp (https://github.com/Interlisp/medley).

Or - a crazy idea - build an emacs-only machine. That would be fun! :)

This repository contains multiple projects closely related to (hardware-accelerated) rendering in Squeak/Smalltalk.

Packages related to using OpenGL in Squeak/Smalltalk.

Author here, feel free to ask any questions you have :).

It's amazing this little project shows up again here. So far, I received a lot of very positive and friendly feedback about this little pet project of mine.

The whole project would not have been possible without the work of Rene Stange, who created the circle bare-metal library for the Raspberry Pi (https://github.com/rsta2) and Dan Banay, who created a C++ implementation of the Smalltalk-80 VM (https://github.com/dbanay/Smalltalk). I mostly hacked together some glue code...

If you want to dig deeper, the Blue Book by Adele Goldberg and David Robson (scan provided by Stephane Ducasse, thanks a lot!) is _the_ reference on both the language and the structure and implementation of the underlying bytecode VM: http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....

Beware, though it's fully functional, crosstalk is still limited by constraints of the original Smalltalk 80 system - e.g. in terms of color (black and white only), possible screen resolution (2^20 pixels, the system crashes if you try to increase the resolution beyond this) and available memory (~1 MB!).

Nevertheless, I think it's a rather authentic reproduction of a more than 40 year old system and I learned (in a comment thread on a completely different topic) that one of our fellow hackernews regulars used it to teach his kid Smalltalk programming - love it! I haven't tried to optimize it significantly, so there's no JIT compiler or bitblit acceleration using the Raspberry Pi GPU.

There's a more modern bare-metal Smalltalk implementation based on Squeak (https://squeak.org) for the Raspberry Pi by Pablo Marx, though this seems to have some stability problems according to the author: https://github.com/pablomarx/RaspberrySqueak

Finally, if you are interested in alternative bare-metal language/OS environments for the Raspberry Pi, you could also give Lukas Hartmann's (of MNT Reform notebook fame) Interim OS a try: http://interim-os.com

Came here to mention Smalltalk. In things like Smalltalk-80 and Squeak, there was no build system, there are no source code files, there isn't anything but the Smalltalk Development Environment. With something like ENVY/Developer, building involved generating an exported image from the environment.

If OP wants to try it: https://squeak.org/

She missed the biggest ‚programming portal‘ of all: Squeak (Smalltalk) (https://squeak.org/)

Inspecting objects, ‚live‘ coding, a GUI that's intimately tied to its CLI - that's exactly Squeak!

The Morphic UI: http://wiki.squeak.org/squeak/1870