HackerTube
HomeLongsLikedHistoryWatch laterCategoriesPlaylistsSettings

Tim Ewald - Clojure: Programming with Hand Tools

ClojureTV9 HN recommenders · recommended in 10 months, 2014-2024
YouTube
48K views · 12 years ago · talk · evergreen

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.

Functional programmingSoftware practice, open source & careersWoodworking, metalworking & workshop skills#clojure#woodworking#handtools#automation#craftsmanship#simplicity

15 comments from Hacker News

@adityaathalye2024 · in “Why software engineers like woodworking (2021)”

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. ▶ this 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.

RecommendsView on HN
@refset2024 · in “Why software engineers like woodworking (2021)”

"Programming with hand tools" (Tim Ewald, Clojure Conj 2013) is a very memorable talk on this theme: ▶ this video

RecommendsView on HN
@fmjrey2022 · in “Why software engineers like woodworking”

Unless it's my tiny phone screen I'm surprised this video did not surface yet ▶ this video (Tim Ewald - Clojure: Programming with Hand Tools)

RecommendsView on HN
@dgb232021 · in “Automation != Leverage”

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] ▶ this 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

RecommendsView on HN
@kbuchanan2021 · in “Why I Hate Frameworks (2005)”

Learn Clojure. Then you can spend the rest of your life building with hand tools, lol: ▶ this video (Seriously, though, Clojure is awesome—but occasionally I miss the guardrails of a framework.)

JokeView on HN
@datahead2020 · in “Cheap Router Table and Lift”

Interesting presentation that explores your question. +1 intersection from this commenter. Tim Ewald - Clojure: Programming with Hand Tools ▶ this video

RecommendsView on HN
@ludwa62020 · in “Woodworking for Engineers”

Must-see presentation (~1hour) for anyone interested in this topic is "Programming With Hand Tools" by Tim Ewald: ▶ this video

Strongly recommendsView on HN
@aidos2018 · in “Ask HN: What are some of the best technical talks you've heard?”

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 ▶ this video

RecommendsView on HN
@aidos2017 · in “Ask HN: If you were to switch career, what would you do?”

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) ▶ this video And if you haven't seen him before, you're about to fall in love with Matthias Wandel: link link

RecommendsView on HN
@spacemanmatt2016 · in “Talks that changed the way I think about programming”

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. ▶ this video

Strongly recommendsView on HN
@fmjrey2016 · in “Beginning Woodworking”

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: ▶ this video

RecommendsView on HN
@escherize2016 · in “Why I hate frameworks (2005)”

We build complicated software with simple tools where I work using Clojure. There's even a talk about Java:Powertools::Clojure:Handtools! [1] [1] - ▶ this video

CitesView on HN
@briantakita2014 · in “The Birth and Death of JavaScript [video]”

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'

CitesView on HN
@aidos2014 · in “JavaScript: The Right Way”

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

CitesView on HN
@mark_h2014 · in “Best development book I've read, has no code in it”

There was a talk at Clojure/conj by Tim Ewald on just that: ▶ this video "Programming with hand tools" Lots of conference reviews nominated it in their favourite talks too.

RecommendsView on HN
clojure.core/typing - Matt Adereth35:41

clojure.core/typing - Matt Adereth

ClojureTV
40K views • 10 years ago
Effective Programs - 10 Years of Clojure - Rich Hickey1:14:52

Effective Programs - 10 Years of Clojure - Rich Hickey

ClojureTV
176K views • 9 years ago
"Simple Made Easy" - Rich Hickey (2011)1:01:39

"Simple Made Easy" - Rich Hickey (2011)

ClojureTV
434K views • 5 years ago
Expert to Expert: Rich Hickey and Brian Beckman - Inside Clojure53:56

Expert to Expert: Rich Hickey and Brian Beckman - Inside Clojure

jasonofthel33t
119K views • 13 years ago
Solving Problems the Clojure Way - Rafal Dittwald1:02:26

Solving Problems the Clojure Way - Rafal Dittwald

Clojure/north
87K views • 7 years ago
Clojure for Lisp Programmers Part 1 - Rich Hickey1:28:59

Clojure for Lisp Programmers Part 1 - Rich Hickey

ClojureTV
25K views • 13 years ago
Zach Oakes - Making Games at Runtime with Clojure37:34

Zach Oakes - Making Games at Runtime with Clojure

ClojureTV
31K views • 11 years ago
Simplicity Ain't Easy - Stuart Halloway50:01

Simplicity Ain't Easy - Stuart Halloway

ClojureTV
24K views • 13 years ago
"Simple Made Easy" - Rich Hickey (2011)1:01:39

"Simple Made Easy" - Rich Hickey (2011)

Strange Loop Conference
219K views • 5 years ago
Invited Talk - Guy Steele1:07:22

Invited Talk - Guy Steele

ClojureTV
39K views • 9 years ago
Clojure for Java Programmers Part 1 - Rich Hickey1:48:13

Clojure for Java Programmers Part 1 - Rich Hickey

ClojureTV
131K views • 13 years ago
Inspiring a future Clojure editor with forgotten Lisp UX - Shaun Lebron35:32

Inspiring a future Clojure editor with forgotten Lisp UX - Shaun Lebron

ClojureTV
23K views • 9 years ago
Glenn Vanderburg - Cló: The Algorithms of TeX in Clojure42:25

Glenn Vanderburg - Cló: The Algorithms of TeX in Clojure

ClojureTV
9K views • 11 years ago
Brian Goetz - Stewardship: the Sobering Parts1:03:31

Brian Goetz - Stewardship: the Sobering Parts

ClojureTV
39K views • 11 years ago
Hammock Driven Development - Rich Hickey39:49

Hammock Driven Development - Rich Hickey

ClojureTV
333K views • 13 years ago
Anthony Marcar - Clojure At Scale @WalmartLabs39:41

Anthony Marcar - Clojure At Scale @WalmartLabs

ClojureTV
24K views • 11 years ago
Bruce Hauman - Developing ClojureScript With Figwheel45:31

Bruce Hauman - Developing ClojureScript With Figwheel

ClojureTV
56K views • 11 years ago
Barliman: trying the halting problem backwards, blindfolded - William Byrd, Greg Rosenblatt36:14

Barliman: trying the halting problem backwards, blindfolded - William Byrd, Greg Rosenblatt

ClojureTV
8K views • 9 years ago
ClojureScript for Skeptics - Derek Slager41:09

ClojureScript for Skeptics - Derek Slager

ClojureTV
72K views • 10 years ago
REBL - Stuart Halloway33:06

REBL - Stuart Halloway

ClojureTV
25K views • 7 years ago