Live data from Hacker News

The Python Paradox (2004)

paulgraham.com

251–260 of 275 posts

Re: The Python Paradox (2004)

#251
post #125

PHP dominated the internet and then eventually became shunned with people embarrassed to admit they use it. I sometimes wonder if Python is on this trajectory but much slower or not. We are already at the point where there are very clearly better alternatives from nearly every technical perspective, so it's carried primarily by momentum and ecosystem. Can that last forever?

> We are already at the point where there are very clearly better alternatives

Can you name them? I’m not personally aware of any. Python is here to stay for a long long time. It’s become the de facto language for AI/ML and there’re good reasons for that. And programming the AI way or with a significant component involving AI is very likely the future of programming. Until a much better general purpose tool comes around (ie a language that doesn’t get in the way and comes with batteries included - especially for non cs types who have to accomplish programming like tasks) I don’t see it going away anytime in the near horizon

Re: The Python Paradox (2004)

#252

Earlier quoted context omitted.

That's a good point I hadn't considered. where did you find these measurements?

https://games.greggman.com/game/dynamic-typing-static-typing...

Maybe it's my daftness but where does this post say that typed Python has twice the number of bugs?

It only seems to say that typed code takes longer to write and is longer. It doesn't seem to say that typed code has more bugs, nor does it compare typed Python with untyped Python.

Re: The Python Paradox (2004)

#253
post #155

Earlier quoted context omitted.

To me it seems like the ugliest parts of every language is the parts dealing with anything but the most simple types. When langs start introducing things like generics, then things really get gruesome. Thats why I always personally enjoyed duck typing.

> Thats why I always personally enjoyed duck typing. Static or dynamic? You will ask a non-duck to quack. Do you want to find out before or after you start your application?

If you care if it can quack, you see if it can quack.

Re: The Python Paradox (2004)

#254
post #153

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…

> Rust makes enormous binaries But it DOES make binaries. Such a breath of fresh air after years of Java/Scala.

I never really understood this, especially in the age of small docker containers? You just yeet your jar into the container and deploy. Ok, so rust and go don't need a jvm. Why does it matter? Disk space is dirt cheap. It's not like statically linked binaries are small by any measure anyway.

Re: The Python Paradox (2004)

#255

Earlier quoted context omitted.

>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 important to your world view that they might as well be nazis[0], you can tell your priorities are not in order. I hate that everything is politically-coded nowadays, but…

So, this is the problem, you can easily say something is sufficient but it might not be neccessary, or vice versa, implying the converse is often not true. It's does seem silly, but you're right a lot of conservative hackers are anti-systemd, but the converse really isn't true, I don't even think it's like "here are some exceptions" rather than most of the anti-systemd crowd are not reactionaries. Also, "conservatism…

Yeah, I wrote "inverse" but I meant "converse". It's definitely one of those situations, here.

>Also, "conservatism" meaning "if it ain't broke, don't fix it" is NOT equivalent to political conservatism at all. Conservatives all the time advocate for changes that contradict tradition all the time.

True. Frankly, I don't know the exact reason why anti-systemd sentiment seems tied up with conservative/reactionary political tendencies (or, more correctly, why the latter seems tied up with the former).

Re: The Python Paradox (2004)

#256
post #225
post #222

Earlier quoted context omitted.

That seems to be getting things backwards. How could they find it easier or more productive if they haven't even done IO yet?

I would say the productivity gains of Haskell are actually most transparently obvious in the case of the sort of toy algorithmic code you're likely to be writing in a compsci class.

OK. And I would say the productivity gains of Haskell are most transparently obvious in the case of the sort of highly complex, stateful, I/O-interacting code you're likely to be writing for a successful tech company.

Re: The Python Paradox (2004)

#257
post #221

Earlier quoted context omitted.

OK, but now we're back full circle, and you're disagreeing with both epgui https://news.ycombinator.com/item?id=34542953 and krisoft https://news.ycombinator.com/item?id=34544130

Yeah, of course, I am. I don't see what that has to do with anything. So my point is only valid if I support someone else? A lot of us here have read "Learn You A Haskell for a Great Good". We've used it. It's not a socio-historical incident, and it's not just beginners who struggle with the language either.

> Yeah, of course, I am. I don't see what that has to do with anything. So my point is only valid if I support someone else?

Your point is perfectly valid. I'm just saying the thread has just become a sequence of assertions and not particularly enlightening.

Re: The Python Paradox (2004)

#258
post #60
post #53

Earlier quoted context omitted.

I've had the opposite experience. Our competition used a "boring" Ruby on Rails architecture, so they were burning investment capital on cloud hosting every month, meaning they were forced to rush for milestones and cut corners so that they could grasp the next piece of funding before their runway ran out. Meanwhile our "esoteric" codebase meant we could run everything on a couple of servers we owned and spend our ti…

I'm sure counterexamples exist (and I'd be interested in hearing what kind of software this happened with specifically), but in the 99% case the cloud hosting costs for most startups is going to be tiny compared to, say, salaries.

Properly hosting in the cloud requires some additional salaries.

Re: The Python Paradox (2004)

#259

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/trou…

Due to Rust's character and niche, it seems rather likely to stay. Wouldn't bet against it yet. There is so much potential for it to replace old and fragile things.

Re: The Python Paradox (2004)

#260
post #256
post #225

Earlier quoted context omitted.

I would say the productivity gains of Haskell are actually most transparently obvious in the case of the sort of toy algorithmic code you're likely to be writing in a compsci class.

OK. And I would say the productivity gains of Haskell are most transparently obvious in the case of the sort of highly complex, stateful, I/O-interacting code you're likely to be writing for a successful tech company.

This doesn’t match my personal experience (having worked on a Haskell web app professionally for a couple of years). GHC does have some cool features like STM, but typical stateful code tends not to be radially more concise or easier to write in Haskell than in other high level languages (compared to, say, code for traversing a binary tree, or implementing a parser combinator library). Others may have different experiences.
Post reply on HN