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

181–190 of 275 posts

Re: The Python Paradox (2004)

#181

Post by goodoldneon »

whizzter wrote: post #149
goodoldneon wrote: post #109

Earlier quoted context omitted.

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…

“Felt like they wanted C#” makes sense because Anders Hejlsberg was involved with TypeScript. Glad they stopped forcing C# into it and let it be its own thing. Not that C# is bad though!

Re: The Python Paradox (2004)

#182

Post by foldr »

howling wrote: post #171
krisoft wrote: post #134

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

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.

Re: The Python Paradox (2004)

#183

Post by consilient »

komadori wrote: post #141
creata wrote: post #83

Earlier quoted context omitted.

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

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

Re: The Python Paradox (2004)

#184

Post by ivanbakel »

tasuki wrote: post #180
epgui wrote: post #43

Earlier quoted context omitted.

> 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 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: their experience stands in the way. I'm somewhat of a fan of Haskell (though its standard library is awful) and very much a fan of Idris (at the very least it's a better-Haskell, at best, dependent types!), but hard disagree. These languages…

>Get started with Haskell or Idris, you quickly hit higher kinded types, monad transformers, free monads, final tagless. It's a different universe.

How is any new developer hitting any of these "quickly"? I'm working on a mature production codebase with plenty of advanced Haskell, and we barely have any tagless final code - much less free monads. Even HKDs and monad transformers are relatively recent additions to our toolbox that we reach for when appropriate - most of the code uses plain old datatypes and one or two concrete monad types.

My experience of learning Haskell is that many production codebases use advanced features because they are big boons to productivity, but few learning resources make reference to them. In fact, Haskell's biggest problem is probably the gap in knowledge between simple, low-productivity code written by newer developers, and the kind of code that actually goes into production with all the optional advanced features. A budding developer can easily write a whole application that never goes beyond `IO` without issue.

Re: The Python Paradox (2004)

#185

Post by omershapira »

quickthrower2 wrote: post #150
roenxi wrote: post #118

Earlier quoted context omitted.

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

Python does too, to a limited extent. A good example is type annotations. You don't _have_ to use type annotations, but you can enforce it in your project by writing a typechecker or a preprocessor; and there's a subset of python that can be compiled statically.

And the Clojure example imho is a bit of a red herring, because while it allows a lot of flexibility (reader macros in Clojure are very powerful), they don't encourage ecosystem divergence, since Clojure can use JVM/Java for "Batteries" and most standard libraries. Cljs is more similar in that way, because it carries much of javascript's divergence with it.

Re: The Python Paradox (2004)

#186

Post by AdamN »

nextos wrote: post #108
cvccvroomvroom wrote: post #24

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…

> 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. I think Ruby is much better than Python for building large applications. Ruby is essentially Smalltalk with a neat Algol-like syntax and some Perl-isms. Its OO system is a joy to work with. Python got so popular in data-oriented applications because it's a reall…

That's sort of outdated. Python now has type hints, protocol oriented programming support, and is quite fast (for what it is). This wasn't the case back in the day but it's all there now.

Re: The Python Paradox (2004)

#187

Post by intelVISA »

pjmlp wrote: post #135
aerfio wrote: post #110

Earlier quoted context omitted.

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

cloud native web assembly...

...x86_64? ;)

Re: The Python Paradox (2004)

#188

Post by AdamN »

dragonwriter wrote: post #122
zo1 wrote: post #100

Earlier quoted context omitted.

If you're doing casting its probably a code smell and good indicator of something being off, or you're doing something too exotic. I'd say this applies a good amount to normal compiled languages too. To do types well, I'd recommend constraining as much as possible. E.g. if a library gives you a union of 5 possible return types, just type it as one of them that you know you'll get and don't let that "complexity" propa…

> Or any other type checker for that matter other than Pycharms built-in one and mypy. Don’t faff about with vscode either. Eh, I’m not getting different editors for different languages (coding, documentation, and otherwise) used in the same project, and IntelliJ doesn’t have nice tooling for everything I need that VSCode does. Not sure how good Pycharm’s typechecking is, but pyright is, IME, usually better than mypy…

PyCharm will be a big upgrade over VSCode for any full sized project trying to use type hints (and really for any Python project)

Re: The Python Paradox (2004)

#189

Post by baq »

thedataangel wrote: post #178
dietrichepp wrote: post #93

Earlier quoted context omitted.

I do see fundamental reasons. Haskell was designed from conception to be a platform for research and education. I’d say it was a wild success at those two things. Certain decisions that made it successful as a platform for research and education make it less suitable for use writing applications in industry. The main decision I am thinking about is lazy evaluation. Lazy evaluation forces authors to write pure code, w…

Having used Haskell in industry, I can say it's actually _surprisingly_ good at boring run-of-the-mill software. The strong focus on correctness and the ecosystem-wide consistency of it's core design patterns means you spend a lot less time debugging things, and a lot more time writing the thing you actually want to write. That said, the type system _does_ stand in the way of learning it - though it's very powerful o…

...which is as easy as using foldl instead of foldl' instead of foldr, which to a beginner is... mildly confusing.

Re: The Python Paradox (2004)

#190

Post by mark_l_watson »

dietrichepp wrote: post #93
epgui wrote: post #43

Earlier quoted context omitted.

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

I do see fundamental reasons. Haskell was designed from conception to be a platform for research and education. I’d say it was a wild success at those two things. Certain decisions that made it successful as a platform for research and education make it less suitable for use writing applications in industry. The main decision I am thinking about is lazy evaluation. Lazy evaluation forces authors to write pure code, w…

OCaml uses eager, not lazy evaluation but it is even less popular than Haskell. BTW, I like Haskell, but I feel like a novice, still learning, even though I wrote a Haskell book (you can read it online for free https://leanpub.com/haskell-cookbook/read).
Post reply on HN