131–140 of 141 posts
Earlier quoted context omitted.
And then, python.
I love Python, but basically 96% of Python code and developers absolutely suck at everything, I'm fixing a shit python codebase right now. It's like a language which people love to use to write shit code.
Then you write it again in a better language...
Serving static blog content should be trivial if your code isn't absolute lunacy.
Laziness, Impatience, and Hubris were especially clear/obvious in Perl at the time. Perl was a gazillion times more powerful than Bourne and C-shell (including all the Unix shell tools like `awk`), much more rapid than working in C, incredibly terse (perhaps too much so), and also portable (to all the oddball systems you might have). And the purposes to which Perl was put were often to automate things you'd been doin…
And then, python.
It's for non-programmers.
Earlier quoted context omitted.
I love Python, but basically 96% of Python code and developers absolutely suck at everything, I'm fixing a shit python codebase right now. It's like a language which people love to use to write shit code.
Python is great for prototyping... Then you write it again in a better language...
Python isn't appreciably faster than something like Typescript to someone with actual experience making programs professionally.
Related: The Three Virtues of a Great Programmer - https://news.ycombinator.com/item?id=32487944 - Aug 2022 (2 comments) Larry Wall's Three Great Virtues of a Programmer - https://news.ycombinator.com/item?id=24107571 - Aug 2020 (1 comment) Develop the three great virtues of a programmer: laziness, impatience, and hubris - https://news.ycombinator.com/item?id=11516215 - April 2016 (72 comments) The Three Virtues of a…
Laziness, Impatience, and Hubris were especially clear/obvious in Perl at the time. Perl was a gazillion times more powerful than Bourne and C-shell (including all the Unix shell tools like `awk`), much more rapid than working in C, incredibly terse (perhaps too much so), and also portable (to all the oddball systems you might have). And the purposes to which Perl was put were often to automate things you'd been doin…
> Perl […] incredibly terse (perhaps too much so) I used to like Perl, but I found it hard work at times not to create something that, without ample commenting which arguably removes a lot of the benefit of terseness, even I wouldn't understand without some thought when looking at it a few months down the line. Perl was (is? - I assume it is still used a fair bit) often referred to as a write-only programming languag…
Earlier quoted context omitted.
And then, python.
I love Python, but basically 96% of Python code and developers absolutely suck at everything, I'm fixing a shit python codebase right now. It's like a language which people love to use to write shit code.
Earlier quoted context omitted.
When you learn programming, you are told to never roll your own crypto, or to always use the ready-made libraries, or to avoid manual memory management - and you can have a perfectly fruitful career following rules like that. But you don't get big changes or ambitious intellectual growth without spotting that - if you did choose to break those sorts of rules - you could build something really new and exciting. Anyhow…
> When you learn programming, you are told to never roll your own crypto, or to always use the ready-made libraries, or to avoid manual memory management I've always taken this sort of advice, such as "never reinvent the wheel" to mean "inventing the wheel is time consuming so give yourself an advantage by using already existing wheels", which really has nothing to do with hubris. I never took it as "Don't bother try…
There's only one person I ever met who thought manual memory management was a good idea, and their code was terrible in lots of other ways besides that, so I can't say I've ever thought about that particular example.
But after a decade or so of "don't roll your own crypro", I've also heard that if you specifically want to get into cryptography, the only way to do it is to research existing crypro libraries and work your way upwards, starting from "can I find bugs someone else already found, without reading the full details of their report?" and eventually rolling your own.
[0] That said, I'd now also add that libraries serve as Schelling points to make it easier to find jobs and to find workers.
Earlier quoted context omitted.
I'd even go so far as to say !hubris Pride often leads to unintentional blindness and irrational defensiveness. Humility is where the fun is.
If you’re too humble you might listen to all the people telling you it can’t be done, and later that it shouldn’t be done, and then finally that you did it wrong.
I've never really liked his inclusion of hubris here. Hubris is often defined as unjustified arrogance. Justified confidence, even if you're a jerk about it, was never the fatal flaw of a Greek hero. So I've always substituted arrogance for hubris: the belief that you better understand, and can better address, the requirements than any off-the-shelf library/program/ecosystem.
He gives his meaning for hubris. Seems silly to disagree based on a different definition that he's not using.
Part of the impact of jokes of this form is that you are supposed to be able to sort of reason your way there without explanation. But while laziness and impatience rely on the common usage of the terms, hubris is off in left field, and not even in a way that's commonly understood amongst software developers. Hubris is not "pride, but more so", it is specifically "unjustified pride". A lot of people first encounter the word "hubris" in high school literature/English class, talking about the common tropes of ancient Greek tragedies, where it is necessarily unjustified pride. I guess there's a way to understand "hubris" as "excessive (abrasively so) justified pride", but that seems vanishingly rare. I'd argue that that distinction makes "hubris" here misleading. When I (and, I expect, most people who learned the word in high school), read that a good programmer should have hubris, I understand that to mean a good programmer should be confidently wrong.