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

111–120 of 993 posts

Re: Python Is Eating the World

#111

Post by yawaramin »

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'm sympathetic that Python is relatively not a great language, but IMHO an 80-character line limit is quite reasonable. It's easier to read on smaller screens, easier to view side-by-side diffs, and tends to force you to break up your code more.

That said, this shouldn't be a lint, it should just be enforced by a formatting tool as a format-on-save setting. It just destroys all the wasted arguments about formatting and the wasted time trying to manually line up code.

Re: Python Is Eating the World

#112

Post by jnwatson »

atoav wrote: post #96
hyperpallium wrote: post #57

Earlier quoted context omitted.

Is there a model dependency management system for some other language that addresses all these issues? Dependency hell is everywhere.

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

Re: Python Is Eating the World

#114

Post by l0b0 »

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…

Re. linting, I'd highly recommend Black with whatever line length you want - it'll reliably reformat your code, and once you lose the urge to reformat while typing it's fantastic. It's like deleting a bunch of useless mental code. And the code reviews are even better: include a linting step (ideally with isort) in CI and you can avoid 95% of formatting comments.

Re: Python Is Eating the World

#115

Post by jnwatson »

pietroglyph wrote: post #75
brainless wrote: post #41

Earlier quoted context omitted.

I understand what you are saying but "Python has a lot of problems" is not really a list of "only" dependency management issues. Once your project is setup, dependency management is what you do once in two weeks perhaps. Rest is just writing code.

Having such a basic part of a programming language be awful is inexcusable. It's not just that it takes a lot of time; even if it took no extra time, you're still wasting extra space on your computer, risking breakage on external updates, and compromising security because you can't even tell what code you're running.

"Inexcusable". You know this started in 1989 and its major competition was Perl and TCL, right?

The same issues exist in C, C++, Java and nobody seems to be complaining about those at the same volume.

Re: Python Is Eating the World

#116

Post by RcouF1uZ4gsC »

Python is not eating the world so much as becoming the new Excel. It has a pretty easy learning curve for people who are not programmers. It has pretty good built in tooling. A domain expert, who is not a programmer, can put together pretty impressive models and visualizations relatively quickly.

However, like with Excel, there are serious issues regarding reproducibility, performance, and long term maintenance.

Re: Python Is Eating the World

#117

Post by TheDong »

lwansbrough wrote: post #82

Recently was trying to convert Python to C#... there are few things that are as absolutely incomprehensible as a Python programmer being clever with numpy. I gave up on the conversion. Perhaps this is a point for Python’s flexibility, but I’d say it’s just a waste. Here’s the code. Try to convert this to any C style language. mins = X.min(axis=0) maxs = X.max(axis=0) idxs = np.random.choice(range(self.dim), self.dim-…

Your challenge isn't possible because the code snippet isn't complete. It doesn't include the definition of 'make_tree', 'Node', or the broader context.

That being said, I have no doubt that C++ with Boost would look quite similar to that. The boost libraries have very powerful numeric constructs and can easily handle matrices, uniform random distributions, dot products, and trees.

Re: Python Is Eating the World

#118

Post by jnwatson »

thaumasiotes wrote: post #51
zys5945 wrote: post #44

Earlier quoted context omitted.

I think he is referring to indirect dependencies

>>> Why isn't there any builtin way to automatically define a lock file pip isn't actually part of Python proper.

It isn't part of the Python executable, but it is part of the standard distribution.

Re: Python Is Eating the World

#119

Post by KirinDave »

mkl wrote: post #102
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…

It seems to value my time quite highly, as I can achieve most things more quickly and easily in Python than any other language I know. Can you be more specific about how it increases your burnout? Is it the language, or someone forcing you to use that linter and settings?

> Is it the language, or someone forcing you to use that linter and settings?

It's definitely both.

Preface in true internet style: these are just opinions and you may not share them. That's fine.

I really don't like Python as a language. I don't like its total lack of composability. I don't like its over-reliance on a very dated vision of OO. I don't like how its list comprehensions aren't generic. I don't like how it farms all its data structures out to C. I don't like how it uses cruddy one line lambdas and forces me to name things that are already named by the things I'm passing it to.

And also the linter just exacerbates these things, because the linter is just a crystallized slice of a kind of software engineering culture I really don't like.

Re: Python Is Eating the World

#120

Post by yawaramin »

adev_ wrote: post #98
blaisio wrote: post #33

Python has a lot of problems that really slow down development, but they are all fixable. The biggest issue, in my opinion, is in dependency management. Python has a horrible dependency management system, from top-to-bottom. Why do I need to make a "virtual environment" to have separate dependencies, and then source it my shell? Why do I need to manually add version numbers to a file? Why isn't there any builtin way…

Solution ? Use Nix. > nix-shell -p python3Packages.numpy python3Packages.my_important_package It solves every problem you quoted before.

Or something that works with PyPI directly https://news.ycombinator.com/item?id=20672329
Post reply on HN