Aphorisms on programming language design (2017) | Hacker News Reader

Aphorisms on programming language design (2017)

rntz.net

36 pointsswatson74112 comments

""Declarative" means you can use it without knowing what it's doing. All too often, it means you can't tell what it's doing, either."

Yeah....

Trying to decode this with examples:

> Not everything is an object (Ruby). Nor is everything a function (any FP), a string (Perl), a process (Elixir), an actor (Elixir), a value, a thunk, a message, a list (Clojure), a file (Unix), or an expression (Clojure). Not everything is data (Clojure), nor is everything code. Not everything is lazy (Haskell), immutable (Haskell), pure (Haskell), copyable, serializable, sortable, or transmissible over the network. goto is not the only control operator, and neither is call/cc.

Can you help me fill the missing ones?

Unix being "Everything is a file", has been less and less true starting already in the 1980s. Check the 300+ system calls in Linux and there is lot that is not a file. Many of the system calls would not even need to exist if everything were a file. I some cases that might make things easier, but I don't claim that should be drven to extremes.

Interesting enough after more than 45 years pidfds [1] got added.

[1] https://lwn.net/Articles/794707/

“Everything is code” is implied by “everything is an expression”.

Serializable and transmissible are implied by “everything is data” and “everything is an expression”.

Copyable is implied by “...immutable” and “...data”.

Objects, messages (OO, Smalltalk, Alan Kay)

Function (lambda calculus, FP)

String (shell, tcl, perl)

Process, actor (the actor model, Carl Hewitt, Erlang)

Value, immutable, pure (pure FP)

Thunk, lazy (lazy FP, Haskell)

File (Unix, plan 9)

List (lisp)

Expression (lisp macros, see linked essay)

Copyable (languages without linear type systems, ie. almost everything but rust; tbf some languages have a move/copy distinction even if they don't enforce it with a type system)

Serializable, transmissible over the network (anything that tries to do transparent RPC or state saving, smalltalk images, object databases, X windows)

Sortable (anything with a generic sort function that doesn't take a comparator or similar; ditto generic collection types like maps or sets that don't take a comparator or hash function)

goto (see Dijkstra's "goto considered harmful" essay)

call/cc (Scheme; see also recent work on algebraic effects and delimited continuations)

(I'm the author)

> Not everything is an object (Ruby)

If you think Ruby goes far with that idea, check out Pharo. In Pharo, even an object's fields are objects. Not just the value the field references. The field itself.

Similarly, in the Metaobject protocol of the Common Lisp Object System (CLOS) [0], classes, slot-descriptions, generic-functions and methods themselves are instances of metaclasses

[0] https://en.wikipedia.org/wiki/Common_Lisp_Object_System#Meta...

This was very interesting -

>> Types are a tool of thought. They exist in the mind first, and in the machine second.

>> A statically typed language, therefore, guides your thinking. This is useful. >> A dynamically typed language lets you think freely. This too is useful.

As is this -

>> Not everything is an object. Nor is everything a function, a string, a process, an actor, a value, a thunk, a message, a list, a file, or an expression. Not everything is data, nor is everything code. Not everything is lazy, immutable, pure, copyable, serializable, sortable, or transmissible over the network. goto is not the only control operator, and neither is call/cc.

I feel like they missed a great chance here:

  23 ...
     iii Everybody loves parenthesis

With a hyperlink to someone complaining about Forth or COBOL or something.

>To succeed, be the only available option on a popular platform.

And holy three of them, if you want a cult.

"There is power in restraint. The less a language does, the more can be done to it."

Assembler

Assembler's a great illustration of this. Assembler imposes very few constraints on what you can do. Which, in turn, makes assembly language programs very difficult to manipulate, because there are just so many special considerations to worry about.

A language that doesn't let you decide what registers will be used to store data, or interleave conditional branch statements in clever ways, or carefully select which instructions you use in order to tightly synchronize the program's execution to some outside signal such as the monitor's vertical retrace[1], is a language with a lot more freedom to do things like compiler optimizations.

[1] Dated example, I realize. Unless you count playing TIS-100, it's been a minute or two since I last did anything interesting in assembler.

Reply on news.ycombinator.com