5 ms·

I listened to this. He talks about language diversity but I never heard Rob Pike mention anything about Haskell or ML style languages and his opinions on that.

I listened to this. He talks about language diversity but I never heard Rob Pike mention anything about Haskell or ML style languages and his opinions on that. He never commented on functional programming languages and the closest he gets to it is mentioning lisp. The design of Go feels almost as if he doesn't even know about those ML languages and it feels as if he doesn't like FP. Of course he probably does know about ML style languages. But I would be very interested to hear his take on it and his opinion of FP because I couldn't find anything from google. Anybody know of any links to writings/videos where he elucidates his viewpoints?

darthrupert 3y ago
It's entirely possible for an expert programmer and pl designer to have never heard of ML-based languages or FP as a name for the concept.
- corethree 3y ago
  Possibly. It's wierd he's so enamored with apl which just seems to me like languages focused an algebra designed around arrays. Algebra based designs can be formed around many data structures and many languages generalize this concept like Haskell. With Haskell you can create your own algebraic DSL around arrays and anything else you can think of. It seems he's enamored with the specific array instance of algebra based designs and unaware of how it's only one specific case of a general concept.
  - juliangoldsmith 3y ago
    APL wasn't originally a programming language at all. Ken Iverson designed it as a mathematical notation to express and reason about computer algorithms. "Notation as a tool of thought," is how he thought about it. It was implemented as a programming language years after he created the notation in 1960. An APL-like Haskell DSL could be interesting, but to match APL's expressiveness you'd basically need to reimplement all of APL. For maximum generality, one could just skip both APL and Haskell and just use the lambda calculus. I found that a bit hard to work with, though. As far as Numpy and all, they are all directly descended from APL. The difference is that it takes 10 lines of Python to match 10 characters of APL. While the array languages' terseness can be excessive, doing it in Python is not very pleasant either. Anyway, here's somebody who knows more than I do talking about what they like about APL's successor, J: https://www.youtube.com/watch?v=RWYkx6-L04Q https://www.youtube.com/watch?v=RWYkx6-L04Q
- MrJohz 3y ago
  Is it? That seems like a very bold claim. MLs have been at the heart of a lot of language development for the last few decades, both as research languages for various concepts, but also practically: OCaml is fairly famous as a language to write programming languages in. FP isn't something wild and niche, it's discussed fairly regularly even amongst users of mainstream programming languages. Even Go has an FP library now, coming out of IBM of all places. I don't think you can attribute this to ignorance, because it's very clear that Pike is not ignorant of programming language design - even if you disagree with his decisions, he has had tremendous success at implementing his vision. To me it speaks more of disinterest - FP doesn't seem to really register on his radar as a useful mine of PL ideas. That's fine, although I agree with the previous poster that it's ironic to be such a proponent if APL, and yet have such a blind spot to another very fascinating area of his field.
- wojciii 3y ago
  Would Haskel or some other functional language be a part of a typical CS curriculum? I remember having a course about programming paradigms which introduced different languages and we wrote a small project based on functional languages.
  - blibble 3y ago
    it's hard to do theoretical CS without functional languages
  - pjmlp 3y ago
    I expect that in good universities, with rich curriculum. At very least one of Lisp or Scheme variants, ML variants or Prolog variants.
mlochbaum 3y ago
Well, Lisp is just as functional as ML-family languages like OCaml and F#. Haskell's typed/pure FP is a branch off of this. Surely between Pike, Griesemer, and Thompson someone had some ML experience, but this doesn't matter much for the design of Go. More important is that newcomers can't be expected to have ML experience, and a central goal of Go is to be quickly accessible to new programmers. And there was also a focus on fast compile times, fast execution, and low-level control, which are very hard to achieve with immutable data structures. Overall Go's design is very restrained, which I think shows a lot of wisdom on the part of the authors. ML is not the only language slighted: as Rob says, the only bit of APL that made it in was the name "iota"! I think it'd be a bit of a shame if everyone were pushed to be a polyglot with a finger in every currently popular paradigm. Connections between different approaches to programming are very useful, but the sort of effort made in Go, to refine and simplify one imperative/OO approach, also helps push our understanding of programming into new territory.
- corethree 3y ago
  It's the whole (res, error) error handling thing. Seems like there's an obvious solution that was avoided or not known about here. It's not even about being clever. Its about being practical.
  - mlochbaum 3y ago
    Maybe so. I guess you're talking about option types, although it's not obvious to me that these do any better given the requirement that errors are always explicitly shown in the code. So maybe your problem is with that requirement instead. But why are you listening to a podcast in the hopes the guest will admit his ignorance and tell you something you already know, instead of to learn new things?
    - corethree 3y ago
      >I guess you're talking about option types, I'm talking about a more general concept. A kind of type that can be either one thing or another. For example an Int or an Error. You have Product types which are types that are two things at the same time an (int and an error) and you have sum types (int or an error). To illustrate say I have two types that consists of a small finite set of values type A and type B. A = 1 | 2 (cardinality = 2, A can be a 1 or a 2) and another type that consists of 3 B = '1 | '2 | '3 (cardinality = 3, B can be a '1, '2 or '3) A product type is like a tuple or a struct containing both A and B: (A, B). The cardinality of (A, B) is the product of the cardinality of the individual types: 2 * 3 = 6 (1,'1) (1,'2), (1,'3) (2,'1) (2,'2) (2,'3) in other words cardinality is the total amount of possible values that can be represented by the type. A sum type is a type that consists of EITHER A or B: (A | B). The value can be one or the other. The cardinality becomes the sum of the cardinality of the original types 2 + 3 = 5. In this case the sum type of A | B can be one of these values: 1, 2, '1, '2, '3 Go is missing the sum type. It's like the world of math with only multiplication and no addition. You are missing a critical piece of programming. An option type is simply a Sum type with two possible types. (Any | None) But it goes far beyond just Options. For example JSON is not definable as a type in Go. Not without some really awkward stuff (aka reflection lol). You can define it in almost every other modern language: Python: JSONTYPE = None | float | int | str | List[JSONTYPE] | Dict[str, JSONTYPE] Haskell: data JSValue = JSNull | JSBool Bool | JSRational Float | JSString String | JSArray [JSValue] | JSObject (JSObject JSValue) Rust: #[derive(Debug, PartialEq, Clone)] enum JsonValue { Null, Bool(bool), Number(f64), String(String), Array(Vec<JsonValue>), Object(HashMap<String, JsonValue>), } You can define a type completely isomorphic to json in almost every language. You can't do that at all with Go. Literally this popular data format cannot defined in go. How the heck is that suppose to be "practical"? What does go do when it comes to parsing json? I've seen it and it appears to be the ugliest thing I've ever seen. But that's another deep dive. >But why are you listening to a podcast in the hopes the guest will admit his ignorance and tell you something you already know, instead of to learn new things? I just got a job that involves golang and its now a big part of my life as it's now my daily driver. I thought due to the popularity of the language it must be great. What ended up happening was Go feels like a broken language. But maybe I'm wrong. Maybe Rob Pike had a good reason not to include sum types in his language, or maybe he just didn't know about it. Imagine that, my life and the lives of other people defined by the fact Rob Pike didn't know something. That's what I want to find out. Is the popularity of his language really stemming from him and other people not knowing any better? Or is it me not knowing any better? Have I not seen the light? Or have you not? Put it this way. If you read my post and you knew about everything I said here and you love golang... Then you know something I don't. If you learned something then maybe you haven't seen the light.
blankaccount 3y ago
The key quote about go for me was that it was designed to stop google engineers trying to be clever, and clever FP/ML stuff was excluded explicitly
- corethree 3y ago
  I remember this quote. The context of that quote was actually a reference to OOP and design patterns. He started talking about Nomenclature and referred to OOP Design patterns as just spending time creating taxonomy. FP wasn't really referenced at all in that quote. FP definetely has it's own vocabulary, but nowhere near as extensive as OOP.
kfixjviv 3y ago
Previously: "[Pike is] hardly the first hard-core hacker to be ignorant of the degree to which type theory has seen dramatic advances since the 1980s." It's a comment on this quote from Pike: https://news.ycombinator.com/item?id=6821389 https://news.ycombinator.com/item?id=6821389 I think Pike definitely had not, at that point, explored the way types work in ML-style languages.

darthrupert 3y ago

It's entirely possible for an expert programmer and pl designer to have never heard of ML-based languages or FP as a name for the concept.

corethree 3y ago
Possibly. It's wierd he's so enamored with apl which just seems to me like languages focused an algebra designed around arrays. Algebra based designs can be formed around many data structures and many languages generalize this concept like Haskell. With Haskell you can create your own algebraic DSL around arrays and anything else you can think of. It seems he's enamored with the specific array instance of algebra based designs and unaware of how it's only one specific case of a general concept.
- juliangoldsmith 3y ago
  APL wasn't originally a programming language at all. Ken Iverson designed it as a mathematical notation to express and reason about computer algorithms. "Notation as a tool of thought," is how he thought about it. It was implemented as a programming language years after he created the notation in 1960. An APL-like Haskell DSL could be interesting, but to match APL's expressiveness you'd basically need to reimplement all of APL. For maximum generality, one could just skip both APL and Haskell and just use the lambda calculus. I found that a bit hard to work with, though. As far as Numpy and all, they are all directly descended from APL. The difference is that it takes 10 lines of Python to match 10 characters of APL. While the array languages' terseness can be excessive, doing it in Python is not very pleasant either. Anyway, here's somebody who knows more than I do talking about what they like about APL's successor, J: https://www.youtube.com/watch?v=RWYkx6-L04Q https://www.youtube.com/watch?v=RWYkx6-L04Q
MrJohz 3y ago
Is it? That seems like a very bold claim. MLs have been at the heart of a lot of language development for the last few decades, both as research languages for various concepts, but also practically: OCaml is fairly famous as a language to write programming languages in. FP isn't something wild and niche, it's discussed fairly regularly even amongst users of mainstream programming languages. Even Go has an FP library now, coming out of IBM of all places. I don't think you can attribute this to ignorance, because it's very clear that Pike is not ignorant of programming language design - even if you disagree with his decisions, he has had tremendous success at implementing his vision. To me it speaks more of disinterest - FP doesn't seem to really register on his radar as a useful mine of PL ideas. That's fine, although I agree with the previous poster that it's ironic to be such a proponent if APL, and yet have such a blind spot to another very fascinating area of his field.
wojciii 3y ago
Would Haskel or some other functional language be a part of a typical CS curriculum? I remember having a course about programming paradigms which introduced different languages and we wrote a small project based on functional languages.
- blibble 3y ago
  it's hard to do theoretical CS without functional languages
- pjmlp 3y ago
  I expect that in good universities, with rich curriculum. At very least one of Lisp or Scheme variants, ML variants or Prolog variants.

mlochbaum 3y ago

Well, Lisp is just as functional as ML-family languages like OCaml and F#. Haskell's typed/pure FP is a branch off of this. Surely between Pike, Griesemer, and Thompson someone had some ML experience, but this doesn't matter much for the design of Go. More important is that newcomers can't be expected to have ML experience, and a central goal of Go is to be quickly accessible to new programmers. And there was also a focus on fast compile times, fast execution, and low-level control, which are very hard to achieve with immutable data structures. Overall Go's design is very restrained, which I think shows a lot of wisdom on the part of the authors. ML is not the only language slighted: as Rob says, the only bit of APL that made it in was the name "iota"! I think it'd be a bit of a shame if everyone were pushed to be a polyglot with a finger in every currently popular paradigm. Connections between different approaches to programming are very useful, but the sort of effort made in Go, to refine and simplify one imperative/OO approach, also helps push our understanding of programming into new territory.

corethree 3y ago
It's the whole (res, error) error handling thing. Seems like there's an obvious solution that was avoided or not known about here. It's not even about being clever. Its about being practical.
- mlochbaum 3y ago
  Maybe so. I guess you're talking about option types, although it's not obvious to me that these do any better given the requirement that errors are always explicitly shown in the code. So maybe your problem is with that requirement instead. But why are you listening to a podcast in the hopes the guest will admit his ignorance and tell you something you already know, instead of to learn new things?
  - corethree 3y ago
    >I guess you're talking about option types, I'm talking about a more general concept. A kind of type that can be either one thing or another. For example an Int or an Error. You have Product types which are types that are two things at the same time an (int and an error) and you have sum types (int or an error). To illustrate say I have two types that consists of a small finite set of values type A and type B. A = 1 | 2 (cardinality = 2, A can be a 1 or a 2) and another type that consists of 3 B = '1 | '2 | '3 (cardinality = 3, B can be a '1, '2 or '3) A product type is like a tuple or a struct containing both A and B: (A, B). The cardinality of (A, B) is the product of the cardinality of the individual types: 2 * 3 = 6 (1,'1) (1,'2), (1,'3) (2,'1) (2,'2) (2,'3) in other words cardinality is the total amount of possible values that can be represented by the type. A sum type is a type that consists of EITHER A or B: (A | B). The value can be one or the other. The cardinality becomes the sum of the cardinality of the original types 2 + 3 = 5. In this case the sum type of A | B can be one of these values: 1, 2, '1, '2, '3 Go is missing the sum type. It's like the world of math with only multiplication and no addition. You are missing a critical piece of programming. An option type is simply a Sum type with two possible types. (Any | None) But it goes far beyond just Options. For example JSON is not definable as a type in Go. Not without some really awkward stuff (aka reflection lol). You can define it in almost every other modern language: Python: JSONTYPE = None | float | int | str | List[JSONTYPE] | Dict[str, JSONTYPE] Haskell: data JSValue = JSNull | JSBool Bool | JSRational Float | JSString String | JSArray [JSValue] | JSObject (JSObject JSValue) Rust: #[derive(Debug, PartialEq, Clone)] enum JsonValue { Null, Bool(bool), Number(f64), String(String), Array(Vec<JsonValue>), Object(HashMap<String, JsonValue>), } You can define a type completely isomorphic to json in almost every language. You can't do that at all with Go. Literally this popular data format cannot defined in go. How the heck is that suppose to be "practical"? What does go do when it comes to parsing json? I've seen it and it appears to be the ugliest thing I've ever seen. But that's another deep dive. >But why are you listening to a podcast in the hopes the guest will admit his ignorance and tell you something you already know, instead of to learn new things? I just got a job that involves golang and its now a big part of my life as it's now my daily driver. I thought due to the popularity of the language it must be great. What ended up happening was Go feels like a broken language. But maybe I'm wrong. Maybe Rob Pike had a good reason not to include sum types in his language, or maybe he just didn't know about it. Imagine that, my life and the lives of other people defined by the fact Rob Pike didn't know something. That's what I want to find out. Is the popularity of his language really stemming from him and other people not knowing any better? Or is it me not knowing any better? Have I not seen the light? Or have you not? Put it this way. If you read my post and you knew about everything I said here and you love golang... Then you know something I don't. If you learned something then maybe you haven't seen the light.

blankaccount 3y ago

The key quote about go for me was that it was designed to stop google engineers trying to be clever, and clever FP/ML stuff was excluded explicitly

corethree 3y ago
I remember this quote. The context of that quote was actually a reference to OOP and design patterns. He started talking about Nomenclature and referred to OOP Design patterns as just spending time creating taxonomy. FP wasn't really referenced at all in that quote. FP definetely has it's own vocabulary, but nowhere near as extensive as OOP.

kfixjviv 3y ago

Previously: "[Pike is] hardly the first hard-core hacker to be ignorant of the degree to which type theory has seen dramatic advances since the 1980s." It's a comment on this quote from Pike: https://news.ycombinator.com/item?id=6821389 https://news.ycombinator.com/item?id=6821389 I think Pike definitely had not, at that point, explored the way types work in ML-style languages.