Skip to main content

Why Smalltalk?

Because it's powerful.


Howard Stearns said…
Cute, and of course, I agree.

I'm also interested in ways in which Smalltalk is not powerful, in order to see what can be done to improve things. As with your comments on profiling, I like to be able to measure stuff. One way I like to measure the power of a programming language is to measure the cost (in lines of code) of making a change. This raises two issues in my mind:

1. In the Crqouet code that I've seen, a lot of code is duplicated between classes. Initialize methods do a lot. Operational methods in analogous but non-inheriting classes end up repeating the same (or nearly the same) code. So making a simple change often requires making the same kind of change in multiple places. The bigger the code base, the more often I have to do this. It's just cut and paste, but it's a lot of cust and paste. I hate cut and paste. It offends me. The way this is avoided in my former favorite language is with multiple inheritance. (Including multiple overridable inheritance of initialization methods.) I understand that there are people who have issues with multiple-inheritance -- or ANY form of class inheritance. OK. Maybe that's not the answer. But I would like to address the problem in some way. Any thoughts? I find myself drawn to delegation techniques, but I don't have much experience with them.

2. There's a fair amount of setup and boilerplate that have to do with getting related objects to cooperate and initialize themselves properly. In my formerly favorite language, this was addressed with macros. Instead of writing application-specific stuff directly in the language, you typically create a domain-specific language using a few macros that you write once, and then use that language to create the application code. When issues arise for performance or interfaces to external systems, we change the macros rather than the boilerplate that is distributed throughout the code. Again, any thoughts?

I like to see the cost of making a change be proportional to the the application-domain scope of the change. (I don't have a good way of measuring the application-domain scope of the change. All I have is a subjective feel. But the general idea is that "easy" things should be easy.) In both of the situations I describe, the cost of making a change ends up being proportional to the size of the code base.

Popular posts from this blog

Frontend-only Multi-Player. Unlimited Bandwidth. Or: What is, really?

A multi-player web app needs a backend, right? What if I told you, it doesn’t? Read on for how Croquet gets rid of servers running your multiplayer code. No, really . Instantaneous Shared Experiences  is how we describe Croquet on our website. And while that excellently describes What Croquet does, as Croquet's Chief Architect, I wanted to share a bit about How we do that. So I wrote a Twitter thread . Here it is in blog form, slightly extended. Click the animation above if it does not play automatically Croquet lets you build completely client-side multi-user web apps. Read that again. Client-side. Multi-user. No I’m not kidding. I built it, I know it works. 😁  Croquet apps run completely client-side: are hosted as a static web site no server-side code needed no networking code needed  Croquet is literally virtualizing the server: Instead of running code on a server (or in a serverless function) we run it as a virtual machine (VM) on each client.  Croquet carefully control

Deconstructing Floats: frexp() and ldexp() in JavaScript

While working on my  SqueakJS VM, it became necessary to deconstruct floating point numbers into their mantissa and exponent parts, and assembling them again. Peeking into the C sources of the regular VM, I saw they use the  frexp ()   and ldexp () functions found in the standard C math library. Unfortunately, JavaScript does not provide these two functions. But surely there must have been someone who needed these before me, right? Sure enough, a Google search came up with a few implementations. However, an hour later I was convinced none of them actually are fully equivalent to the C functions. They were imprecise, that is, deconstructing a float using frexp() and reconstructing it with ldexp() did not result in the original value. But that is the basic use case: for all float values, if [ mantissa , exponent ] = frexp (value) then value = ldexp ( mantissa , exponent ) even if the value is subnormal . None of the implementations (even the complex ones) really worked. I

Smalltalk Bindings for Minecraft Pi

The Raspberry Pi is a cute little computer. Quite cheap at $35, you plug in USB keyboard+mouse and a TV as monitor. And it is surprisingly capable, even for running 3D games. One particularly interesting game is Minecraft: Pi Edition . As in other Minecraft versions, the main goal is to create a world. But unlike other versions, you can not only use the tools provided by the game, you can make your own tools! That's because it comes with a programming interface. The Minecaft world is made of little cubes, and you normally place or remove these blocks by hand, one after another. This is fun, but for larger structures also quite cumbersome. For example, this rainbow here might take a long time to construct manually: But I did not make the rainbow by hand. I programmed it, using the Smalltalk programming language. It's just these dozen lines of code in the Squeak programming environment: Squeak is already installed on the Raspberry Pi, because Scratch was made in Squeak