Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Breaking up with Python

cedwards.xyz

Post reply on HN
Print view View original

111–120 of 179 posts

Re: Breaking up with Python

#111

Post by Dove »

I want to break up with Python, too. The one-size-fits-all philosophy that runs through the language from end to end leaves me feeling like I'm typing with three fingers. Sometimes its Right Way really is okay or even right, but sometimes I'd really, really, rather use something else. I worry about a generation of programmers for whom this is the first, main, and possibly only thing they've learned. I worry about them being brain damaged.

But where would I go? I clicked through hoping to find a good suggestion, and found none.

Python has become the lingua franca of programming, in many contexts, in many fields. You don't have a choice. You have to be able to read it, if you want to read what people are doing. You have to be able to write it, if you want people to read your stuff. It's where the libraries are. It's where stuff is happening. For better or for worse, Python won.

Even if I don't care about any of that, I really don't know where to go.

I really loved perl. I loved the powerful expression and conciseness. I miss it. But perl 5 is old, and it shows -- a lot of good ideas have come along in the last couple decades, and a lot of things that seemed like good ideas at the time really haven't worked out. A decade or so ago, I was excited about perl 6, but it doesn't seem to have worked out.

I don't like python. But I don't know what to replace it with. Javascript and Ruby seem like the serious options to me, and it's hard to take the one seriously, and the other is so niche that that itself feels like a serious drawback. I want a general purpose scripting language that can do small scripts well (Messes allowed! Shortcuts encouraged! Power in a small space!) and grow to large projects well (Thoughtful object system! Good package management! Good support for alternative paradigms!)

I just can't figure out what that would be.

Re: Breaking up with Python

#112

Post by samuell »

anigbrowl wrote: post #2

I don't fully agree with these arguments, but they all have some validity. I really felt his point on the documentation - it's great that it's reference-complete if that's what you're looking for, but it's maddening if you are coming to something to find out what it does.

DevDocs (https://devdocs.io) is a great interface to the existing (content-wise wholly OK) Python docs.

Re: Breaking up with Python

#113

Post by dragonwriter »

Atlas22 wrote: post #98
the_af wrote: post #37

Last time I argued, like the TFA does, that Python's typing system is both too complex for casual users and useless for power users ("it doesn't do anything" is about right), and that this makes it hard to evangelize its use to other devs who aren't sold on type systems ("but this doesn't do anything!"), I got into a 30-level nesting flame war with some HN regular who just wouldn't let go . So that's still my line of…

Yeah, I think I agree with you. I still find it curious that the python language server is quite capable of inferring types from unannotated code yet most of the type checking tools for python seem to explode as soon as they encounter an very popular yet untyped library. I guess typing is more of an afterthought than a priority for most dynamic language developers so it doesn't get much love.

> I still find it curious that the python language server is quite capable of inferring types from unannotated code yet most of the type checking tools for python seem to explode as soon as they encounter an very popular yet untyped library.

There are multiple python language servers, but if you mean the Microsoft one, well, that just incorporates one of the best of the Python static typecheckers (Microsoft’s pyright)

Re: Breaking up with Python

#114

Post by dragonwriter »

kcartlidge wrote: post #106
Atlas22 wrote: post #98

Earlier quoted context omitted.

Yeah, I think I agree with you. I still find it curious that the python language server is quite capable of inferring types from unannotated code yet most of the type checking tools for python seem to explode as soon as they encounter an very popular yet untyped library. I guess typing is more of an afterthought than a priority for most dynamic language developers so it doesn't get much love.

Sounds like an opportunity for a type checker that uses the language server.

> Sounds like an opportunity for a type checker that uses the language server

The language server itself uses a typechecker, so you'd just be building a typechecker that uses another typechecker by a roundabout route.

Re: Breaking up with Python

#115

Post by 411111111111111 »

Dove wrote: post #111

I want to break up with Python, too. The one-size-fits-all philosophy that runs through the language from end to end leaves me feeling like I'm typing with three fingers. Sometimes its Right Way really is okay or even right, but sometimes I'd really, really, rather use something else. I worry about a generation of programmers for whom this is the first, main, and possibly only thing they've learned. I worry about the…

That question can't be answered without knowing what kind of programs you're writing. You got a lot of options if you're thinking about websites/apis, almost none if it's machine learning and basically everything is better if you're thinking about GUI applications.

Re: Breaking up with Python

#116

Post by Atlas22 »

dragonwriter wrote: post #113
Atlas22 wrote: post #98

Earlier quoted context omitted.

Yeah, I think I agree with you. I still find it curious that the python language server is quite capable of inferring types from unannotated code yet most of the type checking tools for python seem to explode as soon as they encounter an very popular yet untyped library. I guess typing is more of an afterthought than a priority for most dynamic language developers so it doesn't get much love.

> I still find it curious that the python language server is quite capable of inferring types from unannotated code yet most of the type checking tools for python seem to explode as soon as they encounter an very popular yet untyped library. There are multiple python language servers, but if you mean the Microsoft one, well, that just incorporates one of the best of the Python static typecheckers (Microsoft’s pyright…

Yeah I was indeed referring to Pylance, the Microsoft one. I was unaware that pyright was used under the hood, thanks.

Re: Breaking up with Python

#117

Post by kcartlidge »

dragonwriter wrote: post #114
kcartlidge wrote: post #106

Earlier quoted context omitted.

Sounds like an opportunity for a type checker that uses the language server.

> Sounds like an opportunity for a type checker that uses the language server The language server itself uses a typechecker, so you'd just be building a typechecker that uses another typechecker by a roundabout route.

It's turtles all the way down.

Though in seriousness I'd presume it would be bad type checker uses language server which uses better type checker, which may help with the problem.

Re: Breaking up with Python

#119

Post by heavyset_go »

joromero wrote: post #87

Doesn't JavaScript suffer from most of the same issues the author raises about Python. > Documentation JavaScript wins here thanks to MDN, but it's not the official documentation. > Package Management I agree that Python's package management has its issues, but JS is insane in this regard > Standard Library JavaScript's standard library is definitely smaller than Python's > Slow This is clearly a win for JS > Size Wh…

It does, which surprised me when the author said they preferred JS over Python given the reasons they stated.

There are a lot of reasons to like or not like Python that will become evident after using it in a significant fashion. I was hoping for some of that insight, both to commiserate and celebrate the horrors and joys that I've experienced using the language and its ecosystem for some time. This article was not that.

Re: Breaking up with Python

#120

Post by Dove »

411111111111111 wrote: post #115
Dove wrote: post #111

I want to break up with Python, too. The one-size-fits-all philosophy that runs through the language from end to end leaves me feeling like I'm typing with three fingers. Sometimes its Right Way really is okay or even right, but sometimes I'd really, really, rather use something else. I worry about a generation of programmers for whom this is the first, main, and possibly only thing they've learned. I worry about the…

That question can't be answered without knowing what kind of programs you're writing. You got a lot of options if you're thinking about websites/apis, almost none if it's machine learning and basically everything is better if you're thinking about GUI applications.

You know, I hadn't thought about it that way before. Perhaps the dream of a general purpose language was always incoherent. Perhaps the mess you get when perl tries to offer options to do everything well, and the suffocation you get when python tries to do everything the same way, are inevitable. Maybe using one language for small and large projects was never going to end well -- maybe either the language or the programmers were always going to do it wrong.

I suppose I have been assuming that the best policy is to do as the Romans for a long time now. Windows apps are C++ (or is it C# now?) because that's how things are over there. Android is Java, or Scala if you must -- at any rate, you hardly get to pick. Iphone requires learning Objective C. Jquery for frontend, or whatever the cool kids are doing; PHP on the back is good enough for most of the web, and it's good enough for you. And as you say, in ML, Python is not optional.

And as I think about it, I've been using specialized languages in specialized contexts for a long time. It seems the knowing the underlying language is only ever part of the problem -- you have to learn the specialized language for what you're doing, whether it's GL for graphics or your web framework's way of doing things, or MFC or .NET, or . . .

Yeah. Small tools for specific purposes, and follow the local ecosystem. Things have been going that way, and it's probably a good answer.

When in Rome, then. I like that answer. Thanks.

Post reply on HN