My problem is that I don't consider those institution-centric goals... I consider them to be essentials for developing good software quickly.
I've written many open source Python projects in the thousands of lines, and one of them was 30K lines. Right now, I'm actually going back to some 4 year old Python code I wrote by myself, outside of any institution. I don't see how you could NOT value readability and maintainability in this context.
But yes, I get what he's saying. He's just saying it in a wrong-headed way. As if writing readable code is actually a burden or a cost. It's not if you value your own time properly.
> Right now, I'm actually going back to some 4 year old Python code I wrote by myself, outside of any institution
I think by "institution", he mostly meant "group of people" as compared to a solo programmer.
Personally, I tend to prefer "institutional"-style languages because I have a pretty bad memory. Basically even my solo code is still the work of a group of people—me and all my past selves.
I think there are "solo programmers", but they either:
1. Tend to have a pretty good memory for their own code so they are comfortable living in their own idiosyncratic world.
2. Don't maintain solo programs for a long time.
Even for group code, I think there is still room for languages that are more focused on "build your own mini-language, then write your program in it" as opposed to "there's one prescribed way to do it".
I think a lot of it comes down to ramp up time. When a new developer (or your future forgetful self) starts hacking on your program, how much time do you want them to spend before they are useful?
Languages like Python, Ruby, and Java try to minimize that by making all code in those languages roughly similar so it's easy to hop from one codebase to another.
Languages like CL and Perl place less of a premium on that. In return, the idea is that once you have ramped up, your overall velocity is higher. You basically have to learn a new language—the "language" that the program itself is written in—but once you have you now can express concepts in that program's domain more succinctly.
I don't think there's a right or wrong here, just different trade-offs to be made.
You are equating readability and maintain-ability with quick ramp up time. That is a very institution centric way of looking at software development.
As a great counter example look at Haskell. The ramp up time for a typical Haskell program is fairly high but once you invest the upfront cost and understand the programs major abstractions you can make changes quickly and in a much less error prone fashion.
>My problem is that I don't consider those institution-centric goals... I consider them to be essentials for developing good software quickly.
I would say it depends. Readability and maintainability are very nice virtues, but if you are a driver or graphics developer and it cost you the performance then it stops to be desirable.
>As if writing readable code is actually a burden or a cost
It does have a cost, most of the time in the performance form and some other times in creativity form.
I've written many open source Python projects in the thousands of lines, and one of them was 30K lines. Right now, I'm actually going back to some 4 year old Python code I wrote by myself, outside of any institution. I don't see how you could NOT value readability and maintainability in this context.
But yes, I get what he's saying. He's just saying it in a wrong-headed way. As if writing readable code is actually a burden or a cost. It's not if you value your own time properly.