raganwald.com

A very famous cover illustrated by Robert Frank Tinney (1947 - 2026). The mass adoption of OOP was the result of many interlocking changes, but this cover of this issue of Byte did a great deal to popularize Smalltalk and contemporaneous OO languages.

This issue led me to installing Digitalk's Smalltalk/V, and also to learning all about commands, undo, redo, and Object Pascal.

Thank you, Robert. Others may have done the engineering that captured my interest, but your illustration captured our attention and primed us to have fun while learning.

https://en.wikipedia.org/wiki/Robert_Tinney

Try APL in your browser!

But first, a little motivation to get you started: Game of Life in APL. Pay attention to how interactive APL programming is completely different from other ✌🏽dynamic✌🏽 languages like Ruby or JavaScript. It's much more like Smalltalk or LISP.

https://m.youtube.com/watch?v=a9xAKttWgP4

Now try it for yourself:

https://tryapl.org/

“Learn Lisp the Hard Way,” 2nd draft, last updated in 2022.

https://llthw.common-lisp.dev

#lisp #commonLisp

“A Conversation with Alan Kay” (2004)

Contains his famous ’programming is a pop culture’ quote and his perspective on the tenuous relationship between success and perceived merit in the software industry.

https://queue.acm.org/detail.cfm?id=1039523

"Code should be written to be verified, and only incidentally to be executed"

Proposition: Code written in functional languages is both intrinsically and extrinsically more verifiable. Intrinsically because of idempotency. Extrinsically because social forces happen to have resulted in code written in languages like Elixir to contain patterns that are easier to model.

The attached opinion piece suggests this makes them better languages for LLMs. But that also makes them better languages, period.

https://www.thefuriousopposites.com/p/grace-hoppers-revenge

👋🏽 @cdegroot@mstdn.ca

It was once fashionable to ask "pet" interview questions of software engineers. These questions usually demanded that the applicant know—or figure out on the fly—some algorithm with an intermediate- or advanced technique, like recursion.

One variation on the "pet question" interview would seem to ask for an algorithm, but in actuality there would be a quick-and-dirty "hack" such as using a regex to perform replacements in a text file.

"Alice and Bobbie and Sharleen and Dyck" is a fable that reverses the second interview type: The interviewer is looking for a pushdown automaton, and the interviewee presents the quick-and-dirty hack.

https://raganwald.com/2018/11/14/dyck-joke.html

p.s. Yes I have written balanced parentheses code live in an interview. I got the job anyways.

One of the finest things ever written abut the state of computing... And an excellent shaggy dog story: “The Emperor's Old Clothes,” Dr. Tony Hoare's 1980 Turing Award lecture.

http://pascal.hansotten.com/uploads/hoare/The%20Emperor's%20Old%20Clothes.pdf

Espresso Ristretto.

I miss CoffeeScript, I was very fond of that language and the lovely experience of working with CoffeeScript, Backbone, and even jQuery during a time when interfaces were considerably more CRUD-forward.

https://raganwald.com/assets/books/coffeescript-ristretto.pdf

One step closer to writing the words of my next blog post. The theme is "balanced parentheses, but generating them, not recognizing them."

I now have an implementation of generators for simple BP (aka "Dyck-1 languages") and Typed BP (aka "Dyck 2+ languages"):

https://gist.github.com/raganwald/31f12e78d47a69d44f3ebe172b64e803

The first 19 words output by the typed generator with pairs "()", "[]", and "{}":

""
"()", "[]", "{}",
"(())", "[()]", "{()}",
"(())()", "[()]()", "{()}()",
"()()", "[]()", "{}()",
"()[]", "[][]", "{}[]",
"(())[]", "[()][]", "{()}[]"

@sitcom_nemesis@tech.lgbt “A language that doesn't affect the way you think about programming, is not worth knowing.”

—Dr. Alan J. Perlis

https://www.cs.yale.edu/homes/perlis-alan/quotes.html

Postmodernist Programming: “Emulating GOTO in Scheme with continuations”

https://terezi.pyrope.net/ccgoto/

RE: @raganwald@social.bau-ha.us

My author is at it again.

A fresh result in the pursuit of finding something interesting about "balanced parentheses."

Having already sorted out how to generate every finite balanced parentheses string, we now can parse a string and determine if it is balanced with recursion.

https://github.com/raganwald/balanced-parentheses/blob/main/src/typed-dyck.test.ts#L57

Work in progress on an essay about flipping the old "balanced parentheses" problem around: Instead of recognizing balanced parentheses, how would we go about generating them?

Here's the first milestone: We first construct a mapping from the positive integers to pairs of non-negative integers to establish a bijection and an ordering, then we map non-negative integers to dyck words recursively.

https://gist.github.com/raganwald/31f12e78d47a69d44f3ebe172b64e803