Live data from Hacker News

The Python Paradox (2004)

paulgraham.com

141–150 of 275 posts

Re: The Python Paradox (2004)

#141
post #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.

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

Re: The Python Paradox (2004)

#143
post #118

Funny how emergence works with tools. Give a language too few tools but viral circumstances - the ecosystem diverges (Lisps, Javascript). Give it too long an iteration time but killer guarantees, you end up with committees. Python not falling into either of these traps should be understood as nothing short of magic in emergence. I only recently discovered that python's reference typechecker, mypy, has a small side pr…

> Imagine reading the C++wg release notes in the same mood that you would the python release notes. Which mood are we talking about here? Mild dread? They keep adding new features to the language. The Python programming language is around 30. The release notes at this point should be "wow, we found a bug this year! Didn't expect to see one of those!". The secret of Python is it is actually a large community all learn…

Industries change, needs change, new possibilities emerge. A language that doesn't change is probably either dead, dying, or headed for a tiny niche. Python changes a lot because lots of people use it and have needs and desires for it. Clojure is used very little, so doesn't have the same kind of demand for improvement or community to do it (I don't for a moment believe it couldn't be improved).

Re: The Python Paradox (2004)

#144
post #68

Earlier quoted context omitted.

I haven't followed development of the Python language in a while but this article was featured last week [1] and it does feel like committees. I have followed development of C++ and... yeah, committees and subcommittees. [1] https://chriswarrick.com/blog/2023/01/15/how-to-improve-pyth...

Well, in reality it’s more complicated there always were approaches through committee and approaches outside (conda being an initiative, and lately there is an explosion of tools making use of the pyproject.toml interface). with packaging there are things the committee is good at (making sure that a change to packaging does not break packaging for certain configurations and use cases) and individual initiatives outsi…

Frankly, yes, the PEP process looks great!

Re: The Python Paradox (2004)

#145

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…

> These people once mentioned, on twitter, that people who hate systemd are like reactionaries

I don't think you are actually referring to the entire Rust community here. Did one person say this on Twitter, and maybe a handful retweet? Besides, what does Rust have to do with systemd?

(Not a Rust user, and don't really have an opinion on systemd.)

Re: The Python Paradox (2004)

#146

Earlier quoted context omitted.

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

Python has types now (though it didn't when I wrote the 36kLOC program I had in mind). What problems are there with python variable scoping -- you can have global and local variables, shouldn't that be enough?

> though it didn't when I wrote the 36kLOC program I had in mind).

Yeah, that was my assumption. Still, typing in Python feels very clunky compared to TypeScript. And even though it is much better after 3.8 and 3.9 updates, the adoption of typing in various useful libraries was relatively low as far as I remember.

> What problems are there with python variable scoping -- you can have global and local variables, shouldn't that be enough?

Maybe it is just me, but the scoping rules feel weird: blocks like "with"-statement or for-loops don't create scopes. There is no distinction between declaration and assignment. Sometimes you have to use those weird "nonlocal" and "global".

Re: The Python Paradox (2004)

#147

Earlier quoted context omitted.

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

Lack of typing support is a major advantage. If you don't have types you don't need interfaces, generics, etc. The resulting code is shorter and less bug prone.

You still need all of that. You just have to store that information in documentation and do analysis in your head instead of relying on a static analyzer.

Re: The Python Paradox (2004)

#148
post #112

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…

Rust is to C what systemd is to /etc/rc. Both C and /etc/rc are defining characteristics of old-school Unix culture, so it kind of makes sense even just on account of that that folks who hate systemd also hate Rust. What puzzles me is that OpenBSD people seem to be quite actively opposed to Rust too. They are the project that disables hyperthreading for security reasons, runs ld to relink the kernel after every boot…

If you want to understand how it might be motivated by security, just read the LKML threads around Rust - the Rust developers’ claims are at times pretty wild, and in my experience (after 20 years in infosec), they tend to have a relatively narrow view of “safe”.

I am expecting new vulnerabilities to pop up from developer’s misunderstanding of what Rust actually guarantees, especially in the same memory space as the kernel.

On top of that, Rust implies a huge new bundle of complexity, a second compiler to have bugs in, and a new software supply chain to attack. The language is extremely complex compared to C. These are not easily dismissible problems.

While Rust is definitely a step up from C++ in embedded, I am not convinced bolting it onto existing kernels will fix more potential CVEs than it will cause.

Re: The Python Paradox (2004)

#149

Earlier quoted context omitted.

You missed TypeScript, which has advanced generics with union support and the JS ecosystem is getting better each day and it’s ubiquitous.

TypeScript is fantastic —- such a flexible type system. It was introduced 18 years after JavaScript but feels like a perfectly natural evolution of JavaScript. TypeScript _should_ feel like a wonky bolt on but it’s wonderful. A testament to the folks who built it

To be honest early TypeScript was quite bad with class dependence (functional style was an afterthought) and "namespaces" (That was still used in the mainline TS compiler until recently iirc, behaved like nested objects in JS, kind-of useful but totally missed the NodeJS file-based-module-separation) felt a lot like they wanted _Java_ or C#.

Sometimes during the late 2.x series TypeScript really came into stride with ability to express more "dynamic" types, using a functional style and having arrays-behaving-like-tuples,etc and the 3.x and 4.x series has really made it polished.

TL;DR; It's quite great now, but don't dismiss sceptical people because early versions of it kinda DID suck.

Re: The Python Paradox (2004)

#150
post #118

Funny how emergence works with tools. Give a language too few tools but viral circumstances - the ecosystem diverges (Lisps, Javascript). Give it too long an iteration time but killer guarantees, you end up with committees. Python not falling into either of these traps should be understood as nothing short of magic in emergence. I only recently discovered that python's reference typechecker, mypy, has a small side pr…

> Imagine reading the C++wg release notes in the same mood that you would the python release notes. Which mood are we talking about here? Mild dread? They keep adding new features to the language. The Python programming language is around 30. The release notes at this point should be "wow, we found a bug this year! Didn't expect to see one of those!". The secret of Python is it is actually a large community all learn…

Don’t lisps (or lisp-likes) push language feature creation into user space? And also with Clojure piggying on the JVM, I would be shocked if it needed continuous updates.
Post reply on HN