Well timed! I've just been trying this out myself after reading Maxwell's Equations of Software [1]. It's fun realising that the "base" functions you're doing in Go can be reduced to even more fundamental forms using the Lisp you're implementing.

[1] http://www.righto.com/2008/07/maxwells-equations-of-software...

When I look through what Rob has done, I see a few patterns clearly traced to LISP, including a strong emphasis on recursive approaches and simplification by relying on functional (immutable) semantics. Look at the bitmap layers work, Newsqueak, Sawzall. There is of course also a heavy dose of pragmatism, which seems to be what you are criticizing.

Your question is therefore answerable: since he was in fact exposed to all that material forty years ago, he would be exactly where he ended up.

Not that there's much type theory in that book, but I'll note that Rob has also worked with type theorists in the past as well, notably Luca Cardelli on Squeak. And he was the one who suggested we approach Phil Wadler to help us work on the semantics of generics in Go. So again the ignorance about programming languages that your comment implies simply isn't accurate.

This pattern of assuming what other people know about is endemic on HN (and the internet more broadly, but especially so here), and it is harmful to productive discussion.

Interestingly, preaching the benefits of "simplicity" is also a very popular pastime on HN but that apparently does not extend to the languages used.

Thank you, this is a very helpful framing of something I've recently been struggling to articulate about languages with sophisticated type systems after having surprisingly positive and productive experiences with Clojure and Go.

https://en.wikipedia.org/wiki/Paradigm_shift#Incommensurabil...

This is exactly what we see. People adhering to different computing paradigms use some of the same words (e.g. "type"), but they have different meanings and basically they talk past each other as a result.

https://www.youtube.com/watch?v=Dq0WFigax_c

It's somewhere in the first 10-20 minutes (if someone wants to give a timestamp link)

(Also, my experience is that such comments usually get downvoted/flagged on HN, you just have to wait awhile)

(on closed vs open and haskell)

That's not really what my comment is about; and I know very well who Pike is, and I'm assuming everyone here does. (Come on, legendary!)

Note that the phrase I used, "doing the experimentation", specifically avoids speaking to what Pike knows or doesn't know.

Note, that's not the topic of the talk, it's just mentioned in it.

    // Expr represents an arbitrary expression.
    type Expr struct {
        // An Expr is either an atom, with atom set, or a list, with car and cdr set.
        // Car and cdr can be nil (empty) even if atom is nil.
        car  *Expr
        atom *token
        cdr  *Expr
    }

I probably never would have done it that way, I would probably use an interface type instead. This way actually saves space in cons objects… in the above version, a cons is 24 bytes, and below it would be 32:

    type Expr interface { }
    type Cons struct { car, cdr Expr }

  func apply(fn, x, a Addr) Addr {
          if atom(fn) == T {
                  switch fn {
                  case CAR:
                          return caar(x)
                  case CDR:
                          return cdar(x)
                  case CONS:
                          return cons(car(x), cadr(x))
                  case ATOM:
                          return atom(car(x))
                  case EQ:
                          return eq(car(x), cadr(x))
                  default:
                          return apply(eval(fn, a), x, a)
                  }
          }
          switch car(fn) {
          case LAMBDA:
                  return eval(caddr(fn), pairlis(cadr(fn), x, a))
          case LABEL:
                  return apply(caddr(fn), x, cons(cons(cadr(fn), caddr(fn)), a))
          }
          panic(errint("bad node: " + car(fn).String()))
  }

I think when you're all in the same package and accessing unexported fields you know about, this is much clearer than an interface. I often add unexported mutually exclusive fields that local code has advanced knowledge about to prevent unnecessary over-abstraction.

Go embraces the common insight that you can encode a sum as a dependent product. That is, here, you have a discriminated union of atoms and cons cells, but the discriminant is not a specific tag value, as it would be in Haskell or ML or similar, but rather the nil/non-nil state of these fields. Of course, there is no static enforcement of this property, as there would be in contemporary languages with sum types, including Rust's enums.

The quintessential example of this in Go is result/error multi-value returns. The result is valid if the error is nil. If your goal is to save bits (which is rarely the case for Go programs), as you note, avoiding an explicit discriminant (such as an interface pointer) means that you're encoding the discriminant's information in to less space, utilizing the specific domain knowledge of mutual exclusion.

Stepping further from Go, this same principle is at play in Clojure, which favors open maps for information. In Clojure, multimethods can dispatch on arbitrary functions of values. This means that any field can easily be used as a discriminant. Now, saving bytes is certainly not the purpose of this in Clojure, but it's interesting to think about. Forcing dispatch in to a privileged discriminant tag means that data needs to be transformed/parsed in order to re-arrange information in to the tag for dispatch.

Alexis King wrote an excellent article about this sort of transformation: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

As excellent as that article is, I think the truth lies in some balance. Both parsing and validation are useful techniques. Contemporary typed languages tend to push you down a path towards parsing instead of validation, which is probably the way the pendulum should swing for many use cases. However, there is one language that stands in stark contrast: TypeScript. Because it needs to support existing JavaScript idioms, it has grown a type system powerful enough to enable reasonable type safety with a validation based approach. Tools like control-flow sensitive type checking, literal types, and type-guards make that possible. You can use an arbitrary key in some JS object with a literal type value as a discriminant and the type system will do the right thing with union types.

There is one other area where Go is interesting here: zero values. Go zero-initializes all freshly allocated memory and encourages a style that embraces that. These freshly allocated objects are called "zero values" and often they are useful right out of the gate. You're encouraged to make code no-op safely with zero values, or apply some sane defaults. This makes an important distinction between `EnableFoo bool` and `DisableFoo bool`. Looping zero times is a perfectly valid thing to do. Silently skipping nil values is a perfectly valid thing to do in some cases. Etc. Clojure is similar with nil punning. While not without it's downsides, this is an interesting point in the design space that seems totally ignored by theoreticians and totally under-appreciated by working programmers, even those who work with Go and Clojure regularly. I'd really like to see that change, as I've found my programs have generally improved as I make judicious use of these techniques.

If you define away the zero states completely with sum types, code flow is completely accounted for at compile time, and entire categories of "oops, that shouldn't be nil right now" bugs simply don't exist. On Apple platforms, this is a major reason to use Swift instead of Objective-C.

I haven't used Go, only read some code occasionally; perhaps there's some other difference here that makes this a nonissue. But it sure looks like it has the same set of problems.

Yes, it's nice to have the type system catch problems. And yes, in the context of memory-unsafe languages null or wild pointers are a big problem. But I've found that you'd need a combinatoric explosion of data constructors and abstract interfaces to enforce the interesting invariants of my programs. A nil pointer (which panics at runtime with a good stack trace!) tends to be among the easiest problems I have to solve when my programs violate invariants.

I'm not arguing that sum-types are a bad idea. Only that dependent products (with or without enforcement, static or dynamic) are an under appreciated technique. Sum-types are really just one special case of dependent products.

Curious, know little Clojure but isn't "open objects" a Javascript thing too? What is special about Clojure here?

I called out Clojure specifically because of the culture around this specific issue and because of the dispatch design of the multimethods that are present in the standard library and widely favored. Nothing stops you from making dispatch tables or simply switching on a key in JavaScript.

https://www.youtube.com/watch?v=PXoG0WX0r_E

Closest I’ve seen to this was core.logic in the Clojure community, but it appears to be dead.

It’s being used in rust-analyzer (the leading language server) today, and is likely to be used in the compiler in the future. Not really intended to be general-purpose, but an interesting datapoint. And could evolve to be more general, knowing the Rust community.

The idea seems pretty damn intriguing.

Game of life in APL: https://www.youtube.com/watch?v=a9xAKttWgP4

https://web.archive.org/web/20131006150020/http://www.kuro5h...

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

https://shakti.com/

Not really. As I see APL is ISO standardized and there are many implementations.

The problem though might be that those ideas (like Julia's broadcast) are so seamlessly integrated into it's functional paradigm that you won't "really" know which parts are parts where you've been tricked into doing array programming.

- GPL license - Extremely well-documented - General purpose - Runs on any platform - 64-bit - C-like performance for many operators - Interpreted, interactive development environment - Package manager - Near-zero boilerplate

https://www.jsoftware.com/books/pdf/easyj.pdf

"Array language" describes a pretty generic syntax format wherein an operator acts on multiple inputs. Functional programming is a style that nests nicely with arrange languages. If you know "R," just think of lapply. It's like lapply everywhere, but without the lapply syntax. Every function is vectorized.

People who aren't formally trained on loops or object-oriented programming tend to pick this up more easily. That said, you can do OOP and loops in J if you want to.

As a fan of both awk and array languages, I think that an nsl-awk would be a really interesting project.

[1] https://github.com/kanaka/mal

https://github.com/kanaka/mal/pull/518

He won a Silver Medal for archery in the Olympics.

(Hint: look up 1980 Olympics)

tldr: he is canadian and 1980 summer Olympics was boycotted by both canada and america.

[1] https://wiki.c2.com/?RobPike