Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Python Paradox (2004)

paulgraham.com

Post reply on HN
Print view View original

221–230 of 275 posts

Re: The Python Paradox (2004)

#221

Post by tome »

ulizzle wrote: post #203
tome wrote: post #156

Earlier quoted context omitted.

That's a response to a slightly different question. Your answer makes it clear that exposing students to a language isn't enough to make them take up a language. The original point was that Haskell isn't per se inaccessible.

It's inaccessible because it's difficult and arcane compared to languages like Python, especially at the beginner levels when you are still trying to figure out how a for-loop works, and what are variables, and so on.

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

Re: The Python Paradox (2004)

#222

Post by tome »

foldr wrote: post #182
howling wrote: post #171

Earlier quoted context omitted.

I have a similar experience at Oxford. However, the introduction course doesn't even cover IO monad and all of our code are run in repl. No wonder the students regard Haskell as impractical as they did not even write a full program in it.

Still, if they'd found that Haskell was much easier or more productive to use than other programming languages for simple computational tasks, you'd think a few of them might have googled 'how do do IO in Haskell' and gone from there.

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

Re: The Python Paradox (2004)

#223

Post by Nullabillity »

intelVISA wrote: post #187
pjmlp wrote: post #135

Earlier quoted context omitted.

That was the past, helped by Kubernetes and Docker respective decisions to migrate from Java and Python into Go. Plenty of them are still Java and .NET based, as the ecosystems counter reacted to Go's adoption hype, and Rust is the new kid on the block specially for cloud native Webassembly projects and eBPF. Like Helm creators nowadays doing mostly Rust, https://deislabs.io/posts/

cloud native web assembly... ...x86_64? ;)

WASM is architecture-independent (ARM servers are becoming a thing, for better or worse) and has a lot of investment into sandboxing it performantly (since it also has to run in browsers).

Re: The Python Paradox (2004)

#224

Post by marcosdumay »

noobermin wrote: post #29
PhoenixReborn wrote: post #4

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…

Impersonal ad-hominen is a great new way to construct an argument.

Or, maybe not that new. "These people to that" without even saying what people you are talking about has been used on politics since forever.

Re: The Python Paradox (2004)

#225

Post by foldr »

tome wrote: post #222
foldr wrote: post #182

Earlier quoted context omitted.

Still, if they'd found that Haskell was much easier or more productive to use than other programming languages for simple computational tasks, you'd think a few of them might have googled 'how do do IO in Haskell' and gone from there.

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.

Re: The Python Paradox (2004)

#226

Post by rjh29 »

ReflectedImage wrote: post #213
rjh29 wrote: post #176

Earlier quoted context omitted.

Languages like Python and TypeScript support 'any' as a type, so you can always opt out of strong typing if you want. Most of the time generics are preferable to things randomly dying at runtime though.

Things don't die very often due to typing issues. The unit tests always pick up typing problems. Testing the code's behavior implies testing the code's typing. And if you are not testing the code's behavior then the code isn't really tested at all.

Does your code check every single variable is not null before using it? That every function argument is of the expected type? That every attribute exists before it is accessed? And do you have unit tests for all of this too?

If so - then you're writing a whole lot of manual checking that a strongly typed language would perform for you, at compile time. If not - well then you're doing less testing than a strongly typed language would.

I agree that these issues are rare, and there is evidence that strongly typed languages have a similar number of bugs to dynamic ones. But suggesting that because you have unit tests, you don't need strong types, is a bit naive to me.

Re: The Python Paradox (2004)

#227

Post by ulizzle »

tome wrote: post #221
ulizzle wrote: post #203

Earlier quoted context omitted.

It's inaccessible because it's difficult and arcane compared to languages like Python, especially at the beginner levels when you are still trying to figure out how a for-loop works, and what are variables, and so on.

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.

Re: The Python Paradox (2004)

#228

Post by klyrs »

keithalewis wrote: post #218
klyrs wrote: post #82

Earlier quoted context omitted.

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 t…

Party pooper. Don't you know we are just here to bitch and moan?

Look, I'll admit, it looks terrible from the view that gdb gives... but when you see the whole file, it's just not so bad.

Re: The Python Paradox (2004)

#229

Post by inglor_cz »

solveit wrote: post #74
deafpolygon wrote: post #36

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).

This here. Regardless of talent, you will produce quite a lot of junk.

I am a programmer and a published book author (8 books so far and over 35000 sold copies). I wrote a pile of shit, too, but it helped me become a better coder and a better author.

Re: The Python Paradox (2004)

#230

Post by necovek »

threeseed wrote: post #56
eddsh1994 wrote: post #51

Earlier quoted context omitted.

Or just write in Python like Quora, Pinterest, YouTube, Dropbox, etc

YouTube is almost entirely C++ and Dropbox rewrote their sync engine years ago in Rust because of how ridiculously slow their Python implementation was. No one is saying you can't make a web site using Python. Just that it is inherently a slower language that is far poorer at concurrency than many other languages.

Python is not slow for concurrency: Python has built-in cooperative concurrency that's pretty efficient, and if you care about minimum task time vs running more tasks in parallel, you need to look at multiprocess execution. In the latter case, you are generally inefficient with memory use, but if that's not an issue, you'll be effectively using your CPUs.

However, Python is slow compared to most compiled languages for simple large loops over any data structure.

A good example is how ORM libraries will fetch a million rows from the database as a list of tuples in roughly the time the db emits them at (say, a second with C-based code), yet it will take them 100x or 1000x as long to turn those rows of tuples into Python objects with pure Python code.

Post reply on HN