One of my pet peeves is the cliche "use the best tool for the job". It's often thrown out as a resolution to endless debates like "what programming language is best?" And indeed it does stop the debate. It is interpreted as a high-minded and pragmatic perspective that transcends the petty grumblings of language fans.
But instead of seeing it as an enlightened perspective, I hate it. It doesn't bring resolution to a debate. It kills discourse while providing very little new insight. "Use the best tool for the job" merely displaces the issue from "the best language" to "the best language for some job x".
There's a little insight there: identify the job before trying to find the best language for it. But this rarely happens. What usually happens is the discussion ends, the participants scurry off with the same guilty feelings associated with counting angels on pinheads.
Is there some hypothetical best language? I don't think so. But the discussions are fruitful. While we may not come to a conclusion, we do wrestle with important issues. What qualities make languages better or worse? What role do practical concerns, like ease of learning and availability of libraries, play in the choice? And what do we do with Turing completeness, the everpresent trump in these kinds of debates?
I am thankful for having engaged in these kinds of discussions. And I still enthusiastically dive in with a spirit of inquiry. My studies of programming languages and the history of computing have only deepened my appreciation for the wonder of the relationships between syntax and semantics and data structure and computation. Through these discussions, we can exchange our wonders. And when someone mentions "best tool for the job", I can't help but feel sorry for them.
The speaker has disengaged from history and creative inquiry. Weren't the programming languages we have now created by people who found no suitable tool for a job? Or perhaps the job only came about because the tool was created! And obviously there will be different tools, and different jobs, in the future. Who will create them? Certainly not someone more concerned with matching up tools to jobs than discovering deeper principles at work.
Please keep inquiring and, yes, enjoy the issue.
Can learning a programming language be optimized so that you learn the most important stuff first? I've analyzed over 4 million lines of Clojure from GitHub to find the most commonly used Clojure expressions. Then I created flashcards to help you remember them.
Mike Fikes put together the top 7 ClojureScript frustrations from the 2014 State of Clojure survey. He compiled together, under each frustration, the changes made since then in the ClojureScript compiler. It's great evidence of the progress of the language, the community's willingness to listen, and the importance of voicing your experiences in the State of Clojure Survey.
A cool, interactive tutorial of Quil. There are little sketches throughout the text. You can change the code in an editor and watch it change the image or animation. Very cool!
Daniel Szmulewicz talks about the history of interactive programming (going way back to the first Lisp machines) and how it works in Clojure.
Parinfer looks like a great alternative to the also awesome Paredit which makes some different choices about how to maintain balanced parens.
Eric Smith talks about how he got into functional programming and some of its challenges.
Reusable React components.
An epic day for this Clojure IDE. You can now pay for Cursive or use it freely for non-commercial work.
A newsletter about calls for proposals, speaking tips, and videos.
The book is not finished, but you can get half-off and receive updates when they come out. And when the book is done, they ship it to you! Click "get this deal" and enter in the coupon code.