Live data from Hacker News

Python Is Eating the World

zdnet.com

531–540 of 993 posts

Re: Python Is Eating the World

#531
post #496
post #471

Earlier quoted context omitted.

Isn't it also just as much about Python is having it's day, granted a day long in the waiting but many langs go through this (Ruby, PHP) and then it tapers off and the next language has it's day. Probably Go will be the next hotness in 5 years.

Actually, Golang isn't so great. Try to change something lower level, for example in their socket implementation. Also, it's trying to promise a sane concurrency and all code I've seen use mutex all over the place.

The main reason I get so curious as to why so many developers would rather use premade packages then spend r&d into highly optimized solutions.

Re: Python Is Eating the World

#532

Earlier quoted context omitted.

Maybe, I love Go but I'm not sure it's the next "hot" thing, all the recent "hot" languages have been scripting languages PHP, Ruby, Python, JS ... I'd say JS and Python are currently jockeying for that position.

Isn’t JS one of the most popular languages? It has a monopoly in the browser so that and C++ already has the most impact on users. Hard to see how it can become more popular.

That's what I mean: Python and JS are jockeying for position as the hot language right now.

Re: Python Is Eating the World

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

I've always seen it like this: Not everyone builds reproducible software with Python (or in general) and how you handle dependencies can vary. Python leaves it open how you do it: globally installed packages, local packages, or a mix of both. In the end, it needs to find the import in the PYTHONPATH, so there's no magic involved, and there are multiple robust options to choose from. So instead of bashing Python for n…

You can have both: provide a sane default for most users and allow people to roll their own.

The reason why Python gets extra criticism for this is because it likes to tell people that there should be one obvious way to do it and that it comes with batteries included yet it's dependency management system is just crap and doesn't follow that at all.

Re: Python Is Eating the World

#534
post #42
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…

>Most people just cross their fingers and hope dependencies don't change Is there anything wrong with pip freeze > requirements.txt and then pip install -r requirements.txt ? This would install the exact versions

If you have "foo==0.1" installed, and foo has the dep "bar~=0.2" (current vers of bar 0.2.1).

Then bar releases version 0.2.2

So your deps want bar 0.2.1, but foo now wants bar 0.2.2

This breaks your pip install.

EDIT: there are a few other gotchas (please respond to this post if you know of any more)

e.g. from https://medium.com/knerd/the-nine-circles-of-python-dependen...

"If two of your dependencies are demanding overlapping versions of a library, pip will not necessarily install a version of this library that satisfies both requirements" e.g. https://github.com/pypa/pip/issues/2775

Re: Python Is Eating the World

#535
Well, I could be put in the ‘Python hater’ category: I do love Python for short programs using TensorFlow, the SpaCy NLP library, PyTorch, etc. I really hate using Python for large applications. Everyone gets to choose their own favorite languages, and for me that would be Common Lisp, Haskell, Java, or Scala for working on large projects. Each to their own though.

Re: Python Is Eating the World

#536

Earlier quoted context omitted.

> Probably Go will be the next hotness in 5 years. I think it will be difficult to grow a large ecosystem for a language with very poor FFI performance [0] in the long run. Golang's poor FFI performance is the number 1 reason I wouldn't use it for my own projects. [0]: https://github.com/dyu/ffi-overhead

People gripe about the strangest things. After using Go almost exclusively for about 18 months I have had to interface with existing C libraries exactly zero times.

I think you don't get the point. Most people don't create such interfaces, but the libraries/systems they work with use them a lot, at least in other languages.

This is for example the reason why there won't be a large mathy/scientific ecosystem in golang.

Re: Python Is Eating the World

#537

Holy Crap! What a lot of irrational, hyperbolic hate for Python. I think everybody should spend their first couple of years working in Fortran IV on IBM TSO/ISPF. No dependency management because you had to write everything yourself. Or maybe [edit: early 90's] C or C++ development where dependency management meant getting packages off a Usenet archive, uudecoding and compiling them yourself after tweaking the config…

https://conan.io/ https://vcpkg.readthedocs.io/en/latest/ You were saying about C/C++ package management?

What about pkgconf + autoconf? Might not be the grand unified package manager you're conditioned to look for, but works well and is pretty much universally used. Besides, C and C++ aren't about language ecosystem lock-in, but about creating standardized artifacts (shared libs, static libs, and executables) designed to work and link well in a polyglot environment (well C++ maybe less so with its symbol mangling/typesafe linkage).

Re: Python Is Eating the World

#538
post #102

Earlier quoted context omitted.

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…

Just a point about linters. They are bad in every language (because everyone has different opinions on what they consider beautiful code).

If you're having a burnout because the PR you just opened are being rejected by the linter you probably just make the linter apply the modifications automatically in pipeline.

We used to hate the linter checks in my current workplace because it was really boring to fix the issues. Now the CI simple fix them, and nobody cares anymore.

Re: Python Is Eating the World

#539

Earlier quoted context omitted.

> Probably Go will be the next hotness in 5 years. I think it will be difficult to grow a large ecosystem for a language with very poor FFI performance [0] in the long run. Golang's poor FFI performance is the number 1 reason I wouldn't use it for my own projects. [0]: https://github.com/dyu/ffi-overhead

People gripe about the strangest things. After using Go almost exclusively for about 18 months I have had to interface with existing C libraries exactly zero times.

I've run a few semi popular open source projects, and it's surprisingly common to hear people tell me it's useless because it's lacking their specific pet feature. Now these comments just make me laugh, just like the parent's gripe with slow FFI

Re: Python Is Eating the World

#540

Earlier quoted context omitted.

> Particularly the lack of braces Since most of my professional experience is with C like syntax languages, I don't get how the lack of braces is an advantages, quite the opposite in my limited experience with Python. Braces define scope unequivocally, they are easy to visually parse and don't care whether you are using tabs or spaces or even if you, loud gasp, mix them. Furthermore, you can copy and paste, say for l…

Two things: 1. For people not used to do programming, braces in text are usually significant - having them everywhere, and even start and end on different lines, are confusing. 2. For people not using standard US keyboard braces are often an SHIFT or ALT command, that makes it wildly different to program uninterrupted.

> 2. For people not using standard US keyboard braces are often an SHIFT or ALT command, that makes it wildly different to program uninterrupted.

I really depends on what you mean by wildly,but I've never programmed in a US keyboard (I use UK or Spanish) and it doesn't seem to be a big issue for me, clearly YMMV

Post reply on HN