nothing makes us feel like we're not programmers like trying to read Lua code that uses object-oriented programming structures

I think what fucks with our head is that we get Lua normally - like, we've written multiple PICO-8 videogames and art projects - but then we see a program whose entire structure operates according to an alien logic and everyone around is like "yeah, that's some good code"

y'know what? fuck it. we're going to go back to the source and figure out what the fuck object-oriented programming is, once and for all https://archive.org/details/byte-magazine-1981-08

Smalltalk is an object-oriented language, as opposed to procedure-oriented languages such as BASIC, Pascal, and FORTRAN . Because of this, programming in Smalltalk is similar to the process of human interaction.

okay, we probably should have expected some eyebrow-raising analogies in here but we're raising our eyebrows

also holy crap there are a lot of ads in this thing - it makes the Internet look goddamn restrained

Where to Start

The order in which you read the Smalltalk-80 articles in this issue makes a difference. The first stopping point should be Adele Goldberg's article "Introducing the Smalltalk-80 System" on page 14, in which she provides a guided tour of the issue. I also recommend Dave Robson's "Object-Oriented Software Systems" on page 74 as a good overview of the Smalltalk-80 philosophy. The glossary on page 48 will be helpful as you begin to absorb the rather extensive (and sometimes overwhelming) vocabulary used to describe the language . I found that, once the terms become familiar, the concepts begin to make elegant sense.

okay, so, 14, then 74, then copy out glossary from 48 *takes notes*

Small talk is the name LRG [the Learning Research Group of the Xerox Palo Alto Research Center] assigned to the software part of Alan Kay's personal computing vision, the Dynabook. The vision is a hand-held, high-performance computer with a high-resolution display, input and output devices supporting visual and audio communication paths, and network connections to shared information resources.

having used a number of similar machines, we can understand why Kay thought that would be cool

In figure 1, we see a view of the conventional software development environment: a wizard sitting on his own computational cloud creating his notion of a Taj Mahal in which programmers can indulge in building applications for nonprogramming users. The Taj Mahal represents a complete programming environment, which includes the tools for developing programs as well as the language in which the programs are written. The users must walk whatever bridge the programmer builds. A goal in the design of the Small talk system was to create the Taj Mahal so that programmers can modify it by building application kits, which are specialized extensions and/or subsets of the system whose parts can be used by a nonprogrammer to build a customized version of the application. Applications that can be created from a kit are related in a fundamental way: the programmer may, for example, create it for building bridges, but it is the user who pieces together the parts to create a customized bridge (see figure 2).

<guy who has only seen The Boss Baby voice>getting a lot of Picotron vibes from this</guy>

*squints at page 26*

okay, so, picking from these options, tentative reading order for ourselves:

• 14 system
• 17 object oriented programming
• 48 glossary
• 230 data structures
• 322 control structures
• 286 design principles
• 90 programming environment
• 147 more programming interface
• 300 Smalltalk virtual machine
• 378 Smalltalk virtual memory
• 369 ToolBox painting component
• 168 graphics kernel
• 348 Smalltalk-80 for kids

this is a fucking doorstopper of a magazine, wow

also, getting genuine wiki-walk vibes from how extensive and interconnected it is

stating our goals out loud so we know when we can bail:

1. understand what object-oriented programming is
2. understand why anyone would want to build anything this way

(checking the glossary, we're definitely on the right track - self shows up all the time in object-oriented Lua, and nil is an old friend)

(also fucking posting automatically when hit enter on subject CW line, ugh)

The words "object-oriented" mean different things to different people. Although the definition given in this article may exclude systems that should rightfully be called object-oriented, it is a useful abstraction of the idea behind many software systems.

*notes*

Many people who have no idea how a computer works find the idea of object-oriented systems quite natural. In contrast, many people who have experience with computers initially think there is something strange about object-oriented systems.

...okay, do we feel called out or seen?

I am assuming that most of you also have some experience with software systems and their creation. So instead of introducing the object-oriented point of view as if it were completely natural, I'll try to explain what makes it seem strange compared to the point of view found in other programming systems.

right, gonna go with "seen"

Data/Procedure-Oriented Software

The traditional view of software systems is that they are composed of a collection of data that represents some information and a set of procedures that manipulates the data.

[...]

A problem with the data/procedure point of view is that data and procedures are treated as if they were independent when, in fact, they are not. All procedures make assumptions about the form of the data they manipulate. The procedure to move a window should be presented with data representing a window to be moved and its new location. If the procedure were presented with data representing the text contents of a window, the system would behave strangely.

[...]

These two problems have been addressed in the context of the data/procedure point of view by adding several features to programming systems. Data typing has been added to languages to let the programmer know that the appropriate choice of data has been made for a particular procedure. [...]

Object-Oriented Software

Instead of two types of entity that represent information and its manipulation independently, an object-oriented system has a single type of entity, the object, that represents both. Like pieces of data, objects can be manipulated. However, like procedures, objects describe manipulation as well. Information is manipulated by sending a message to the object representing the information.

Okay, so, philosophically, I think I get what the argument is. Using a shoot-em-up as an example: instead of having data for the player, player bullets, enemy bullets, enemies, and powerups, and then separately procedures for each interaction, you make all of those objects and have some kind of bump method that governs what they do on collision.

We're not sold on it yet but we at least see why the concept has a mathematical appeal.

(fuck, there are so many ads)

Conclusion

The realization that information can describe the manipulation of information is largely responsible for the great utility of computers today. However, that discovery is also partially responsible for the failure of computers to reach the utility of some predictions made in earlier times. On the one hand, it can be seen as a unification between the manipulator and the manipulated. However, in practice, it has been seen as a distinction between software and the information it manipulates. For small systems, this distinction is harmless. But for large systems, the distinction becomes a major source of complexity. The object-oriented point of view is a way to reduce the complexity of large systems without placing additional overhead on the construction of small systems.

This does brush up against one of our emotional sticking-points with regard to object-oriented programming in Lua: building a system of objects feels like it adds a lot of complexity, and in the small systems we interact with, we don't know what you're meant to get out of doing all that extra work.

gonna take a break from Smalltalk for a bit

okay, we're back.

...we need to figure out where we want to pick up again on this BYTE issue

back to the info in "Introducing the Smalltalk-80 System":

[...] The two examples of programming in Smalltalk-80 are likely next steps: one, by Jim Althoff, tells you how to build data structures (page 230); the other, by Peter Deutsch, describes how to build control structures (page 322). Or, you can follow a hallway to the user interface window. and read Larry Tesler's description of the Smalltalk programming environment (page 90). Trygve Reenskaug offers further perspectives on providing a programming interface to a Small talk system (page 147).

...user interface, I think.

Soon after I began battling the mode monster, I became associated with Alan Kay, who had just founded the Learning Research Group (LRG) at the Xerox PARC. Kay shared my disdain for modes and had devised a user-interface paradigm (reference 3) that eliminated one kind of mode, the kind causing the preemption dilemma. The paradigm he advocated was called "overlapping windows."

It's freaking weird reading old magazine articles from when concepts like "applications run in windows and you can switch between them" are new.

Kinda cool, though. You have to imagine that they're pretty happy to see their ideas beco--

Of course, windows are, in a sense, modes in sheep's clothing. They are more friendly than modes because you can't slip into a window unknowingly when you are not looking at the screen, and because you can get in and out of any window at any time you choose by the push of a button.

...oh, right, modern computer programs steal focus and throw up un-skippable popups all the time. The modes Tesler hated so much are still here, I guess 🙃

The implementations of Small talk produced by Dan Ingalls and the other members of the Learning Research Group have achieved ever-increasing integration. The file system, process-management system, graphics capability, and compiler are implemented almost entirely in Smalltalk. They are accessible from any program, as well as by direct user interaction.

Okay, we're going to make the boss baby tweet joke again, but Picotron's everything is implemented almost entirely in Picotron Lua, right? It's even a fairly similar UI.

If the machine has a high-performance disk drive, you can use a virtual-memory version of Smalltalk and have as little as 80 K bytes of main memory, not counting display-refresh memory. Otherwise, you should have at least 256 K bytes of memory. [...]

Really living in a different world now, aren't we?

Making a Selection

In the Smalltalk-76 user interface, text is selected using the pointing device and a single button . First, the cursor is moved to one end of the passage to be selected (photo 8a). The selection button is pressed and held down while the cursor is moved to the other end of the passage. This operation is called "draw-through," though it is not necessary to traverse intermediate characters en route to the destination. When the cursor reaches the other end of the passage, the button is released. The selected passage is then shown in inverse video (photo 8d).

...they freaking won. It worked. This entire text editor section is just describing how all the text editors work now.

To issue a command that is not available in a menu, you select any place you can insert text, and type the whole command as a statement in the Smalltalk language (photo 10a). Then you select that statement and issue the single-parameter command "do it" (photo 10b) to obtain the result (photo 10c).

what?! that's so weird! wow!

Inspecting Data Structures

Suppose someone has given you a Smalltalk program to implement a "regular polygon" class (table 1) and you want to learn more about it. It would be helpful to see an actual instance of a regular polygon.

If the variable triangle refers to a regular polygon, you type the following statement into your work-space window:

triangle inspect

and then issue the "do it" command in the pane menu (photo 12a) . In a few seconds, a two-paned "inspect window" appears on the screen. Its title tab tells you the class of the inspected object, in this case, RegularPolygon. The window is divided into two panes. The left or variable pane lists the parts of a regular polygon, sides, center, radius, and plotter. The right or value pane is blank.

You point to the word sides in the variable pane and click the selection button on the mouse. The word sides is highlighted, and in the value pane, the value of the variable sides appears (photo 12b), in this case, 3. You point to the word center and click. In the value pane appears the value of center (photo 12c), in this case, the point 526@302. The value pane is dependent on the variable pane because its contents are determined by what you select in the variable pane. The arrow in figure 3 symbolizes this dependency.

...I think this is a place where Smalltalk's object-oriented method serves it well

it puts the relevant functions ready to hand for inspection

it's interesting - the Smalltalk environment looks like a modern user interface, with applications in windows, but it ... isn't

they're actually less siloed from each other than that - they're all part of one system, and edit that system and so each other

we kinda had to break that one for security - you want to be able to download a game from a stranger without fearing it will rewrite your computer to their whims - but it's neat

(took a sec to go fix some typos - hence all the edits)

another difference between Smalltalk and most computing in the 2020s - we were saying this to a friend elsewhere - is the assumption that computers have operators who learn how they work and how to manipulate them

nowadays, the assumption is that they have users who should be steered so they (supposedly) don't have to learn anything

open-source leaves a crack open in that exploitative idea, but it feels like a pretty thin crack sometimes

there's quite a cliff to climb to get anywhere in a lot of programs

at least it's possible, though, sometimes

The entire stack of the process under test was saved in the notify window. When a notify window appears, the rest of the system is not preempted. You are not required to deal with the notify window when it appears. You can work in other windows and come back to it later, cause other notify windows to be created, or work a little in the notify window and then do something else. There are no modes.

yyyep.

Type checking is important in most systems for four reasons, none of which is very important in Smalltalk:

[...]

• Type declarations help to document programs. This is true, but well-chosen variable names and pertinent comments provide more specific information than do type declarations. A poor documenter can convey as little information in a strongly typed program as in an untyped program.

I like the idea of analyzing your code itself as a kind of documentation you make. Not a revolutionary idea, but a good one.

Project Windows

Although overlapping windows enable you to keep the state of several tasks on the screen at the same time, you may sometimes be working on several entirely different projects, each involving several tasks. Small talk lets you have a different "desk top" for each project. On each desk top are windows for the tasks involved in that project. To help you travel from one desk top to another, a desk top can have one or more project windows that show you other available desk tops and let you switch to one of them (photo 21).

...huh - our ADHD brain likes that idea. Using multiple desktops would be easier for us if they were all, like, labeled and stuff and visible in front of us, and we could make and erase them at whim.

For many people, the workings of a computer remain a mystery. Just exactly what the computer does and how it does it is locked within the code of a computer language. The computer and the user understand two completely different languages. It is well known that only a few systems are designed and written so that they can be understood by the user. More than twenty years of experience has shown us that a bad system design can never be hidden from the user, even by a masterfully devised user interface. A quality system, therefore, must be based on sound design that can be described in terms with which the user is familiar.

Okay, we start imagining a golden age one second and then immediately discover that no, things were bad then, too - it's just that we're listening to someone who noticed and pushed back.

An individual's total information needs are very large and complex. His Smalltalk system, therefore, is also likely to be large and complex. [...]

Unnecessary gendering, ugh.

[...] The challenge to the Small talk experimenter is to find ways to structure systems so the user will not only understand how to use them, but also get an intuitive feel for their inner workings. [...]

But yes, I agree - that would be very empoweri--

In this way, the user can really be the master and the systems his faithful slaves.

...nope. Nope, fuck off. Leaving now.

The syntax design (or lack of it) was an example of taking the "flexibility" position to an extreme. Our experience in teaching Smalltalk-72 convinced us that overly flexible syntax was not only unnecessary , but a problem. In general, communication in classroom interaction breaks down when the students type expressions not easily readable by other students or teachers. By this we mean that if the participants in a classroom cannot read each other's code, then they cannot easily talk about it. Our intention was that the Smalltalk system serve as a communication mediator, but the lack of communication due to the runtime parsing of expressions was hindering this goal.

this makes us think thoughts we've thought about Toki Pona, actually

simplicity in one place can easily lead to complexity somewhere else - instead of everyone having to learn one word, they have to learn a hundred different bespoke rewordings of the same meaning

instead of everyone having to learn one library function, they have to learn a hundred different bespoke re-implementations of the same thing

sometimes you get simplicity by adding more, not by removing it.