Live data from Hacker News

Rob Pike explains why every programmer should know about the array languages

arraycast.com

21–30 of 39 posts

Re: Rob Pike explains why every programmer should know about the array languages

#21
post #6

> 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…

Syntax matters.

Sure, you can learn to read and write what superficially looks like line noise, but the market has spoken: very few people want to.

Look at the success of Tensorflow and PyTorch. They’re also tensor / array programming systems. They’re wildly popular, with at least two orders of magnitude more users each than all array languages put together.

The difference is that they’re built on top of Python, which is famously user-friendly in its syntax.

More importantly: they were parallel and GPU-accelerated from the beginning.

What’s the point of an array-based language if it’s slower and harder to write than the equivalent in mainstream languages!?

Their current niche of “quants analysing time-series data” is tiny and shrinking all the time.

There was even a chap here advocating the speed and terseness of his preferred array-based language.

Meanwhile the equivalent in Rust was something like a thousand times faster and not much longer!

Array-based languages have been infected by a particular style largely unique to certain types of mathematicians: brevity over clarity, obscure syntax over English, idioms instead of identifiers, etc…

They’ll never be popular while they remain purposefully niche, appealing only to the type of developer that uses single-character file names: https://news.ycombinator.com/item?id=31363844

Re: Rob Pike explains why every programmer should know about the array languages

#22

Earlier quoted context omitted.

>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…

Sure, I've run into this when I went to do some language implementation in Go (dumped at [0]; didn't keep up with it just because I didn't have much reason to do it in the first place). I'd prefer ADTs, but I just frowned a bit and used interfaces. Your strong feelings here aren't because this is objectively inconvenient but because you think it's something you shouldn't have to put up with. If there's a factor you'r…

> I know something you don't (the ability to create your own array DSL gives you none of the advantages of a particular array DSL developed over decades of hard work)

I don't see how this has anything to do with golang.

>you know something I don't

That go is missing sum types?

> Go's popular because it got stuff right that other languages in the space like Dart and Swift missed.

The only advantage I see are implementation specific and not language specific. Go has a better ecosystem, it's cross platform, it has extremely fast compilation times. The language itself is independent of these factors. You haven't mentioned any specific advantage by golang as a language here which is my main gripe with it as of now. But if you meant the implementation specific stuff than I agree with you, those are big advantages. It's one of the reasons why a language like python hasn't fully taken over... if python had the speed of C then it would likely even replace go.

Because of this I'm going to have to assume you agree with me. Go from a language design viewpoint is fundamentally broken. You clearly still like it, but you also clearly can't articulate specific reasons as to why. I mean this is normal, if you like something for really long and you learn that you've liked something flawed for years you're not going to flip around in seconds.

Anyway I think Go only appears fundamentally broken. There must be someone who knows why Rob Pike made these choices to leave our really fundamental primitives when designing go. I don't see why yet, and even though you're a supporter of go you haven't clearly elucidated why either.

I'm still waiting on the reasoning why Rob decided to leave out sum types and make go routines a first class feature when the concept of green threads are easily created as library sub rountines. Not being snarky here. I think this reasoning exists, we just don't see it yet. Perhaps someone else does?

Re: Rob Pike explains why every programmer should know about the array languages

#23

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 ab…

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

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.

Re: Rob Pike explains why every programmer should know about the array languages

#24
post #10

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, Adám Brudzewsky, Stephen Taylor and Bob Therriault.

And then Pike begins by saying he doesn't know much about APL.

it doesn't seem like he knows much about anything really

Re: Rob Pike explains why every programmer should know about the array languages

#25

Earlier quoted context omitted.

Sure, I've run into this when I went to do some language implementation in Go (dumped at [0]; didn't keep up with it just because I didn't have much reason to do it in the first place). I'd prefer ADTs, but I just frowned a bit and used interfaces. Your strong feelings here aren't because this is objectively inconvenient but because you think it's something you shouldn't have to put up with. If there's a factor you'r…

> I know something you don't (the ability to create your own array DSL gives you none of the advantages of a particular array DSL developed over decades of hard work) I don't see how this has anything to do with golang. >you know something I don't That go is missing sum types? > Go's popular because it got stuff right that other languages in the space like Dart and Swift missed. The only advantage I see are implement…

I got curious and decided to google around. I din't find anything from Pike specifically, but my overall impression is that the maintainers simply refuse to see significant value in sum types. They do acknowledge the benefits but not their importance. Interestingly, the overwhelming majority of Go users (at least as indicated by this[0] GH issue) do wish for Go to have sum types. My speculation for Pike in particular though is that he's not that important to have significant influence on the evolution of Go.

[0] https://github.com/golang/go/issues/19412

Re: Rob Pike explains why every programmer should know about the array languages

#26

Earlier quoted context omitted.

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?

>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…

JSON numbers are not floats/doubles.

Re: Rob Pike explains why every programmer should know about the array languages

#27
I wish the licensing of APLs were more free. Yes, GNU APL exists and related languages like J are free. However, if you want the APL symbol set your choices are few: GNU APL, Dyalog, or one-man hobby projects. As far as I can tell, GNU APL is more of a historical time capsule than a practical development language.

The array language community seems friendly and exceedingly competent. It also appears to have a strong "get it done" attitude which prioritizes engineering over freedom. The community is tightly entwined with proprietary software.

I can't bring myself to invest the time to meaningfully learn APL because it's hard to see it as a real investment—the community doesn't own its contributions. It looks like trading dollars for arcade tokens.

Re: Rob Pike explains why every programmer should know about the array languages

#28
Shouldn't hurt most programmers to look at problems from a different angle. Or at least allow their brains to re-wire into considering other programming styles.

But that holds for other paradigms too:

https://madhadron.com/programming/seven_ur_languages.html

Re: Rob Pike explains why every programmer should know about the array languages

#29

I wish the licensing of APLs were more free. Yes, GNU APL exists and related languages like J are free. However, if you want the APL symbol set your choices are few: GNU APL, Dyalog, or one-man hobby projects. As far as I can tell, GNU APL is more of a historical time capsule than a practical development language. The array language community seems friendly and exceedingly competent. It also appears to have a strong…

While I am the author of one of those one-man projects, I would like to point your attention towards BQN. It started as a one-man project, but isn't anymore.

As much as I would like people to look at my implementation, if you want to play around with something more complete, and also uses symbols in the same way APL does, then BQN is the one to look at.

Re: Rob Pike explains why every programmer should know about the array languages

#30
post #6

> 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…

Syntax matters. Sure, you can learn to read and write what superficially looks like line noise, but the market has spoken: very few people want to . Look at the success of Tensorflow and PyTorch. They’re also tensor / array programming systems. They’re wildly popular, with at least two orders of magnitude more users each than all array languages put together. The difference is that they’re built on top of Python, whi…

[deleted]
Post reply on HN