Hey Zach, thanks for writing Elements of Clojure. The chapter on names was a fascinating read.
What books/resources on distributed systems or software in general would you recommend to read?
What has motivated you to create all your OSS libraries?
And what’s your typical workflow like for a new piece of code?
I think I agree with your definitions. Ontology is “that which is” and teleology is “that which ought.”
I’m not saying that purposeful effects (affects) - or the purposive interface - cannot be independent of implementation. Just that there is always some implimentative, ontological context from which those oughtful statements derived. And in our heads, those oughtful statements exist over an otherwise un-oughtful substrate. And when we put them into computers, they are again hosted over an otherwise un-oughtful substrate.
So, yeah, I’m saying that some ontology always encompasses a functional interface. But I’m not just saying that in the sense that, “hey, everything is relative.” I think that this ontological/teleogical relationship may produce a certain amount of necessary syntactical baggage, which scales at some constant rate relative to problem size. Something akin to universal, sort of mathematical law of metabolic scaling as a contention between purposes and the incidental complexities it takes to get there for a given hosting ontological context.
Software in general is pretty broad, but I’ve compiled a rough bibliography here that you might find interesting. I especially recommend Data and Reality.
As far as distributed systems go, Nancy Lynch’s Distributed Algorithms is a good formal resource, and Gerald Weinberg’s An Introduction to General Systems Thinking is a good informal resource.
Pretty much everything I do is to motivate myself to understand something better. If a project has an obvious path to completion, I generally never get around to doing it.
I start with a single file, and try to thread together simplistic end-to-end functionality, and then start filling in the pieces. Tests come later, but as I’m changing things there’s some small set of code I can run at the REPL to make sure everything still fits together. This helps me decide how the project should actually be structured.
And I’d say that the model behind an interface, usually in a high level language, is a teleological gestalt built on top of a lower level (within the hierarchy of ontologies) model of reality. That lower level model is again just a gestalt sitting on top of yet a lower level ontology, until we reach the ones and zeros, which are the non-teleological mass of our programs.
Anyway, not trying to derail your AMA, but I thought these Aristotelian ideas around syntactic baggage were related to your ideas on naming things, and I’ve been wanting to ping you about them for a while, as I’ve been reading through the book. Perhaps we can spin this off into another conversation if your interested.
A question more specifically about the book: While you called it “Elements of Clojure” it’s really not just about clojure, but in some ways programming more generally, as you’ve explained. And now that Clojure is 10 years old, I wonder, how would you say Clojure itself has effected your ability to write this book? Do you think you would have written in had Clojure never existed? (for some other language, perhaps) In what ways has Clojure impacted the thinking that contributed to your more general ideas on programming in the book?
Hey Zach, how’s Lacuna going? Can you talk much about your plans for it?
Also, thanks for bifurcan, it’s lovely.
Yeah, feel free to email me, my contact info is on my site.
Clojure has definitely shaped how I think about software. Once you start to really distill things, there’s a certain convergence (the interface, the process, etc. exist pretty much everywhere), but the perspective of the book is that of a Clojure programmer. Maybe once I have more perspective on these ideas I’ll be able to answer the counter-factual of “what if I had gone deep into some other language”, and I’ll be able to write an “Elements of Software”. That probably won’t be any time soon, though.
Slowly. This week is honestly the first time I haven’t had most of my attention on the book. My current plan is to spend the next six months playing with some different approaches, and then start releasing screencasts, etc. to explain what I’m trying to accomplish. If I get a good response, I’ll work another six months towards creating an alpha-quality prototype and do a Kickstarter. Hopefully I’ll show more discipline in the face of scope creep than I did with the book.
What are you using Bifurcan for?
What’s the story on heron? I’ve actually been thinking about using spec to exercise some automatons! 
It’s an attempt to make a more reusable version of Automat, which has faster compilation of the automata. But if you’re just trying to build on top of spec, Automat should work just fine for you.
Nice! Well your code has always been educational and inspirational and your book has followed suit, so thanks for all the work you’ve shared! Keep it up!
I’m using it in a few internal projects, basically any time I want persistent data structures in Kotlin. In Cursive itself I currently just use the Clojure ones, but I may switch to Bifurcan for some use cases there to stop Clojure being eagerly loaded. I also at one point thought I had a great use for IntMap for an optimisation problem, but in the end I just simplified my life instead and didn’t need it.
If you feel comfortable answering, how do you approach programming work? (As a superficial example, some work many hours then take days off; some work few hours with efficiency; some procrastinate their asses off then hate their past selves. Or maybe you see it in totally different terms.)
Are there any tips you’d like to share, about being prolific and/or doing good work?
[I’m asking quite a few questions, so of course choose only those you feel like answering.]
What attributes did your best coworkers/collaborators have?
What attributes would you like to see in coworkers/collaborators, if not mentioned above?
How would you like the Clojure community to better organize? (In a way actionable by non-Cognitect workers?)
I have never been able to do more than six hours of truly focused work in a day, and most of the time fall short of that. Earlier in the thread I described my writing process as “waiting until I feel like I’m going to vomit words”, and the same is true for software. I wait until the next few steps feel obvious, and then try to get it all down before I lose that clarity. Since it can take a while to reach that step, I tend to have at least four different projects going at any given time, which seems to increase my chances of being able to make progress on something.
This isn’t a great fit for professional environments (you just look like you’re sitting around dawdling), but I’ve found most software problems in a business do have obvious solutions. At the very least, when starting a project you can chip away at the easy parts, and build your way up to the hard ones.
I’ve always enjoyed it when someone is passionate about a topic and also skilled at explaining it. This passion sometimes needs to be balanced by the people around them (they love to use their hammer), but I’ve always learned a lot.
Also, I’ve found that people who have gone deep on one topic are better at evaluating how well they understand other things. I’ve interviewed a lot of people, and a common issue with more junior candidates is they seem to think that “knowing” a language is knowing its syntax, and maybe its core library. This makes them slower to ask for help, because they think having trouble with something is a reflection on them, rather than a natural part of the learning process.
I think knowing one thing well, even if it’s entirely unrelated to software, makes learning new things much easier.
I think a lot of the frustration in the community stems from the fact that Cognitect treats Clojure as a technology rather than a product. But this has been true for a decade, and I don’t think it’s reasonable to expect it will change, even if everyone complains a lot.
What we need is a steering committee, drawn from the community, that owns the task of “productizing Clojure”. This encompasses creating a standard process for people looking to learn the language, identifying “best in class” libraries for common problems, creating frictionless means for people to contribute back to the community, and so on. Clojurists Together has made some important progress in this direction, and I encourage anyone who wants to become a member, as I think a lot of what I describe above will fall out of what they’re doing.
Alright. We’re approaching the 24hr mark. I will close this topic now.
Thanks @ztellman for answering so many questions and hope to see you around for the book club and other stuff! 
Have a nice easter weekend everybody!