Hacker News Reader

Comment by overgard | Hacker News Reader

Smalltalk is IMO super readable, it's just not familiar or standard. To me, unreadable languages are languages that rely heavily on symbols. The obvious extremes would be perl or APL. In those, if you don't already know the symbol it's pretty much impossible to figure out. In smalltalk, it tends to read like english so you can usually understand what it's doing even if you're not entirely familiar with the syntax.

To be honest, I find this is actually the hardest thing I grapple with when I look at mathematics that I'm not familiar with. A lot of times the concept and the equation are simple, but if I'm not familiar with what a specific greek letter is supposed to represent it's completely impenetrable. Not that I'm saying we have to change math, but I always found that was the biggest obstacle for me.

View on HN

Yup, symbols are the hardest.

A few years ago (on sort of a whim?) I read a ML science paper without first having much of the foundational knowledge; I'd end up having to go off on more than a few Google dives per paragraph, just to understand what they were talking about.

But you can't Google an equation, or a symbol in an equation - at least I couldn't, and get meaningful results.

The biggest advantage computer scientists have over mathematicians is that our variables can be more than one character

Mathematicians allow multi-character identifiers when it comes to functions, though. sin, abs, det, etc.

But those are not variables.

Not in academic papers unfortunately... And while math symbols are somewhat standard across papers, every CS paper comes up with their own meanings for half the symbols they use.

Sometimes they are nice enough to say "we use random squiggly arrow to mean x", but then you need to keep a table of symbols on the side to even read the paper.

Other times they just reuse "common" symbols and expect you to know, even though that symbol has been used for more than one purpose over time.

It's all very tiresome.

> I read a ML science paper without first having much of the foundational knowledge; I'd end up having to go off on more than a few Google dives per paragraph, just to understand what they were talking about.

That's pretty much the norm with scientific publications, no? They're intended to be read by people with advanced degrees in the field.

You know you have a problem when even advanced degrees in a close field isn't enough, because your symbols are different. (And yeah, ML has this one.)

We should have iconographic dictionaries for Math.

One man's i is another man's j.

> To me, unreadable languages are languages that rely heavily on symbols.

Interestingly, the first Smalltalk, Smalltalk-72, used loads of symbols.[0] Introducing a new variable used an index finger symbol. Evaluating a message used an opened eyeball. The "turtle" was represented by something looking like a smiley face. There's a working emulator of Smalltalk-72 on Dan Ingalls' website, and I'd recommend playing around with it.[1] They really embraced the "everything is messages" thing, and couldn't figure out how to optimize it on their hardware (since the language is frankly way too powerful and not amenable to static analysis). If they could have seen the utility of something like a JIT, the future might have turned out differently, but as it happens, the Smalltalk variant Self was the first highly-efficient one, almost 20 years after Smalltalk-72.

Sun later cannibalized the Self team to have them focus on Java performance, and the result was the HotSpot VM, which in some ways saved Java from being a failure.

[0] http://www.esug.org/data/HistoricalDocuments/Smalltalk72/Sma...

[1] https://lively-web.org/users/Dan/ALTO-Smalltalk-72.html

Page numbers on the first citation?

Page 16 for the PDF, actual page # is 9. It shows up earlier but that's the best early example of the little face representing the turtle.

afaik Smalltalk-80 was the language that gave rise to implementations that were available outside the lab.

Smalltalk-80 was the language IBM trained their consultants to use.

There was one Smalltalk-72 inspired implementation not created by PARC. It was based on their publications before Smalltalk-80 was released. Rosetta Smalltalk

afaict That was a “prototype”. Was it ever made available to anyone beyond the authors?

They wrote: Rosetta Smalltalk was shown at the Exidy booth at NCC'81 and beta-tested at about 40 sites across the country.

But it was unfortunatelly discarded as soon as Xerox published Smalltalk-80.

Fair enough, I don't wish to diminish their work, or lionize Smalltalk-72 over Smalltalk-80.

It was supposed to be released to run on Z80 machines. Apparently it was killed when Smalltalk-80 was starting to be released (if Ted Nelson is to be believed):

https://archive.org/details/RosettaBrochure/RosettaBrochure/...

> Smalltalk is IMO super readable

Yep, definitely one of the most readable out there.

> unreadable languages are languages that rely heavily on symbols.

Yes and no.

I actually find symbols useful for very common and mostly structural elements. As an extreme example, assignment as '←' or ':=' or '=' is much better than "assign to" or having to use special accessor methods/messages (leaving aside that these things should be dynamic).

And I actually like the way that Objective-C uses "-" to introduce instance methods, because they are so common and there is really not much else that could go there, except maybe a class method introduced via "+". Having to write "function" or "func" each time is just clutter, and non-sensical clutter because there is very little else that could go there, and certainly nothing user defined last I checked. C of course doesn't use anything at all, you just start writing the function return type and name.

Similar with "set" and "get" for property accessors in C#. Those just seem wrong at that location, though I don't really have a good alternative. I tried to use "=|" and "|=" in Objective-S (http://objective.st), but nope, not a good alternative. Although "|=" is pretty good for dataflow constraints / permanent assignments.

Similar with "at:" for indexed access in Smalltalk. While I appreciate the uniformity, the "[]" syntax really adds something here and is common enough for special syntax to make sense.

So anyway: names for semantic-bearing and user-defined constructs. Symbols for very common structural/architectural elements, where they can be made to make sense.

UPDATE: In many ways, this is a lot like natural language does it, though of course not identical. It would be awkward to have to write "full stop" or "this sentence ends here" at the end of every sentence. So: punctuation.

Reply on news.ycombinator.com