6 ms·
Although I don't think of Python and Java as that similar, I do see what Larry is getting at. Python encourages "There should be one-- and preferably only one -
by cicero 10y ago
Although I don't think of Python and Java as that similar, I do see what Larry is getting at. Python encourages "There should be one-- and preferably only one --obvious way to do it", which is very nice for institutions where multiple programmers have to work with the same code.
The power that comes from "more than one way to do it" in Perl is great for an individual programmer that wants to create his own custom tool box, but it can cause difficulties in an organization with people at different skill levels all working on the same code base.
By the way, you see similar issues with Common Lisp. It is great for individual power programmers, but it seldom catches on for something that has to scale way beyond one programmer. As a contrast, look at Go, which was, as Larry Wall would say, "dumbed down" to meet the institutional needs of Google.
I know a lot of Hacker News types would rather think of themselves as power programmers rather than institutional types, but we shouldn't overly disparage the power of institutions to scale way beyond what a single individual can do, even though there can eventually be problems with bloat and mediocrity.
All this is to say that there is need and room in the world for programmer-centric and institution-centric tools. Larry has been helpful to point out the difference, and so people should think about these things when choosing between Python and Perl, for example. I work at a small school, and although I am a one-man programming shop, I do everything in Python in the hopes that if something happens to me, my successor will have an easier time understanding my code. I had done some work in Racket, Clojure, and Haskell, but then I thought about the future and converted everything to Python.
- chubot 10y agoYeah I see what he's getting at in the sense that Python is more regular and compositional, while Perl is more personal and "poetic" (if I'm to be charitable, I don't really like that quality in my code). But "Python has always considered itself institution-centric" is patently FALSE... as I said, if you were using Python 10+ years ago, when Perl was more popular, you would find that statement very surprising. Paul Graham even wrote about this: http://paulgraham.com/pypar.html http://paulgraham.com/pypar.html
- cicero 10y agoI will agree with you that Python didn't consciously consider itself institution-centric, but it has valued institution-friendly goals such as readability and maintainability.
- chubot 10y agoMy 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.
- munificent 10y ago> 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.
- chubot 10y agoRight, 100% agree, but then we've just defined away "solo programmer". If there are no solo programmers, then it doesn't make sense to design any part of a language for them :)
- munificent 10y agoI 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.