[HN Gopher] Rob Pike explains why every programmer should know a...
___________________________________________________________________
Rob Pike explains why every programmer should know about the array
languages
Author : bobterryo
Score : 36 points
Date : 2023-08-19 05:31 UTC (17 hours ago)
(HTM) web link (www.arraycast.com)
(TXT) w3m dump (www.arraycast.com)
| corethree wrote:
| 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 wrote:
| 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.
| wojciii wrote:
| 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 wrote:
| it's hard to do theoretical CS without functional languages
| MrJohz wrote:
| 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.
| corethree wrote:
| 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.
| kfixjviv wrote:
| 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
|
| I think Pike definitely had not, at that point, explored the
| way types work in ML-style languages.
| blankaccount wrote:
| 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
| mlochbaum wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| >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
| values. (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. 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.
| bobterryo wrote:
| Rob Pike, co-creator of the Go language and UTF-8, tells us why
| every programmer should know about the array languages.
|
| Host: Conor Hoekstra
|
| Panel: Marshall Lochbaum, Adam Brudzewsky, Stephen Taylor and Bob
| Therriault.
| gumby wrote:
| And then Pike begins by saying he doesn't know much about APL.
| juicypt wrote:
| That's really weird, since he did implement a calculator that
| uses a dialect of APL: https://aplwiki.com/wiki/Ivy
| medler wrote:
| I think he's sort of being humble and also admitting that
| he's not a true expert. It's clear he has more than a
| passing familiarity with APL.
| medler wrote:
| > whenever something APL related comes up on Hacker News, it's
| always in the form of arcana you'll laugh at rather than
| fascinating work being being done by very smart people. I find
| that offensive, but I'm not going to push back on that. I don't
| talk on Hacker News. But I've seen a lot of interesting things
| being posted about it, and the comments are always almost
| universally, like: "what the hell is that for?". And not
| understanding that that language was once the best interactive
| language out there, and in many ways still is. And there's some
| phenomenal stuff being done with it. But it's hived off somehow
| from most of the rest of the computing world in a way that, for
| instance, Lisp (which is, I think, an almost contemporaneous
| language; Lisp was a little earlier, but similar) ... Lisp is
| sort of part of the universe of programming that people
| understand. They'll laugh at it, but they understand it, and they
| know what to do with it. And APL is something altogether
| different. I think that's a shame.
|
| I will admit my interest in learning APL has been piqued. Though
| I do find it odd that they never once mention the most popular
| array programming language of all time, MATLAB
___________________________________________________________________
(page generated 2023-08-19 23:02 UTC)