Effective Programs - 10 Years of Clojure - Rich Hickey

Here's a video of the creator of Clojure explaining his preference for dynamic vs static languages, and how he came to the choice of making Clojure dynamic, that may help inform your decision: ▶ this video

in “Minesweeper in Clojure” · View on HN

That's quite a judgement call to make based on the utility of error messages. I can't remember the last time I was blocked based on a Clojure error message anyway. Errors are less frequent and usually pretty obvious. I think you're wrong to say core devs don't understand modern programming, but you'd probably be right to say that they didn't prioritize making it approachable and stooping to the lowest common denominator. And it's not just Clojure, but datomic, core.async, spec -- all solving real problems in modern large scale programming with elegance. Watch Rich's 'Effective Programs' talk [1] and lmk if you still feel that he's out of touch with modern large scale programming. I think he's pretty in tune. [1] ▶ this video

in “Clojure Error Messages Are Accidental” · View on HN

We Really Don't Know How to Compute: Gerry Sussman - [link] Zebras All the Way Down: Bryan Cantrill - [link] Jonathan Blow on Deep Work: Jonathan Blow - [link] Simple Made Easy: Rich Hickey - [link] Effective Programs - 10 Years of Clojure: Rich Hickey - ▶ this video The Last Thing D Needs: Scott Meyers - [link]

in “Ask HN: What is your favourite tech talk?” · View on HN

One of the big benefits of clojure being dynamic is that everything is data (e.g. a map, set, vector or list). This is what allows reuse. - The vast core library of functions that manipulate those data structures can be used for everything in your program, cos it's all data. - Most clojure libraries take and/or return data, reducing the need for clumsy adaptors, or even worse not being able to get at the data you need cos the library writer was really enthusiastic about encapsulation of everything they thought was of no use to consumers. - You don't have a person class, you have a map with a first name and last name. Now the function that turns first + last name into full name can be reused for any other map with the same keys. (A rather spurious example, but a real one would take a large codebase and an essay to describe) I can only recommend watching some of Rich Hickey's talks, particularly these ones, they're not entirely about types, but they express the above ideas much better than I can: - Simple made easy [link] - Effective programs ▶ this video - Are we there yet? (this one is more about OOP, but unless you're using something like haskell, idris etc its relevant for your type system of choice) [link]

in “Types, and Why You Should Care [video]” · View on HN

"Enterprise" stuff in a much less "enterprise" way is one usage, hence being based off the JVM. Rich Hickey has also mentioned the concept of "situational programs"[1] which Clojure is used in a lot. Clojure is also used in a wide variety of other areas like data science[2] or desktop applications[3] much like other general purpose programming languages. [1] ▶ this video [2] [link] [3] [link]

in “Clojure 1.12.0 is now available” · View on HN

I guess no one uses Clojure/Script on HN anymore. All of your requirements fit the cluster in designspace that the language was designed to occupy. (cf. 'situated programs' in ▶ this video )

in “Ask HN: Easiest way to build a CRUD app?” · View on HN

The creator, Rich Hickey, explains that Clojure has been explicitly designed for 'situated programs' in this talk: ▶ this video

in “Rich Hickey and Brian Beckman – Inside Clojure (2009) [video]” · View on HN

Honestly, I think this series of blog posts could have had a more complete title: "Principals of Data Oriented Programming (aka, Idiomatic Clojure) " All of these ideas (and I think they are good ones) are inspired heavily by Rich Hickey's talks and rational behind developing the Clojure language (the author of the post states as much). And while you can use these techniques in other languages/paradigms/problem domains, they are really intended to work well inside the constructs of Clojure, and when applied to "information-driven situated programs" [0] (read business applications with dynamic requirements). As for some of the short-comings you mentioned: "But you still need a mechanism to manage mutating data" Clojure supports this through the use of locking constructs like atoms. [1] "I think what it's getting at is that you don't really know the precise type of your data, over time, in a distributed system, so it's good to include the flexibility to handle that. That makes sense to me. but generic data structures aren't necessarily always the right way to handle that." Clojure attempts to bridge the gap between generic data-structures and strongly-typed constructs using run-time specifications. [2] I mean, the ideas presented here can be generally useful, but your mileage may vary if the principals take you too far out of the idiomatic for your particular language/paradigm/problem domain. If that's the case, you could find yourself wasting energy swimming up stream. [0] - [

in “Principles of Data Oriented Programming” · View on HN

Agree with other ppl here, an unnecessarily violent rant, and the point the author makes is kind of lost in the title "Protobuffers Are Wrong". What they really mean is "I think Protobuffers type system could be better". I recently saw a talk by Rich Hickey about Effective Programs [1]. The talk explains why Hickey favors dynamic types, with EDN [2] and transit [3] proposed as an alternative to more statically typed data exchange formats like protobufs and less structured ones like Json (the talk explains the reasons, nearing the end I think). 1: ▶ this video 2: [link] 3: [link]

in “Arguing against using protobuffers” · View on HN

As mentioned, types are in the standard, and certain implementations provide compile time warnings of type and other issues...[0] The biggest non-feature advantage (the condition system is a pretty big feature though missing from everything else) is the mindset of writing programs, which other dynamic languages typically don't get right. The idea of "growing" a program, and responding to change, is part of that mindset and once it's internalized a lot of the language decisions make a lot more sense. e.g. "trace", "break", "compile" are all part of the standard, all available at runtime, whereas in other languages you tend to have a separation of the runtime from any "IDE feature" like debugging break points, tracing function calls, and compiling (not "eval"ing) new code. Other languages + IDEs are getting there but there's so much more to go. In Java land, with the support of things like JRebel, we can make pretty significant modifications to a running program like add/change/remove methods to a class. But what about any existing objects I may have instantiated? Those are left around, referring to the old code. In Lisp, redefining classes works out of the box (no need to wait decades for JRebel to show up), and "update-instance-for-redefined-class" is a standard generic function, which you can write a version of to handle conversion of existing objects. No mysterious old versions of objects running around, you didn't have to bring down the program to restart it, nice. It's a

in “This Old Lisp” · View on HN

I think Rich Hickey described it pretty well when he said (paraphrasing from [0]) that static languages present the programmer with neat little puzzles to solve that feels like we're writing applications but we're just creating intricate types and abstractions. I think he has a point, but I certainly don't want to give up the benefits of static languages, like being able to catch all of my silly errors. [0] ▶ this video

in “Why I never finish my Haskell programs” · View on HN

I don't find that too surprising, Rich tends to let things bake internally (in his head and at Cognitect) for a while before releasing anything publicly for consumption and feedback. Most of Clojure's current development is around tooling [1] and some changes to move clojure.spec out of alpha. I believe they want to accomplish this for 1.10, but I'm not sure where I remember hearing that. Alex Miller has mentioned that Cognitect built and continues to work on a tool that tracks all of your functions with spec definitions and generatively tests them only when the function or one of its dependencies changes. This would be extremely helpful since generative testing can be expensive to run, especially if you want to generate huge amounts of test cases. It'd be nice to say "test all of my codebase's functions 10 million times" and then have that information stored locally with the code. In Rich's "Effective Programs" talk [2] he outlines the "10x problems" that Clojure was targeted at solving. In it there are two 10x problems that weren't solved by Clojure: resource utilization and libraries. There's not much Clojure can do to solve resource utilization as it's dependent on the host (JVM), but the library problem (especially Clojure libraries with spec definitions) is solvable (though there seems to be some disagreement on whether only allowing growth in libraries in a practical). Pure speculation: All of their tooling projects (spec, codec, tool.deps, and the above mentioned gene

in “Problem Solving and Clojure 1.9 with Rich Hickey” · View on HN

What do you mean by "doesn't have monads?" You just write monads in Clojure. They are only a structural formalism. [1] If you meant doesn't have the Maybe monad built in... why would you want that tangled up in your data? [2] [1] [link] [2] ▶ this video

in “Is Haskell the right language for teaching functional programming principles?” · View on HN

> `a -> a`; `[a] -> [a]`; It means nothing! It tells you nothing ! — Rich Hickey, Effective Programs [0] [0]: ▶ this video --- A disastrously poor take. I used to work at a Clojure company, and there's no chance I'd ever go back to that.

in “Clojure: The Documentary, official trailer [video]” · View on HN