Hacker News Reader

Comment by mikebenfield | Hacker News Reader

Yeah I heard him say that and to be perfectly honest I don't know if I believe he truly thinks that. This is a man who devoted years of his life to create a new programming language because he found it difficult and frustrating to use existing languages. In this talk and many others he talks about how he believes Clojure's features (like dynamic typing and dynamic dispatch and the whole keyword system and others) are really key to writing good software and how many other features (like static typing) are irrelevant or harmful... and now here he's saying programming languages don't matter much?

View on HN

But notice that his arguments are always focused on the tool/feature.

You can look at Clojure as a "reference implementation" for many of Hickey's ideas. (A production-ready reference implementation, of course.)

But all of Rich's ideas/"features" can be applied in your language of choice. (Immutability, functional programming, avoid-ADTs, how one should do versioing, etc.) I've employed many of these and other of Rich's ideas effectively in Java. The ergonomics would be better in Clojure, of course, but for (probably good) political reasons I have to use Java at work.

Just notice that Rich's rhetoric is nearly always focused on specific problems and solutions that transcend Clojure.

> But all of Rich's ideas/"features" can be applied in your language of choice.

Not just can, but have been and are. Clojure is one of those languages (like SmallTalk) where, even if it's not the most "successful" or "popular" language in the long run, it has had an oversized impact on how we program in general.

Genuinely curious...what are these over-sized impacts?

I think Clojure contributed to the functional and meta programming resurgence. It didn't innovate on any one feature, but it brought a whole lot of old forgotten ideas back together, and showed their value.

Immutable data structures?

Like... Singly linked lists?

I even remember using VLists (work by Philip Bagwell, that probably inspired the data structures in clojure) in 2006, and I am not even a programmer.

Yea, not VList exactly, but similar and also pioneered by Phil Bagwell. They're implemented as a trie under the hood. And provide a list or set or stack or queue or map like interface. You can not mutate the value at any node, instead edits are diffs in the tree, a bit like git commits.

So they end up being almost as fast as their normal mutable counterparts, and with similar and sometimes better memory consumption, because nothing is ever copied under the hood.

This allows them to be good enough to be made the default datastructures. Clojure was the first to make this gamble, and show that the state of the art immutable datastructures mostly pioneered by Bagwell were practical and could replace immutable ones for the 99% use cases.

No: the idea that immutable is a sensible default, and active enforcing of immutability. In Java, e.g., a linked list's cell might be immutable, but its contents are most likely mutable - so back to page one. It is definitely possible to write code for structures that are immutable by interface or convention, but the environment does not help you doing so.

Clojure did not invent immutable data structures!!

Somehow a language is only an attempt at incarnating principles. It also evolves to go closer to that.

He mentioned he liked Common Lisp but they didn't let him use it in production, so he created a Lisp that runs on an industrial runtime.

Which is a little weird, because (as I mention elsewhere), there's Armed Bear Common Lisp, which is a Lisp which runs on the JVM. Seems to me that he could have saved a lot of time an effort just sticking with Common Lisp.

He'll argue, of course, that the time & effort are worth it for immutable data structures. I'm unconvinced, but that's the great thing: we don't all have to agree! I'm glad he's having fun.

Immutable data structures were part of it, but not the whole story. From the article:

"But Lisp had a bunch of things that needed to be fixed in my opinion. It was built on concretions, you know, a lot of the design of more abstractions and CLOS and stuff like that came after the underpinnings. The underpinnings didn't take advantage of them so if you want polymorphism at the bottom, you have to retrofit it. If you want immutability at the core, you just need to, you need something different to, you know, from the ground up. And that's why Clojure was worth doing as opposed to trying to do Clojure as a library for Common Lisp. The Lisps were functional kind of, mostly by convention. But the other data structures were not, you had to switch gears to go from, you know, assoc with lists to, you know, a proper hash table. And lists are crappy data structures, sorry, they just are. They're very weak, and there's no reason to use them as a fundamental primitive for programming. Also packages and interning were very complex there."

Yeah, I understand that. But if he really didn't care much about programming languages, why wouldn't he just use C++, which he was allowed to use in production?

Rich was a professor of an advanced C++ class (at NYU, I think) in the late 90s, and wrote a very popular paper on how to get some killer performance out of that language. He's been around the block and knows a thing or two about these things.

I don't understand how this is a reply to my comment.

He talks about that quite a few times in the video.

Yes, and the things he says about it indicate he does think programming languages are important.

I think there may be a bit of people talking past each other here. I think one can reasonably say that which language one uses isn't as important as which features that language has. Also, there comment you originally responded says "that programming languages (including his own) are the most important aspect of doing our programming work well." That doesn't mean that the language or its features aren't important. They're saying that it's not the most important thing.

The hierarchy Rich refers to[0] puts domain complexity and misconception as 10× more important than anything that's language specific. I believe this is the basis of the quote I pulled. I think this is compatible with thinking that language features are important, but domain complexity and misconception are more important issues when tackling a problem with code.

[0]: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

Reply on news.ycombinator.com