Live data from Hacker News

The Python Paradox (2004)

paulgraham.com

131–140 of 275 posts

Re: The Python Paradox (2004)

#131

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…

You mean the mood to find out what breaks in every minor Python release?

I have been using Python in and out for system administration since version 1.6.

Re: The Python Paradox (2004)

#132
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?

Python is fine as scripting language for scienctific computing. What do you need more ?

Re: The Python Paradox (2004)

#133

Funny how Python is considered esoteric by author when Python is amongst the oldest of languages in widespread use then (2004). - C++ 1985 - Perl 1987 - Visual Basic 1991 - Python 1991 - JavaScript 1995 - Ruby 1995 - Java 1995 - PHP 1995 - C# 2000 Back in 2004, despite how small Python was - it was still in the top 10, just past Delphi. - Java dominated, followed by PHP.

I don't know how popular the language was, but I distinctly remember it was seen as unfit for "enterprise" work. This was a time where the Serious devs would do SOAP, CORBA and other boilerplate-heavy RPC. Python was always branded "bad performance because of PIL", because multi-threading was gonna be the future anyway.

I don't know how popular Python was, but I remember it was a "toy" language, and when Reddit rewrote their whole website in it a few years later (2005? 2007?) it was seen as a bold risky move.

Re: The Python Paradox (2004)

#134
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…

> 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. Every year about 500 new students were thaught Haskell. I don’t know a single one of us who stuck with it. Probably there are a few odd ones, but if it were only a question of familiarity you would expect that more people from there would keep programing in it.

Re: The Python Paradox (2004)

#135
post #110

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…

> Go is easy to learn but then the capability of it plateaus. Given that almost every cloud native project is written in Go I'd say this is entirely not true.

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/

Re: The Python Paradox (2004)

#136

Funny how Python is considered esoteric by author when Python is amongst the oldest of languages in widespread use then (2004). - C++ 1985 - Perl 1987 - Visual Basic 1991 - Python 1991 - JavaScript 1995 - Ruby 1995 - Java 1995 - PHP 1995 - C# 2000 Back in 2004, despite how small Python was - it was still in the top 10, just past Delphi. - Java dominated, followed by PHP.

I don't know how popular the language was, but I distinctly remember it was seen as unfit for "enterprise" work. This was a time where the Serious devs would do SOAP, CORBA and other boilerplate-heavy RPC. Python was always branded "bad performance because of PIL", because multi-threading was gonna be the future anyway. I don't know how popular Python was, but I remember it was a "toy" language, and when Reddit rewro…

In 2000, plenty of enterprises were adopting Python to replace Perl, and doing CMS based on Zope.

During the late 90's there was a DDJ issue dedicated to Python.

The first Python version I used at work was 1.6.

Re: The Python Paradox (2004)

#137

Earlier quoted context omitted.

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

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?

Re: The Python Paradox (2004)

#138
post #44

Typed python is extremely ugly and frustrating. Does anyone have any good advice on doing it well? It seems like every library has their own system and doing any kind of casting just to make the linter be quiet is such a chore.

> It seems like every library has their own system

Well there are like 3 or 4 checkers existing.

Then there's pydantic which needs a mypy plugin because it uses the types in a very non-standard way. But I use typedload (which I wrote) so that's not an issue for me.

Other than pydantic I've just encountered libraries without type definitions, or done properly.

Perhaps the fact that I tend to avoid adding dependencies helps me there.

Re: The Python Paradox (2004)

#139
post #44

Typed python is extremely ugly and frustrating. Does anyone have any good advice on doing it well? It seems like every library has their own system and doing any kind of casting just to make the linter be quiet is such a chore.

Check out https://github.com/google/pytype

Use mypy. More mature.

Re: The Python Paradox (2004)

#140

So what are some present day choices for a language that can serve this people differentiator role? And yet is practical? How about F#?

Rust seems to be a popular choice for filling this role at the moment.
Post reply on HN