Code Quarterly's Interview with Rich Hickey | Hacker News Reader

Code Quarterly's Interview with Rich Hickey

codequarterly.com

160 pointsfogus44 comments

I loved this:

> When we drop down to the algorithm level, I think OO can seriously thwart reuse. In particular, the use of objects to represent simple informational data is almost criminal in its generation of per-piece-of-information micro-languages, i.e. the class methods, versus far more powerful, declarative, and generic methods like relational algebra. Inventing a class with its own interface to hold a piece of information is like inventing a new language to write every short story. This is anti-reuse, and, I think, results in an explosion of code in typical OO applications.

I think he has a good point, and as someone who really likes functional languages, I agree with him, but I think there really needs to be a better explanation of functional "patterns" and how to structure large functional programs before it will catch on more.

Also, it's easy to say, "object-oriented programming is bad for reuse," but that's not all OO is for (i.e. encapsulation, etc.).

I'd have to go back through the literature, but reuse was not something I heard talked about much at all when I first seriously started doing OO in the 90s.

With that said, reuse with OO today is not in a horrible state, no pun intended. Things can certainly be easier, but I think design is the bigger issue. And the problems I see suffer in functional designs as well as OO designs.

I'd have to go back through the literature, but reuse was not something I heard talked about much at all when I first seriously started doing OO in the 90s.

Maybe it was an '80s thing, but I recall "reusable software components" being touted as the industry savior. OO was all about reuse then.

See Fred Brooks's "No Silver Bullet". If I remember correctly that was one of his hopes for OO...

Encapsulation is also addressed in the article. I really liked his response to that too, it was like a more succinct version of the Steve Yegge Wikileaks/Java private methods blog post[1] that did the rounds a few months back.

[1] - http://steve-yegge.blogspot.com/2010/07/wikileaks-to-leak-50...

> I think he has a good point, and as someone who really likes functional languages, I agree with him, but I think there really needs to be a better explanation of functional "patterns" and how to structure large functional programs before it will catch on more.

Are there any good existing resources for learning these things?

It's really hard to beat Hickey's Clojure Bookshelf, http://www.amazon.com/Clojure-Bookshelf/lm/R3LG3ZBZS4GCTH. I've found the Standard ML books to be particularly illuminating as far as structuring functional code.

Apparently he reads those books while lying in a 'Presidential Cotton Rope Hammock' [1], which is at the bottom of his Bookshelf list ;-)

[1] http://www.amazon.com/Presidential-Cotton-Rope-Hammock-Size/...

It's a reference to this talk: http://blip.tv/clojure/hammock-driven-development-4475586

What is simple informational data? I've never heard that term before, and its not obvious what he's referring to.

I took it to mean data objects.

He expands on that when he talks about an "associative model" of information.

His argument against using classes/objects is that objects (in mainstream PLs) can't be accessed in a dictionary-like fashion.

But switching to dictionaries wholesale for this reason seems to throw out the baby with the bathwater. The loss of abstraction is real, and could be worked around trivially by making every object respond to a dictionary protocol. This would give you the best of both worlds.

Don't most mainstream languages now give you this?

I think Javascript, C#, Ruby, Python give you this. C++ and Java don't.

And as you say, you do lose a fair bit giving this away.

No all those languages suffer (except JS) from the fact they don't give you uniform access. Consider the different forms of access for dict types, array types, object types in said languages.

I have to admit that this distinction seems really minor. But maybe I'm missing something here. I'd love to see an example if anyone has one.

  (get "foo" 0)          ; \f
  (get {:foo 'bar} :foo) ; bar
  (get #{0 1 2} 1)       ; 1
  (get [:a :b :c] 1)     ; :b

  (def path [0 :foo 1])
  (get-in [{:foo "bar"} 1 2] path) ;\a

Being able to deal with data generically in a first class manner is very, very useful. You can only get this in all the languages you've mentioned (including JS) w/ more or less custom code writing.

> and could be worked around trivially by making every object respond to a dictionary protocol. This would give you the best of both worlds.

You do realize that's the approach Clojure takes right?

The whole point of OO is that you don't want code reaching into the internal member data of the object. The real reason that algorithmic code reuse is so difficult in C++ and Java is that they lack usable first-order function literals.

Not to mention that lack of structural typing and Mixins make it even harder to actually have reuse. Dynamic languages like Python and Ruby solve this beautifully, and so do Go and Scala on the more static type side.

> generic information manipulation code... requires the capability to generically access/modify/add properties by name/key, ... etc

Java reflection does much of this. Though you can't add properties.

He's against types, and only values them for performance. Yet, the relational algebra that he admires uses types (the definitions of tables - "schema"). Although they're flexible types, in that you can change schema definitions (schema are themselves tables). And you can invent new schema willy nilly (e.g. result of a join). They are types in that each row (or instance) in a table has a value for each column in the table.

The relational algebra is one of the most successful and enduring innovations in computer science - and it also has a solid mathematical basis. It's dynamic types may be a good guide to the value of types other than for performance.

What are some examples of functions that take advantage of having this sort of dictionary-like access to objects?

As just a trivial example, compare the following:

    order.getLineItem(2).getQuantity();
    
    (get-in order [:lineitems 2 :quantity] 1)

The first is simple enough, but it's essentially a DSL. No code that doesn't know about that API can work with those objects. If I want to guard against null objects I have to re-do that sort of work over and over again.

Contrast with the latter, where the get-in function just treats the subject as a nested associative structure. It can handle the null checking, and it doesn't care what my keys look like.

When I briefly used Clojure, I was very impressed with clojure.set. (Probably the "relational algebra" Hickey mentioned in the interview, with operators like project, rename, join, etc. Stuff that anyone who knows SQL will be familiar with. A good example of what such abstractness buys you.)

ClojureQL - bringing Relational Algebra back to Relational Databases

http://blog.bestinclass.dk/index.clj/2010/11/clojureql--1.0....

I have to admit, the first line looks like better code in my eyes. The only "advantage" of the second one is that it "handles" null checking. Which really means that I still need to handle what happens when order is null, versus, the non existence of line items, or the non existence of quantity.

The only real advantage I see from the second line version is that I can write that code and run a partially completed program, that for example doesn't have a notion of orders at all -- and the program can still run. But I guess this just boils down to preferences.

PurchaseOrder rather than ScheduledThreadPoolExecutor.

I liked this quote: > A bad design with a complete test suite is still a bad design.

`Rich Hickey dubbed his tendency to spend more time thinking about problems than typing code as “Hammock-Driven Development”. ` in the foot notes ;-)

He actually gave an entire talk on the subject at Clojure Conj

http://blip.tv/clojure/hammock-driven-development-4475586

How much to spend reading and how much time to spend in programming exercises / programming for yourself? Now I have a daily job and it's hard for me to find the right equilibrium between learning new techniques and stuff and just creating something new with what I already know.

(I read relentlessly, too; English is not my native language though so sorry for the grammar)

It's not about reading, it's about doing.

I'm not here to convince you otherwise if you dislike reading, but for many it's not as black and white as you present. In fact most of the greatest hackers I've ever met were also among the most voracious readers (Rich Hickey included).

In doing, there is a lot of reading. Every line of code you write you will likely read dozens of times. And if you are writing anything significant, they will be read many more times by others.

Why doesn't Code Quarterly have an RSS?

Haven't gotten around to it yet. Definitely on the list.

I was expecting to see some reference to fortress, scala and abcl in order to discriminate what's important about Clojure. An important question: Of those books listed, are there any you think every programmer should read?, yes, Fogus, your book should be read by all programmers.

Does anyone here use clojure in production? Is it useful in a webapp context? With a SQL DB?

A list of some people using Clojure in production here, http://clojure02.managed.contegix.com/display/community/Cloj...

Recently posted in HN, the Clojure web stack:

http://brehaut.net/blog/2011/ring_introduction

We use it at work (Sonian) for backend archival and indexing, but there's a more comprehensive list of users: http://dev.clojure.org/display/community/Clojure+Success+Sto...

I love clojure, wrote a web crawler in clojure at my last job. But, I still think rails is the best way to write a webapp if you have a lot of user interaction. If it's primarily a REST api or something like that, then clojure would work great.

I've used Clojure in production. Specifically I coded database driven system monitoring app with a web interface, so I can say it works fine with SQL and in a webapp context.

Reply on news.ycombinator.com