xkriva11

It is here for many decades: https://www.youtube.com/watch?v=eEz08IlcNMg

Probably start with Pharo MOOC: https://www.youtube.com/playlist?list=PL2okA_2qDJ-kCHVcNXdO5...

Smalltalk: https://github.com/pavel-krivanek/BarePharo

There is one important point to note. Works created by artificial intelligence are not subject to copyright.

Reminds me this meme: https://pbs.twimg.com/media/HNIjjQQasAA77yl.jpg

Practice: https://pavel-krivanek.github.io/colorType/

That's cool, but why not use the native colorForth keyboard layout?

https://www.ultratechnology.com/editor/dvorak.jpg

Talking about Self... https://github.com/pavel-krivanek/Selfie

...but the infinite desktop is still missing there.

To add to this, a quote from an article about the editor ed:

It’s important to realize that in ed you were usually editing a file you had already printed beforehand. If you only wanted to fix a few small things in a multi-page listing, you simply entered the corrections in ed on the relevant lines, added something here and there, and at the same time you would just write the simple minor fixes directly into the printout by hand-without having to tediously retype everything.

You had the files on paper, which is a very pleasant and ergonomic medium for reading. You can literally surround yourself with it, cover your desk, and easily move your eyes between dozens of functions. If you learn to keep order and stay oriented in that mountain of paper, you can be very effective.

Moreover, from an ergonomic point of view you wouldn’t be doing badly at all. Printed paper in natural light is definitely easier on the eyes than low-refresh-rate screens in the years that followed. Paper lets you quickly add notes, sketch a little graph, basically work in a very natural way - one people were used to back then from the moment they first held a crayon.

Most of the time a programmer isn’t writing code but reading it. In that respect, people back then may actually have had it better than we do today. When it did come to writing, the only truly more complicated part was essentially making corrections. The history of everything you’d done was right there on paper. I don’t want to idealize the way they worked back then, but all of this explains how they were able to work effectively even with such primitive tools.

The paper printouts on the table are a kind of simple spatial browser. Thanks to this, we have UNIX (at least it explains how they were able to create anything at all with just a teletype back then).

From a conceptual point of view, browsing code is like browsing a fractal. Tools must take this into account.

ZXsheet is a full-featured spreadsheet application for the Sinclair ZX Spectrum written in just 10 lines of BASIC.

But Squeak is 1996 ;)

Or use existing one: https://github.com/Zag-Research/Zag-Smalltalk

https://gtoolkit.com/ or https://moosetechnology.org/

A small game with a randomly generated corridor inspired by the Psygnosis Lander

Smalltalk offers several excellent features for LLM agents:

- Very small methods that function as standalone compilation units, enabling extremely fast compilation.

- Built-in, fast, and effective code browsing capabilities (e.g., listing senders, implementors, and instance variable users...). This makes it easy for the agent to extract only the required context from the system.

- Powerful runtime reflectivity and easily accessible debugging capabilities.

- A simple grammar with a more natural, language-like feel compared to Lisp.

- Natural sandboxing

xwoaf-rebuild matches that

https://web.archive.org/web/20240901115514/https://pupngo.dk...

You may try CADR (precursor to Genera) on-line: https://lispcafe.org/cadr/usim.html

No, they used a tool (SystemTracer) running inside the original Smalltalk that enumerated all the objects in the running image and serialized them in a new image format into a new image file. Every time the image file format changed, it was transformed like this. Smalltalk is very close to a biological system.

I tried do do it in a 16-bit JonesForth-based implemenetation and it required to rename JonesForth CREATE to CREATEHEAD, implement a primitive DODOES and then define these two words:

: CREATE WORD CREATEHEAD DODOES , 0 , ;

: DOES> IMMEDIATE ['] LIT , HERE @ 6 CELLS + , ['] LATEST , ['] @ , ['] >DFA , ['] ! , ['] EXIT

I recommend this Lua implementation. Truly beautiful and more accessible. https://github.com/melvinzhang/meta2-lua

Alan Kay: "I had the fortune or misfortune to learn how to read fluently starting at the age of three. So I had read maybe 150 books by the time I hit 1st grade. And I already knew that the teachers were lying to me."

ColorForth environment uses only 27 keys. See https://www.greenarraychips.com/home/documents/greg/cf-edito...

This Byte volume can be found here: https://archive.org/details/byte-magazine-1981-08/mode/2up

A demonstration of on-the-fly modification of GUI internals in Smalltalk-78: https://www.youtube.com/watch?v=eEz08IlcNMg

A faster booting version (without Lively Kernel IDE): https://codefrau.github.io/Smalltalk78/

There is Ultibo based bare metal Oberon version too: https://github.com/MGreim/ultiboberon

To downvote, you need a minimal amount of karma (something like 500 points)

I think it's a variant of the Anthropic principle. This project has been around for many years, and if it hadn't been based on Smalltalk at the time, it might not have come into existence. It's a natural extension of how Smalltalk environments approach development tools, pushing it to a new level. For more technical details, refer to https://pharo.org/features.