Live data from Hacker News

The Python Paradox (2004)

paulgraham.com

81–90 of 275 posts

Re: The Python Paradox (2004)

#81
post #16

UPDATE: I realize this is a repost from 2004. Still worth exorcizing dead links since content is still relevant What's up with the Turkish and Japanese translation links not working? Are they just dead cos they rotted? I've been working on my own multilingual site upgrade lol so my mind is on this @PG to future proof consider using archive.org's wayback machine for essential links like translations, shld hopefully be…

> What's up with the Turkish and Japanese translation links not working?

No idea about the Japanese translation, but the Turkish one was hosted on a Turkish Slashdot clone (fazlamesai.net) back then [1]. There is still a web site at that domain but I believe it is owned by someone else these days.

Key takeaway: Host translations yourself, do not let others host it for you.

[1] https://web.archive.org/web/20040910012806/https://fazlamesa...

Re: The Python Paradox (2004)

#82

Earlier quoted context omitted.

approaches C++-level eyebleed Have you ever hit F12 on any C++ std function or data structure? Every time I do it genuinely feels like I'm back at day 1 freshman year of an undergrad CS degree.

Post a pic

A random file in the standard library:

https://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a0109...

Honestly I don't think it's that bad if you can look past all the underscores. I looked around for something worse but maybe I'm just accustomed to the eyebleed that C++ has to offer. To me, Rust is uglier, but that's because it's been around a quarter of the time that I've been using C++ and I don't know what all the symbols do without looking up a cheatsheet.

Re: The Python Paradox (2004)

#83

It was right then, but it's kind of dated and misses an evolutionary lesson: beautiful code isn't enough, it has to be safe, beautiful, maintainable, productive, understandable, and resource efficient. Ruby is still great for throwing something together fast and maintaining it until it runs into scale problems. It added gradual typing with sorbet and RBS. Crystal is a neat typed, compiled Ruby-alike but it's buggy. R…

> Tag structs are laborious... Rust should rebase its type system to have union types, i.e., foo: i32 | f32.

Rust has ADTs, so I'm not sure what you're saying here. Can you expand on how you think unions would make code nicer than disjoint unions? They definitely make generics much harder to think about for me.

Re: The Python Paradox (2004)

#84

In my experience, programmers obsessed with unconventional programming languages are exactly the ones that prioritize (over) engineering over simply shipping things. If you think, writing your codebase in a funky functional language would bear fruits in the long turn, you're in for a surprise. The road is full of pitfalls. Here are a few I outlined in my essay[1]: 1. Hiring is harder: "When it comes to hiring people,…

> Why should I waste my energy on learning a new language, especially when it can fade into obscurity and the output is going to be the same anyway?

I used that reasoning to keep writing perl when python suddenly seemed everywhere and over-hyped.

To be honest, I probably should have just taken the time to learn python sooner. I haven't abandoned perl, and I doubt I ever will, but it would have saved me some time/trouble to have picked up python earlier since it wasn't the fad I assumed it was.

Today, I assume Rust is just a fad so I'm tempted to avoid the same mistake and pick that up too. Haven't bothered yet though.

Re: The Python Paradox (2004)

#85
post #43

It was right then, but it's kind of dated and misses an evolutionary lesson: beautiful code isn't enough, it has to be safe, beautiful, maintainable, productive, understandable, and resource efficient. Ruby is still great for throwing something together fast and maintaining it until it runs into scale problems. It added gradual typing with sorbet and RBS. Crystal is a neat typed, compiled Ruby-alike but it's buggy. R…

> Haskell and Idris are beautiful and powerful, but inaccessible to most software engineers. I don't see any fundamental reason why that should be the case. It seems to me that while it's true that most engineers would have a hard time navigating these languages today, it's mostly due to socio-historical accident. It's not because the languages are particularly difficult or arcane, it's mainly because people don't al…

Imo, one "fundamental" reason is that Haskell has a much smaller, nicer core than most languages, so it builds everything out of that core. For example, most languages have variable update statements in their core. Haskell defines at least two data types of "programs that have stateful variables" (ST and State). The result is that people want to see how everything is broken down into pure functions under the hood, and that means it takes more time to learn the language.

Re: The Python Paradox (2004)

#86

It was right then, but it's kind of dated and misses an evolutionary lesson: beautiful code isn't enough, it has to be safe, beautiful, maintainable, productive, understandable, and resource efficient. Ruby is still great for throwing something together fast and maintaining it until it runs into scale problems. It added gradual typing with sorbet and RBS. Crystal is a neat typed, compiled Ruby-alike but it's buggy. R…

At the time I'm writng this, there's a separate thread on Rust's "ugly" syntax. The issue with complex trait constraints, specialization etc. is that they impact forward compatibility: it is possible that a new version of some external dependency will add trait implementations in a way that ends up breaking your existing code. It's understandable that Rust devs would want to avoid this.

Re: The Python Paradox (2004)

#87
post #74

Earlier quoted context omitted.

A broken clock is right twice a day.

No. People aren't clocks. The best way to make something great is to make ten meh things and discard a hundred crap things. I guarantee you everyone whose takes you admire also have many, many bad takes (which they perhaps don't tweet, but there's a definite trade-off here and PG's lower threshold for tweeting seems to work well enough for his goals).

I take it you're not aware/familiar of/with the phrase.

Here's a deeper explanation from a random Google search result.: https://www.businesswritingblog.com/business_writing/2022/05...

Re: The Python Paradox (2004)

#88

Earlier quoted context omitted.

Or Rust, which is very popular on HN.

Rust is "not as used" but it has a following who hype it to the point that I've avoided taking time to relearn it just due to the strange vibes I get from their community. These people once mentioned, on twitter, that people who hate systemd are like reactionaries (as in, politically far right), as if a choice of init is a correlative of political ideology. When you view others' preferences for fucking software as so…

Genuine question: Maybe the pro systemd people meant the word reactionary in it's non-left/right definition? From Wikipedia: "In political science, a reactionary or a reactionist is a person who holds political views that favor a return to the status quo ante, the previous political state of society" [0]

I've heard people use 'reactionary' to mean "doesn't want things to change", or "wants things to go back to the way they were", which would actually be a pretty reasonable opinion for a pro-systemd person to have about people opposed to systemd.

(I'm not saying that systemd is or isn't good/bad, but it was definitely a change, so describing people who wanted to keep initd as reactionary does seem to jibe with the definition of reactionary folks as being people who favor going back to the earlier status quo)

[0] https://en.wikipedia.org/wiki/Reactionary

Re: The Python Paradox (2004)

#89
post #66

In my experience, programmers obsessed with unconventional programming languages are exactly the ones that prioritize (over) engineering over simply shipping things. If you think, writing your codebase in a funky functional language would bear fruits in the long turn, you're in for a surprise. The road is full of pitfalls. Here are a few I outlined in my essay[1]: 1. Hiring is harder: "When it comes to hiring people,…

[deleted]

[deleted]

Re: The Python Paradox (2004)

#90

Python is great for small scripts or explorations. You can't use it for anything serious that needs to scale due to the lack of concurrency and significant memory overhead. If you need something to scale you use something like C++, Java, Go, Rust, etc.

> Python is great for small scripts or explorations. I've used Python on program with >30000 LOC without any problems.

Do you really have no problems? I find the lack of proper type support and proper variable scoping to be a huge issue.
Post reply on HN