I agree with the sentiment of this article, but strongly disagree with the title, and the advice to learn to type fast.
The title is abuse (or misunderstanding) of the word "currency". Currency is an accounting mechanism. Time is, well, something else. It's an incredibly valuable commodity, a necessary (but not sufficient) ingredient for any activity and hence any kind of progress, and one which you cannot make more of and so is worth using wisely. But comparing it to currency is a category error.
Which brings me to my second point: it seems intuitively obvious that if you want to use time wisely you should use it efficiently, and typing faster is more efficient than typing slower. But this overlooks a crucial point: typing faster can only produce a linear improvement in your efficiency. If you type twice as fast, you will be able to type twice as many characters in the same amount of time. But there is another dynamic in play: if you type slowly, then the cost of typing will become more painfully evident to you, and that can motivate you to think about ways to type less, and that can lead to exponential improvements in typing efficiency.
I have been coding for forty-one years. I never learned proper touch-typing, and so my typing has always been quite slow by coder standards. As a result, typing boilerplate is extremely painful for me, and I try to avoid it at all costs. That drove me to learn Lisp, and that has led me to a coding style where I only need a tiny fraction of the code that, say, a Java programmer needs to do the same job. So yes, I type 2x slower, but I only have to type 0.1x the amount of code for a net win of 5x. And the techniques that lead me to that win can be applied recursively. There are domains in which I can get 100x or 1000x improvements (i.e. 1 line of Lisp code is the equivalent of 1000 lines of Java or C). I never would have been motivated to learn those techniques if I were able to type fast.
That's kind of sad. The most productive 2 week class I ever took was a touch typing class in 8th grade. We learned on mechanical typewriters where you really had to hammer the keys. This has paid off for me enormously.
> quite slow by coder standards
I spend very little time typing code in, that's not where my typing time is spent. For example, I am typing this while looking at the screen, not the keyboard. I catch and fix mistaeks much faster. When I'm transcribing text, touch typing doubles the speed because I read the original while typing.
I also try and optimize my code for readability, not minimal keystrokes.
It's very hard to give short examples because for any short example you can find another language that does the same thing with similar effort. For example, this:
is basically PHP embedded in Common Lisp. So any example I give you to show how cool CL-WHO is you could render it in PHP and conclude that PHP is similarly cool.
The Big Win only happens if you want to combine a feature that is best served by language X with some other feature that is best served by language Y. In the non-Lisp world, you now have to start gluing together code from entirely different ecosystems, whereas in Common Lisp everything lives together in the CL ecosystem (including nowadays the ability to call C code). So I can combine CL-WHO seamlessly with other programs written in CL (and C). That turns out to be a huge win in the long run.
It pretty much comes down to Greenspun's tenth rule [1]. Macros and the ability to embed DSLs are a huge win in certain domains. Two which I have personally worked in are autonomous spacecraft control and chip design. You can do things in Lisp that you could not even conceive of doing in C short of, as Greenspun's tenth observes, basically re-inventing Lisp.
No, it's actually very hard to give large examples. You're not going to replace a million lines of C with a 1000 lines of Lisp, unless something crazy is going on, like most of that million lines is completely the wrong code for the requirements at hand. Or it solves a huge problem X, which includes small subproblem Y; and in the Lisp program we only care about Y.
Small examples are easy: for instance, some one-liner in Lisp based on hashing, compared to a five-liner in C, plus 1000 lines of infrastructure: hash implementation, dynamic strings, ...
Big C programs that have the Greenspunned architecture don't need a lot of additional lines to add new functionality.
Hmm, I am not particular convinced by the example.
How is this different from developing on say JVM, using Kotlin and finding a library providing DSL for HTML?
I was hoping for practical things that fundamentally impossible to describe concisely in non-lisp languages.
I wouldn't dare to challenge that lisps tend to produce concise code but being able to write 10x less code as basis and 100-1000x less on any regular basis seems too good to be true.
I didn't say I could get 100-1000x on a regular basis. What I said was:
> There are domains in which I can get 100x or 1000x improvements
Domains like that exist, but they are outliers. Normal improvement is 10x.
> I was hoping for practical things that fundamentally impossible to describe concisely in non-lisp languages.
Most programming languages are Turing-complete so nothing is "fundamentally impossible" to express in any of them. The thing that is fundamentally impossible in most non-Lisp languages is to extend the language with new syntax and control constructs within the language itself.
It is of course trivial to embed a Lisp interpreter within any language, and that will let you do Lisp-y things within that language. But then your performance will suck, which is why no one does that despite the fact that it is theoretically possible. It is not so much about what is possible as it is about the ways in which your language molds your thought processes. For a C programmer, embedding a DSL is an esoteric advanced technique. For a Lisp programmer, it's as easy and therefore as common as writing a function.
> I didn't say I could get 100-1000x on a regular basis. What I said was:
I know, sorry for misrepresenting that. I just assumed that this happens often enough for you to mention it.
I would be happy with any random 1000x improvement or two you've encountered over the years (imagine something like Java/Kotlin baseline for comparison).
I don't really buy the regular 10x improvement either though (as in something achieved by other means than different form of formatting). Happy to be proven wrong though, my lisp experience is limited to some clojure.
> Most programming languages are Turing-complete so nothing is "fundamentally impossible" to express in any of them
Sure, that's why I said "fundamentally impossible to describe concisely", as in something you can only express concisely in lisp (because of prefix notation? macros? I don't know) and it is bound to be 10x verbose mess in a c-like lang.
"Two which I have personally worked in are autonomous spacecraft control and chip design."
> I don't really buy the regular 10x improvement either though (as in something achieved by other means than different form of formatting).
Why exclude a "different form of formatting"? That phrase is sufficiently vague that it could potentially refer to just about anything.
> something you can only express concisely in lisp (because of prefix notation? macros? I don't know) and it is bound to be 10x verbose mess in a c-like lang.
You are still fundamentally misunderstanding the claim. It is not that there is anything that can be done in Lisp that could not in principle be done in a c-like language with a comparable number of keystrokes. The history of c-like languages is one of continual refinement and adding features that do precisely this.
The difference is that in Lisp if you need a feature that isn't already there you don't need to wait 30 years for standards committees and compiler writers to catch up. All you need to do is take ten minutes to write a macro.
The typing advice seems out of place in the post, but I would encourage everyone to learn touch typing purely for the enjoyment of it. I find it really satisfying. I also think there are ergonomic benefits that outweigh any increased efficiency. Like the author concludes, though, nothing is "absolutely wrong" and to each their own :)
There is nothing wrong with pursing touch typing (or any other skill for that matter) for its own sake, and all else being equal typing fast is better than typing slow. My point is just that all else is not equal. The benefit of typing fast in terms of time savings is linear at best but there are ancillary effects to typing slow that can accrue non-linear benefits.
The title is abuse (or misunderstanding) of the word "currency". Currency is an accounting mechanism. Time is, well, something else. It's an incredibly valuable commodity, a necessary (but not sufficient) ingredient for any activity and hence any kind of progress, and one which you cannot make more of and so is worth using wisely. But comparing it to currency is a category error.
Which brings me to my second point: it seems intuitively obvious that if you want to use time wisely you should use it efficiently, and typing faster is more efficient than typing slower. But this overlooks a crucial point: typing faster can only produce a linear improvement in your efficiency. If you type twice as fast, you will be able to type twice as many characters in the same amount of time. But there is another dynamic in play: if you type slowly, then the cost of typing will become more painfully evident to you, and that can motivate you to think about ways to type less, and that can lead to exponential improvements in typing efficiency.
I have been coding for forty-one years. I never learned proper touch-typing, and so my typing has always been quite slow by coder standards. As a result, typing boilerplate is extremely painful for me, and I try to avoid it at all costs. That drove me to learn Lisp, and that has led me to a coding style where I only need a tiny fraction of the code that, say, a Java programmer needs to do the same job. So yes, I type 2x slower, but I only have to type 0.1x the amount of code for a net win of 5x. And the techniques that lead me to that win can be applied recursively. There are domains in which I can get 100x or 1000x improvements (i.e. 1 line of Lisp code is the equivalent of 1000 lines of Java or C). I never would have been motivated to learn those techniques if I were able to type fast.