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

Python Is Eating the World

zdnet.com

Post reply on HN
Print view View original

211–220 of 993 posts

Re: Python Is Eating the World

#211

Post by willtim »

isatty wrote: post #171
KirinDave wrote: post #93

Reading this got me thinking and I wonder if other people feel like me about this, so I'm going to share it. This is not serious, but not entirely unserious... I try to be a good sport about it, but every time I write python I want to quit software engineering. It makes me angry how little it values my time. It does little for my soured disposition that folks then vehemently lecture me about the hours saved by future…

I know I’m responding to opinion but: developer productivity isn’t one of the pitfalls of Python. Yes I agree that if you’re using Python for a large scale project involving lots of developers its not the best; but that’s because it doesn’t have a good type system. You can’t work out why people like it so much because of this misconception. The languages that you gave as examples most definitely do _not_ value your p…

I am more productive in a language with an expressive type system (e.g. Haskell) than one without. Thinking about types not only guides me towards a working solution quickly, but the checker catches all my minor mistakes. In Haskell, you can actually defer all type errors to runtime if you want to. But I have never felt this makes me more productive.

Re: Python Is Eating the World

#212

Post by ComputerGuru »

geewee wrote: post #146
staticassertion wrote: post #141

Earlier quoted context omitted.

I'm not the person you're responding to but what they say resonates with me as a Python developer. I believe Python is quite possibly the best language for a few things * Exploratory programming - such as what data scientists do * Writing programs that will never grow beyond 150LOC, or roughly what fits on a screen + one page down When I have those two constraints met I am almost always choosing Python. Here are some…

The common "don't use exceptions for control flow" is broken right off the bat with StopIteration. I just think error handling in Python is god awful, really. That's not an idiom python has ever subscribed to though, it's always subscribed to the "Better to ask forgiveness than permission" - I think there are strengths to both viewpoints, but honestly I think "don't use exceptions for control flow" is more of a conve…

> honestly I think "don't use exceptions for control flow" is more of a convention that a "truth"

In absolute terms or when coding on paper, perhaps. But in the real world and if performance even remotely matters, it’s as close to a universal rule all languages end up embracing or turning into creaking hulks of slow code given how exceptions work in practice at the level of cpu execution units.

C#/IL/.NET embraced excerpts heavily at around the same time (start of the 2000s) but in time developers (in and out of Microsoft) learned the hard way that it doesn’t scale. With .NET core, exceptions for flow control are completely verboten and APIs have been introduced to provide alternatives where missing. Exceptions should be so rare if you chart all handled exceptions, you shouldn’t see any and would thoroughly explore why one or more pop up when a system or dependency hasn’t exploded.

Re: Python Is Eating the World

#213

Post by rleigh »

umvi wrote: post #4

If only its package management were as easy as its syntax... I wish pip worked the same way as npm: -g flag installs it globally, otherwise it creates a local "python_modules" folder I can delete at any time. And optionally I can save the dependency versioning info to some package.json... Instead, pip is a nightmarish experience where it fails half the time and I have no idea where anything is being installed to and…

This isn't even the start of the problems with pip and pypi. If I install pylibtiff, it embeds a copy of an old libtiff which is binary incompatible with the libraries on my system. I have to build it from source, then it works just fine. But I can't inflict this level of brokenness on my end users.

This applies to many packages embedding C libraries, including numpy, hdf5 and all the rest. There has been minimal thought put into binary compatibility here, meaning that it's a lottery if it works today, or will break in the future.

Re: Python Is Eating the World

#214

Post by autokad »

KirinDave wrote: post #93

Reading this got me thinking and I wonder if other people feel like me about this, so I'm going to share it. This is not serious, but not entirely unserious... I try to be a good sport about it, but every time I write python I want to quit software engineering. It makes me angry how little it values my time. It does little for my soured disposition that folks then vehemently lecture me about the hours saved by future…

Disclaimer, I am a data scientist

I feel the complete opposite. I really enjoy working with python over any other language. R does linear models and time series better and matlab has its charm, but overall I prefer python. Python is so easy to read and quick to program in. I am so glad I am not in the Java/C++ world anymore, but I know people in different roles have to deal with different issues.

Re: Python Is Eating the World

#215

Post by kccqzy »

dehrmann wrote: post #81

There ware a time when I wondered if I should learn Ruby or Python. These days, unless I'm going to be a Rails dev, hands-down Python.

There was a time (more than a decade ago) when I wondered if I should learn Perl or Python. Unfortunately I picked Perl, subsequently forgot it and learned Python instead.

Re: Python Is Eating the World

#216

Post by atoav »

jnwatson wrote: post #112
atoav wrote: post #96

Earlier quoted context omitted.

> Dependency hell is everywhere. Excuse me, but as a long time Python user I have to disagree. I started using Rust two years ago and Rust’s dependency managment is easily the best thing I ever saw (keep in mind that I didn’t see everything , so there is a chance there are better things out there). The project-/dependency-manager Cargo ¹ is more “pythonic” than anything Python ever came up with and where others mumbl…

There's a pattern to this. The later the dependency manager was created, the better it is. This is a hard problem space where each new language got to use the lessons learned on the earlier ones. Cargo, though, has a silver bullet. If it can't find a solution to determine a single version for a package, it simply includes more than one version in the object code. That would take a lot of work to duplicate in Python.

They definitly gave this a thought while designing the library system (”crates”) for the language. I am not sure if it is feasible to retrofit such a solution to something like python.. Python 4 maybe?

Re: Python Is Eating the World

#217

Post by Ultimatt »

KirinDave wrote: post #207
xxxpupugo wrote: post #203

Earlier quoted context omitted.

I don't know why you hate it so much TBH. It is a language, better than MatLab/R/SPSS, which come before it. I honestly don't think it is that bad. And they are many people don't care from a programming language perspective, they need to just finish the functionality.

> It is a language, better than MatLab/R/SPSS, which come before it. I don't think so. I think R is a lot more expressive and not really any harder to read. It might have a steeper learning curve, but it's not so bad that I think that actually matters.

I'm currently learning R. Its a terrible, dreadful programming language. But an excellent DSL for statistical analysis. The main mechanisms for the expressive nature of R is its use of the Environment structure, and terrifying casual use of call stack inspection just to make symbolic APIs. It doesn't even make the latter part of the language without Tidyverse things like rlang. In fact without the Tidyverse efforts the language is even bad as a DSL unless you only deal with a CSV of data with like 100 data points.

Re: Python Is Eating the World

#218

Post by dagenix »

isatty wrote: post #171
KirinDave wrote: post #93

Reading this got me thinking and I wonder if other people feel like me about this, so I'm going to share it. This is not serious, but not entirely unserious... I try to be a good sport about it, but every time I write python I want to quit software engineering. It makes me angry how little it values my time. It does little for my soured disposition that folks then vehemently lecture me about the hours saved by future…

I know I’m responding to opinion but: developer productivity isn’t one of the pitfalls of Python. Yes I agree that if you’re using Python for a large scale project involving lots of developers its not the best; but that’s because it doesn’t have a good type system. You can’t work out why people like it so much because of this misconception. The languages that you gave as examples most definitely do _not_ value your p…

It's unclear to me how a person can be productive if the language doesn't value correctness.

Re: Python Is Eating the World

#219

Post by hnarn »

pc2g4d wrote: post #150

It's such a great language, and so incredibly slow :-/

Probably a kind of premature optimization on my part, but this is why I chose Golang over Python as my primary language. Maybe one day Python will have its own compiler without having to drop into writing C, who knows? For know I think the features of Go are just more attractive than those of Python.

Re: Python Is Eating the World

#220

Post by WaxProlix »

KirinDave wrote: post #205
Abishek_Muthian wrote: post #199

Earlier quoted context omitted.

I would rather wish Golang eat the world than Python, just because the practicality of python becomes questionable when performance is key. In my previous startup in India, I trained unskilled personnel to become decent python developers to work on our product; everything was fine till the product grew exponentially and we had to optimise every nook and corner of it to better serve the customers and save on server bi…

Many of my complaints about Python are valid for Go, except that Go makes even more perilous decisions than Python for error handling (and the community kinda gleefully embraces it). But at least Go is a lot faster and has real concurrency AND parallelism, so it's definitely better than Python.

Go makes worse decisions even, I'd say. Python has gevent, one of the best and most friendly greenlet libs around too, so the concurrency/parallel issues seem fairly moot. It's true that the batteries-included versions of things, while mostly easy to use, falter at scale.
Post reply on HN