Tim Ewald - Clojure: Programming with Hand Tools
ClojureTV9 HN recommenders · 2014–2024
48K views · talk · evergreen · Uploaded 2014-01-08
Tim Ewald's Clojure/conj talk uses furniture making with hand tools versus machine tools as an allegory for software. It explores how automation changes what we make and how we think about our work, and why Clojure's small set of simple tools matters.
HN repeatedly names it among the best programming talks, loved for its craftsmanship message that complex tooling can hide simpler solutions.
53:22Ruby Conf 12 - Y Not- Adventures in Functional Programming by Jim Weirich
Confreaks
42:03The Soul of Erlang and Elixir • Sasa Juric • GOTO 2019
GOTO Conferences
1:01:39"Simple Made Easy" - Rich Hickey (2011)
Strange Loop Conference
25:06"Making Impossible States Impossible" by Richard Feldman
elm-conf
1:31:06William Byrd on "The Most Beautiful Program Ever Written" [PWL NYC]
PapersWeLove
1:03:55🚀 TDD, Where Did It All Go Wrong (Ian Cooper)
DevTernity Conference
31:44The Value of Values with Rich Hickey
InfoQ
32:56Bret Victor The Future of Programming
Joey Reid
15 comments from Hacker News
There was a talk at Clojure/conj by Tim Ewald on just that: [VIDEO] "Programming with hand tools" Lots of conference reviews nominated it in their favourite talks too.
It's funny, even as someone who knows js really well, having worked with it for a decade (actually, longer!), the explosion in the ecosystem took me by surprise. I left my web agency role over a year ago to work on my start up with a friend so I've been in relative developmental isolation (lots of python and js, not so much keeping up with the latest trends). I came back to help out on a project recently and had to spend a day researching all the new tools. Particularly around package management, bower, grunt, yeoman, node, npm etc. A year ago a js lib was generally delivered as a js or min.js file. Now there's the whole system to sit around it; every project on github now seems to include the config for each of the different package managers. Even a vagrant file so you can get it all up and running on a brand new vm. Something as simple as adding bootstrap to a project. It's not totally obvious when you first look at it. Where does the code go? How do you compile it in such a way that you don't touch the vendor src itself but you can customise it etc. I have a method that works for me, but I had to play around a little to figure out how to fit it to my needs. Once I got through that stage I was really happy with where things were at. JS libs are nice and easy to install and version control now, dependency management with bower has worked really well for me so far. Grunt makes the automation side of development nice, contained and easily shared. All in all it's a really good
The "wat" is a good first step in identifying problems. However, I see is people getting stuck on "wat" and not moving forward. People would rather win an argument than advance knowledge & the practice. Lot's of ego, programmers have. In the mean time, one can learn to appreciate & use javascript strengths. It can be quite fun, liberating, & useful. Anecdotally, I have not run into these crazy issues, and I program in javascript everyday. I also have a large app and the framework I built is custom. I liken this to using C++, Unix, & bash as a base. Yes, you could say these tools suck and spend time creating, marketing, & community-building for a new tool. Or you can iterate & improve upon these existing tools. There's no wrong answer. What do you want to accomplish? > Sushi knives don't decide to cut you because the rice came from a different origin. That analogy seems like a stretch. Care to explain? Javascript works with different locales. There are many international websites that use javascript. Also, javascript does not "decide" to create a bug in your program. You create that bug by misusing the tool. You will get further if you take some responsibility and improve your practice. > And I'd guess that most craftsmen, outside of a ritual and tradition would love for their tools to have less disadvantages. I agree with that. Usually the improvements are iterative. One could use a laser cutter (which does not need sharpening) to cut sushi, but that would also burn it. Here'
We build complicated software with simple tools where I work using Clojure. There's even a talk about Java:Powertools::Clojure:Handtools! [1] [1] - [VIDEO]
Can't help but mention this great video where an enthusiast woodworking engineer makes a parallel between tools in the real world and tools in computing: [VIDEO]
I gotta throw in one of my favorites, because I have not seen another that really speaks so directly to the value of craftsmanship in development. I also deeply enjoyed the allegory with woodworking tools. [VIDEO]
I also think it seems pretty appealing. There have been some interesting things on HN over the years about it. I loved this talk about how the tools you use determine how you look at problems (Tim Ewald - Clojure: Programming with Hand Tools) [VIDEO] And if you haven't seen him before, you're about to fall in love with Matthias Wandel: [LINK] [LINK]
I'm not a Closure coder but I loved this talk on how as your tooling becomes more complex and automated, you start to lose sight of simpler solutions to problems. It's all about woodworking! Tim Ewald - Clojure: Programming with Hand Tools [VIDEO]
Must-see presentation (~1hour) for anyone interested in this topic is "Programming With Hand Tools" by Tim Ewald: [VIDEO]
Interesting presentation that explores your question. +1 intersection from this commenter. Tim Ewald - Clojure: Programming with Hand Tools [VIDEO]
Learn Clojure. Then you can spend the rest of your life building with hand tools, lol: [VIDEO] (Seriously, though, Clojure is awesome—but occasionally I miss the guardrails of a framework.)
Good article! Two things popped into my head when reading it. First the talk "Programming with Hand Tools" by Tim Edwald[0]. It's a very cool, entertaining talk with emphasis on the craftsmanship side of things and provokes thinking about which parts to automate (or maybe abstract away) and which parts to craft by hand when we're building stuff. Aside: also reminds me of Casey Muratori's Handmade Hero project [1]. He is a strong advocate for structuring things bottom up and building them ourselves. [0] [VIDEO] [1] [LINK] --- Secondly when reading this: > Regardless, the basic idea is that companies are often faced with the decision of doing N units of shitty work or far fewer than N units of great work. This is obviously oversimplified, but there is an important point that wants to emerge from this line of thought. As someone who grew up on open source, standardized technologies and the Web, I have been empowered to build a livelihood on Web development, mostly "self-taught" (or rather self-directed). All of this Web stuff is very accessible and gives you actual _leverage_. You can build something useful very quickly and the community around it is happy to share so much knowledge and work. I'm _very_ thankful for that. But I think as the wider web development community we're losing sight of what that essence is. We started to think of the Web as merely a vehicle for pure scale as in "how to reach the most people and annoy them with notifications" and "how to produce cheap sof
Unless it's my tiny phone screen I'm surprised this video did not surface yet [VIDEO] (Tim Ewald - Clojure: Programming with Hand Tools)
"Programming with hand tools" (Tim Ewald, Clojure Conj 2013) is a very memorable talk on this theme: [VIDEO]
Time Ewald makes a case for "Programming with Hand Tools" in this talk he gave at Clojure/conj 2013. He too makes a connection with wood working. [VIDEO] Summary: For most of human history, furniture was built by hand using a small set of simple tools. This approach connects you in a profoundly direct way to the work, your effort to the result. This changed with the rise of machine tools, which made production more efficient but also altered what's made and how we think about making it in in a profound way. This talk explores the effects of automation on our work, which is as relevant to software as it is to furniture, especially now that once again, with Clojure, we are building things using a small set of simple tools.