Live data from Hacker News

The Python Paradox (2004)

paulgraham.com

261–270 of 275 posts

Re: The Python Paradox (2004)

#261
post #153

Earlier quoted context omitted.

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

Because I run binaries.

Like docker, for instance. If I had to write "java -jar docker.jar -cp ..." and fuck around for a week trying to figure out where the env vars, JVM flags, and arguments to the actual program go, I would not use docker. Let alone piping input through grep, less and tail.

Re: The Python Paradox (2004)

#262
post #156

Earlier quoted context omitted.

> 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 already know it, and people don't like to learn to do things differently I beg to differ. I studied compsci BSC at an eastern european university. The professors decided to test that theory and decided to introduce programing to everyone in our program through Haskell.…

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.

If it was accessible, then exposing students to it would be enough to make them take it up, no?

Re: The Python Paradox (2004)

#263
post #244

Earlier quoted context omitted.

I don't actually care about any of that stuff. You are confusing technically wrong with not working. If the code works in production it doesn't matter that the code is technically wrong. Testing via typing is very weak testing. Almost worthless. Type checking doesn't find many bugs in general. Strongly typed languages have 2.5 times the number of bugs as dynamically typed languages per software feature. Why would you…

> If the code works in production it doesn't matter that the code is technically wrong. This is actually very insightful, but I'm afraid you won't be able to convince most people. The only valid metric of code correctness is empirical : how many times code ran successfully in production. Everything else (unit tests, static typing) is theoretical and often close to useless. I remember seeing a talk where someone analy…

Very insightful indeed. "I never lock the door to my house but it's never been robbed"

Re: The Python Paradox (2004)

#264
post #120

Earlier quoted context omitted.

I used to interview people for data science roles. We let people use whatever language they wanted in the interview. I expected to see a split between Python and R, but the reality was that almost everyone used Python, which was a bit of a surprise. It's even more surprising to me given that Pandas is such a poorly designed library. (Apparently the guy who developed it was learning Python while he was writing Pandas.…

even more surprising is matplotlib .... the most infuriating plotting library I've encountered and yet its de facto standard for most of data science now!

That comes from mimicking Matlabs plotting API, as a way to move people from Matlab into scientific python. "It's a feature not a bug", a bit taken to an extreme. But it was successful.

Re: The Python Paradox (2004)

#265
post #263
post #244

Earlier quoted context omitted.

> If the code works in production it doesn't matter that the code is technically wrong. This is actually very insightful, but I'm afraid you won't be able to convince most people. The only valid metric of code correctness is empirical : how many times code ran successfully in production. Everything else (unit tests, static typing) is theoretical and often close to useless. I remember seeing a talk where someone analy…

Very insightful indeed. "I never lock the door to my house but it's never been robbed"

Once you have got 5 years real world experience and find programs in production that work for the wrong reasons, you will understand. (And I'm not just talking about programs with dynamic typing either)

I'm aware of one case where a program traded 10 million dollars, made 5 million profit. There was a serious jaw dropping error in it. Did it matter? (and if so, to whom?)

Re: The Python Paradox (2004)

#266

Earlier quoted context omitted.

Python might have nice features, but it also has terrible features. Like using dicts for everything. It's not enough to allow good practices, you have to prevent (or at least reduce) bad practices.

>Like using dicts for everything Sorry what? This is absolutely not true.

I think they meant that the underlying representation for most stuff is a dict.

Global variables are stored in a dict (`vars()`). Unless you use slots, an object is essentially a dict

Doesn't really disturb me because they're not used like a dict in practice though

Re: The Python Paradox (2004)

#267
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.

If it was accessible, then exposing students to it would be enough to make them take it up, no?

No? It may not be suited to their applications (wrong tooling / libraries ), or their collaborators may not use it, or they might simply not like it

Re: The Python Paradox (2004)

#268

Earlier quoted context omitted.

Perhaps they mean anonymous (discriminated) unions of some kind with that syntax?

ADTs = discriminated unions + tuples. They likely mean un discriminated unions, as in typescript.

But since rust is compiled, in practice that would be like C unions, right? A pain to work with

I mean typescript has those because the underlying runtime is Javascript, which tracks the types of stuff and handles some kind of polymorphism, so you can get away with undiscriminated unions because the runtime is doing the job of discriminating them

Re: The Python Paradox (2004)

#269
post #15

Yaron Minsky of Jane Street said the same thing about OCaml

I feel like that's a bit different: Ocaml is a functional language. Functional languages have a reputation of being difficult. Plus they encourage a mathematical way of thinking about your code

By selecting ocaml developers, you filter developers who

- aren't afraid of trying stuff even if it has a reputation of being hard (or leart it at school) - are biased towards a mathematical way of thinking

Re: The Python Paradox (2004)

#270
post #263
post #244

Earlier quoted context omitted.

> If the code works in production it doesn't matter that the code is technically wrong. This is actually very insightful, but I'm afraid you won't be able to convince most people. The only valid metric of code correctness is empirical : how many times code ran successfully in production. Everything else (unit tests, static typing) is theoretical and often close to useless. I remember seeing a talk where someone analy…

Very insightful indeed. "I never lock the door to my house but it's never been robbed"

The alternative is pretending your house is a treasury and buying a lock which costs more than any other item in your house. While your roommate develops kleptomania.
Post reply on HN