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

981–990 of 993 posts

Re: Python Is Eating the World

#981

Post by 89qh4p »

sosodev wrote: post #83
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…

Pipenv has felt to me like a pretty solid solution. It's not perfect but it's a lot better than the other options.

Pipenv has a good approach to management, similar to npm, but the implementation is buggy. It gained popularity by being recommended very early on in the official python documentation while being misleadingly advertised as production-ready.

If you look at the issues section in its github repo, you'll see that there are some pretty basic bugs there which are very annoying or disruptive. Moreover it seems the author has almost left the boat and a handful of contributors have to tidy things up.

Just to illustrate my point. I think a package manager that takes a few minutes to install a single tiny package, or don't prevent you from adding non-existing packages (e.g. spelling mistake), or doesn't let you install a new package without trying to upgrade all other packages isn't really production-ready. These are known issues since November last year.

Re: Python Is Eating the World

#982

Post by andybak »

RhysU wrote: post #528
andybak wrote: post #430

Earlier quoted context omitted.

> Flexibility is a strength, not a weakness. "There should be one-- and preferably only one --obvious way to do it.": https://www.python.org/dev/peps/pep-0020/

They almost rescinded that in PEP 357 and ultimately did so in PEPs 468/469. PEP -23 updated the standard library to match, but not until 3.9.1.a. Until then, beware the various blog posts you'll find on Google talking about this concept on 1.x.

It was always an ideal to aim for rather than a strict rule. I don't see any of those PEPs changing the balance enough to claim the principle was dead (maybe a bit injured...)

Re: Python Is Eating the World

#983

Post by bart_spoon »

esyir wrote: post #970
bart_spoon wrote: post #552

Earlier quoted context omitted.

If you are a computer scientist doing a little data science, then R is awful for the reasons you detailed. If your function entirely consists of data science, then R is a fantastic language for the same reasons you hate it.

R is a fantastic statistical toolkit and a terrible programming language. Building software in it? Massive pain in the ass. Processing tabular datasets on the other hand is an absolute breeze that leaves pandas in the dust. Tidy verse makes it better though.

Yeah, this is generally my take. On the one hand, I cringe when I see all the discussion regarding how much better Python is than R for data science. As a data scientist, who spends 90% of my time cleaning, manipulating, and modeling data, I would take R any day over Python. But at the same time I realize that for many, data science is more 90% software engineering, with 10% being the actual data manipulation and modeling, and for these people, R is a complete non-starter.

Re: Python Is Eating the World

#984

Post by takeda »

jnwatson wrote: post #960
takeda wrote: post #895

Earlier quoted context omitted.

Also with C and C++ your dependencies compile with your code into a single binary, unless you explicitly opt into using a library, and when you do it becomes a package manager's issue not yours.

That's vastly oversimplifying the problem. "DLL hell" is a term for a reason. The vast amount of effort and complexity Microsoft has put into managing this problem is proof that dependency management for C and C++ is not a solved problem.

It is not a solved problem, but it is a problem that C and C++ developers don't care about, because it is a problem of packagers.

This is why it doesn't seem so bad if you're programming in those languages.

Re: Python Is Eating the World

#985

Post by lsc »

6thaccount2 wrote: post #963
lsc wrote: post #863

Earlier quoted context omitted.

so I am studying for the FE (I need a lot of math before taking it is realistic) mostly 'cause it gives me this broad feel for things Engineers all know. (I will take the 'other disciplines' - mostly because I want this to be as broad as possible; being broad but shallow makes it a lot easier for me, too, but for me, it being broad is an advantage in other ways, too.) I personally find tests to be way easier than sch…

Wait...are you studying for the FE without getting an engineering degree? Props to you. One thing to keep in mind though is that there is a morning and afternoon session that are both 4 hours iirc. The first session is always a general session which covers the absolute basics of Engineering math, circuits, thermodynamics, statics, Dynamics, chemistry, and physics. It really is very easy if you remember the classes. S…

Yeah, they'll let anyone with a couple hundred bucks sit for the FE. The chances of getting a PE or even an EIT, though, without a degree are... slim to none. But that's not really my goal? (I mean, it would be if it were just tests) Mostly I just want to know those 'absolute basics' of which you speak, and I like to have a test to study towards.

I'll check out that edx class, thanks, that sounds like my thing.

Re: Python Is Eating the World

#986

Post by kbp »

enginaar wrote: post #951
kbp wrote: post #884

Earlier quoted context omitted.

Static typing means that types are figured out statically by looking at the source code, and type errors are detected then when it notices a mismatch. Dynamic typing means that types are worked out at runtime by looking at live objects when code operating on them executes. Strong typing means that types cannot be substituted for other types. In C, you can write `int x = "one"` and the char * (address of) "one" is aut…

You're explaining static typing vs dynamic typing. I'm still failing to see how different Strong vs Static. If the only difference is "Static" means "types are figured out statically by looking at the source code" do you mean it's possible to change the type unlike strong typing? If not, can we say Static encapsulates Strong?

Static typing is not a superset of strong typing, they're on different axes. Strong vs weak typing (which I explained in the second paragraph) is about how strictly types need to match expected types before you get a type error. Static vs dynamic typing is about when you get a type error (during a static typechecking phase, or at runtime when you try to use a value as that type).

When you say the type cannot change, that's ambiguous: do you mean the type of the value a variable holds, or the type of the value itself? In C (a statically typed language), "int x" means that x will always hold an int, but you can still assign a pointer to it, it just turns into an int (weak typing). In Python (a dynamically typed language), the variable "x" wouldn't have a type (so it could hold an int at one point and a string later), but the value it holds does, and because it's strongly typed, it would throw a type error if you attempted to use it in a place where it wanted a different type (eg, `1 + "2"` does not turn 1 into a string or "2" into an int).

Re: Python Is Eating the World

#987

Post by [deleted] »

grumpyprole wrote: post #925
kbp wrote: post #897

Earlier quoted context omitted.

Why aren't statically typed programs really just dynamically typed programs where all the types happen to be statically inferable?

Because most statically typed languages allow us to define our own types, add type signatures to constrain etc. Dependently typed languages also allow types to depend on values. Inference is useful, but only one aspect of static typing.

[deleted]

Re: Python Is Eating the World

#988

Post by enginaar »

kbp wrote: post #986
enginaar wrote: post #951

Earlier quoted context omitted.

You're explaining static typing vs dynamic typing. I'm still failing to see how different Strong vs Static. If the only difference is "Static" means "types are figured out statically by looking at the source code" do you mean it's possible to change the type unlike strong typing? If not, can we say Static encapsulates Strong?

Static typing is not a superset of strong typing, they're on different axes. Strong vs weak typing (which I explained in the second paragraph) is about how strictly types need to match expected types before you get a type error. Static vs dynamic typing is about when you get a type error (during a static typechecking phase, or at runtime when you try to use a value as that type). When you say the type cannot change,…

If I got this correct, you're saying strong can be compared to weak and static can be compared to dynamic. So there is no such thing as strong vs static typing comparison.

Re: Python Is Eating the World

#989

Post by kbp »

enginaar wrote: post #988
kbp wrote: post #986

Earlier quoted context omitted.

Static typing is not a superset of strong typing, they're on different axes. Strong vs weak typing (which I explained in the second paragraph) is about how strictly types need to match expected types before you get a type error. Static vs dynamic typing is about when you get a type error (during a static typechecking phase, or at runtime when you try to use a value as that type). When you say the type cannot change,…

If I got this correct, you're saying strong can be compared to weak and static can be compared to dynamic. So there is no such thing as strong vs static typing comparison.

Right, they describe different aspects of how types work in a language.

Re: Python Is Eating the World

#990

Post by enginaar »

kbp wrote: post #989
enginaar wrote: post #988

Earlier quoted context omitted.

If I got this correct, you're saying strong can be compared to weak and static can be compared to dynamic. So there is no such thing as strong vs static typing comparison.

Right, they describe different aspects of how types work in a language.

Thanks. I appreciate the time you took for clarifying in detail.
Post reply on HN