Live data from Hacker News

The Python Paradox (2004)

paulgraham.com

51–60 of 275 posts

Re: The Python Paradox (2004)

#51
post #14

Python is a glue language. If you want to be hardcore you write something in rust (or whatever) with python bindings...

Or you can just pick a language like Java, Scala, Go etc and not need to manage two codebases, build tools, testing setups etc

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

Re: The Python Paradox (2004)

#52
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 project for typed python to emit C [1], written entirely in python. Nowadays with python's rich specializer ecosystem (LLVM, CUDA, and just generally vectorized math), the value of writing a small program in anything else diminishes quickly.

Imagine reading the C++wg release notes in the same mood that you would the python release notes.

[1] https://github.com/mypyc/mypyc

Re: The Python Paradox (2004)

#53

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

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 time building stuff there was an actual business need for. So we were the ones who got a big acquisition while they crashed and burned. I mean, if you're looking at Facebook then you should look at WhatsApp too.

Re: The Python Paradox (2004)

#54

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

> Facebook was written in PHP. Mark used one language he knew and a $300B company was built on top of it.

This example doesn't further your point at all seeing as they had to over time literally invent an entirely new language to make their PHP codebase scale. And on top of that FB went on to use a whole bunch of uncommon languages (Haskell, Erlang, D, probably a bunch of others I don't know about)

Re: The Python Paradox (2004)

#55

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

> Facebook was written in PHP. Mark used one language he knew and a $300B company was built on top of it. This example doesn't further your point at all seeing as they had to over time literally invent an entirely new language to make their PHP codebase scale. And on top of that FB went on to use a whole bunch of uncommon languages (Haskell, Erlang, D, probably a bunch of others I don't know about)

Well, as the counterfactual, you can't invent a buyer who will value your Clojure shop at the last funding round.

Re: The Python Paradox (2004)

#56

Earlier quoted context omitted.

Or you can just pick a language like Java, Scala, Go etc and not need to manage two codebases, build tools, testing setups etc

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.

Re: The Python Paradox (2004)

#57

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

Also I've found that teams that focus on easily understandable languages (Python I think is the best with its "executable pseudocode" syntax) are those that are placing value on teamwork rather than individual flexing.

Re: The Python Paradox (2004)

#58
post #13

2004. Almost 20 years ago. Was Python even a teen? Python does not attract smart young iconoclasts anymore. It's the scripting language everyone writes because everyone writes Python. What languages do attract smart young iconoclasts? Nim? Elm? Whatever you're doing that is not yet old enough to drink by the time you comment?

My vote is on Nim. Python like syntax with C++ speed. Unknown enough, but still not too new or obscure.

The community gives me pause. Nim's BDFL seems to have a habit of driving away prominent users of the language. Programmers who had contributed to the compiler have made their own hostile fork, and two of the three people who have written book-length introductions to the language have either given up on Nim or been tempted to do so. (The third is the BDFL himself.)

If anyone cares, here's some comments from one of those authors: https://github.com/StefanSalewski/NimProgrammingBook/issues/... . And from the other: https://twitter.com/d0m96/status/1592827547582332929?t=IqKBz... .

These quarrels with Araq differ obviously, but both are pretty discouraging as far as Nim's prospects are concerned.

Re: The Python Paradox (2004)

#59
post #53

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

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 remember Ruby on Rails being a hipster technology for teens who code on MacBooks at Starbucks. Now it’s “boring”. How times have changed!

Re: The Python Paradox (2004)

#60
post #53

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

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.
Post reply on HN