Live data from Hacker News

Python Is Eating the World

zdnet.com

671–680 of 993 posts

Re: Python Is Eating the World

#671
post #42

Earlier quoted context omitted.

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

Another more obscure one:

https://github.com/pandas-dev/pandas/issues/27206

All of a sudden, a numpy release pulls in a new version for a pandas build (that incidentally breaks for py2)

This without involving a "~=", but rather because pandas needs to build from source, and chooses the latest numpy build to do so.

Re: Python Is Eating the World

#672

Earlier quoted context omitted.

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.

Python needs FFI, because its native performance is fairly poor [1]. In general, Go gets away with less FFI because it's fast enough that it doesn't need things to be implemented in C to run quickly. This is especially true if you consider "Go" as "Go + its ASM", which is probably what you'd want if you think of it in terms of science programming.

For another example of a similar effect, Rust has great FFI. Yet I would expect over time it will be necessary for fewer and fewer things, because Rust is already roughly on par with C, and over time, a native Rust API will still be preferable to a C API wrapped with a Rust access layer. It will always have great C FFI, by its nature, but the percentage of projects that won't need it is already pretty high and probably only going up over time.

[1]: People seem to misinterpret this statement a lot, as if I'm saying Python is bad or something. No; it is simply this: Python performance is not very good at a very raw level. It is merely one characteristic of a language out of many, many relevant ones, not a full assessment of the language. Python has many other dimensions in which it has superior capabilities. It just pays for that on the performance dimension. (Whether that's an essential or an accidental tradeoff, well, ask me again in ten years; the programming language community seems to be in the process of working that out right now.)

Re: Python Is Eating the World

#673
post #580
post #546

Earlier quoted context omitted.

> I honestly wouldn't want to have to write this stuff in Python for a simple reason: I don't think I could live without static typing, which is a fantastic tool when you need to manage a large code base written by multiple people over multiple years. I can make a change in some package, do a dry-run compile of every system that uses it, and then see what needs updating. It gives me certain guarantees about data inte…

> Programming in the large without type safety is a fool’s errand. Programming in the large without tests is a fool's errand. Type systems don't guarantee correctness.

> Programming in the large without tests is a fool's errand. Type systems don't guarantee correctness.

I never said you do not need tests nor that static typing is a panacea. In my view it's a necessary, but not sufficient condition, when programming in the large.

Re: Python Is Eating the World

#674
post #294

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…

Over-sensitive individuals are hard to please and often unhappy. That's more of a personality flaw than a flaw with the current state of software engineering. If there's one thing wrong with our profession is a lack of ethics and accreditation - we're essentially letting random people build critical infrastructure and utilities. We don't have a tooling problem, in fact we have too many tools. I see so many people (es…

> Over-sensitive individuals are hard to please and often unhappy. That's more of a personality flaw than a flaw with the current state of software engineering.

Ah yes. Just remove the part of myself that got me into software as a child, and proceed robotically.

Why didn't I think of that?

Re: Python Is Eating the World

#675
post #571

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…

I had to learn Fortran IV for my first job. Am I allowed to hate Python? Are you assuming everyone complaining here is young, and this is their first language? Consider that maybe they're complaining because they've used older languages they liked more. Often, not having a feature is preferable to having a feature designed or implemented poorly.

There's a difference between hating Python, and saying (I'm guessing is the comment that spurred this one) this: "I try to be a good sport about it, but every time I write python I want to quit software engineering.", like a top-level comment below says.

If you had to write Python, would you also want to quit software engineering? Would you go back to Fortran instead of Python?

Of course you're allowed to hate Python but someone saying "every time I write python I want to quit software" is either extreme hyperbole, some tangentially related issue like depression, or just no language at all would make them happy enough.

Re: Python Is Eating the World

#676
post #580

Earlier quoted context omitted.

> Programming in the large without type safety is a fool’s errand. Programming in the large without tests is a fool's errand. Type systems don't guarantee correctness.

You've got it backwards. (Sound) Type systems guarantee correctness for the invariants encoded as types. If it compiles, you know it doesn't have any type related errors at all. With more evolved type systems even your program's logic (or large parts of it) is guaranteed. Tests just allow you to test random invariants about your program. If it compiles and your add() method works when passed 2, 2 and gives 4, it stil…

You need to test anyway. So, is it the case that type systems provide much value beyond what a proper set of tests, which are necessary, are going to provide anyway?

If you skimp on testing your system will be crap, but at least the type system can fool you into thinking otherwise because it still compiles.

Re: Python Is Eating the World

#677

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…

I don't agree at all. Your comment basically says: "It used to suck badly. So don't complain it sucks now.". I think dynamic typing is the bane of good software and we as an industry should try to actively discourage new code to be written in dynamically typed languages. That's not to say that Python doesn't have it's place. But I see it more as a programming language for small utilities no more then 2k loc in length…

No, what I'm saying is that it used to suck really badly and we survived just fine, so I find all the over-wrought hand wringing about the havoc and burnout caused by Python's flaws hyperbolic.

Re: Python Is Eating the World

#678

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…

I'm a somewhat older programmer, and I've worked with a variety of languages (C, OCaml, C++, Scheme, Go, Java...). I think all of them are great in their own way and there's a lot to be learned with all of them. I started to use Python quite recently and I really like it. It is a well-designed language with high-level abstractions that are really fun to use. I like the pervasive use of iterators, the 'everything is a…

You shouldn't trust your programs. That's why you test them mercilessly.

Re: Python Is Eating the World

#679

Earlier quoted context omitted.

No, not at all, I'm saying if you had been a C programmer in the 90's you would have some perspective on some of the complaints and comments about python in 2019.

Why are you complaining about C in the 90s? If you'd been using punchcards in the 50s you'd have some perspective on some of the complaints and comments about C in 1990.

I'm actually not complaining about C in the '90s, it was amazing compared to Fortran in the '80s.

Funny story, my first co-op job (Fortran IV), my boss made me fix a bug using punch cards so I'd appreciate why the codebase wasn't as nice as it might be. THAT was prespective.

Re: Python Is Eating the World

#680

Earlier quoted context omitted.

No it doesn't. As someone else mentioned, RPython exists, and in general, bootstrapping is nice, but there are a variety of compelling reasons to not rewrite CPython in python, that have nothing to do with it being "suited" or not. History, reliability, simplicity, lack-of-value, etc. At this point there's not much to gain by rewriting cpython in python (pleasing some guy on the internet), and quite a lot to lose (si…

It wouldn't have been years of work if they started right after Python was first implemented instead of a big-bang now. For 25 years each time they've implemented a new feature they've chosen C over Python to do it, for reasons of it being better suited, some of which you've listed yourself! Like simple C-interop! I don't think it's a criticism of Python! I've worked on meta-circular implementations of languages and…

Right, but all of those are historical, not innate, which makes your comment wildly misleading.

If the Python ecosystem weren't c-based, it wouldn't matter. But it is. But that has nothing to do with python the language in a vacuum, and everything to do with choices some guy made 25 years ago.

Post reply on HN