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

851–860 of 993 posts

Re: Python Is Eating the World

#851

Post by Ensorceled »

C1sc0cat wrote: post #749
Ensorceled wrote: post #679

Earlier quoted context omitted.

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.

For what use case? for math and tech programming in the 90's I would have gone with Fortran.

Fortran IV? But yeah, Fortran was the goto tool for mathematics, simulations, etc. for the same reason Python often is today: libraries and existing code. I had to convert a simulated annealing algorithm from Fortran to C in the '90s

Re: Python Is Eating the World

#852

Post by kbp »

willtim wrote: post #774
kolanos wrote: post #746

Earlier quoted context omitted.

Python is not weakly typed. It is strongly typed in that it forbids operations that are not well-defined. For example, adding a number to a string) rather than silently attempting to make sense of them. I agree wholeheartedly about weakly typed languages, though.

I believe that marketing Python as "strongly typed" has the potential to confuse rather than educate. Python still crashes at runtime with these errors. It has nice error messages, but it still crashes, potentially in production. If you want to create your own "types", you'll have to add your own runtime checks. It's much more sane than JavaScript, but it's not strongly typed like Haskell. Python does not automatical…

Not automatically coercing values is all that strong typing means. Getting a type error before you run the program is static typing. They're separate axes, and both useful to talk about in a language.

Re: Python Is Eating the World

#853

Post by tus88 »

triceratops wrote: post #848
icxa wrote: post #604

Earlier quoted context omitted.

Have you ever worked in a large engineering organization full of engineers with varying degrees of experience all trying to accomplish the same goal? I can't imagine anyone has ever tried to do engineering at scale (people wise) and did not find the value in static typing. It's why startups eventually moved off RoR once they started scaling. It's why there is such a large push to type JavaScript (have you seen the ro…

> It's why startups eventually moved off RoR once they started scaling. I thought it was because of Ruby's poor performance characteristics.

I assume we are all taking about Twitter and that's what I thought too.

Re: Python Is Eating the World

#854

Post by marmaduke »

jldugger wrote: post #726
CydeWeys wrote: post #701

Earlier quoted context omitted.

I didn't explain the second one well. Here's some exact code. group_keys = ... if not isinstance(group_keys, list): groups_keys = [ group_keys ] So rather than listifying the non-list variable, it was creating a new variable. The cause of this bug is that Python doesn't distinguish between declaring new variables and overwriting existing ones.

Well, this should have been caught as an unused assignment in static analysis. A whole ton of languages allow this situation, so I'm not gonna ding Python too hard for that one. However, here's a related but different python gotcha: if foo(a): v = list(bar(a)) for i in v: print i In this example, v is only defined inside the if. Due to python's limited scopes, v is also valid outside the if, but only has an assignmen…

I'm retty sure PyCharm catches that 2nd one with a warning

Re: Python Is Eating the World

#855

Post by jerf »

6gvONxR4sf7o wrote: post #807
jerf wrote: post #791

Earlier quoted context omitted.

What you say is true, yet, I observe that people undertake that herculean effort with some frequency. Whether that's a good idea, and why that is, those would be entirely separate conversations. But it's just an observable fact that languages pick up native implementations of core functionality over time, subject to certain performance restrictions (e.g., I'm sure that if it wouldn't be unusably slow, Python would ha…

The effort I'm familiar with is the many attempts to make a decent linear algebra library in haskell. There are a number of libraries with huge work put in, but none has reached blas/lapack parity. Nothing's remotely comparable to numpy in ease of use yet. It picks up more libraries as time goes on, and the existing ones mature, but it's so slow that I'm skeptical they'll ever match numpy's usefulness a decade ago.

I think it's really easy to focus on the big hitters and forget they are the exceptions. Yes, matching lapack, any GUI toolkit, a browser engine, and a handful of other things is a big challenge that takes its own community to overcome, not something any language community can do with an incidental fraction of the community's available firepower.

But those are the exceptions, and often you don't need a best-of-breed solution and may prefer the language-native one.

Again, I'm not theorizing about what could be here; I'm looking out in the world, where I see that most libraries tend to emerge out into a native version if the underlying language can possibly meet the basic requirements for performance and such. This is something that needs to be explained, not explained away.

Also... I love me some Haskell, and on a per capita basis the community is great, but if Rust's community isn't already several times larger and growing faster, I'd be stunned, just to pick one example. Haskell has some very interesting cases of best-of-breed libraries, but it doesn't exhibit the library profusion you get from sheer personpower. (Of course, it doesn't really have the problems you get when your libraries are generated by sheer personpower either.)

Re: Python Is Eating the World

#856

Post by ernst_klim »

verttii wrote: post #826
p1esk wrote: post #799

Earlier quoted context omitted.

Right now I’m experimenting with a pretty complicated model (60+ layers of multiple types), and I plan to train it on several hundred GB of data, using 8-16 node cluster (4 GPUs per node). Does Owl have a well tested and well documented autograd library with distributed GPU support (e.g. Horovod)? With a good choice of optimizers, regularizers, normalizers, etc, so I can focus on my model and not on debugging the plu…

I feel what you're saying is that regardless of how subpar a language is compared to alternatives as long as it has community built specific libraries that solve your problems you're more productive using them than anything else. Which is of course a fair point. A language by itself is probably not even in the top 3 considerations when choosing new tech. Stuff like runtime, ecosystem and the amount of available devel…

> A language by itself is probably not even in the top 3 considerations when choosing new tech. Stuff like runtime, ecosystem and the amount of available developers would probably be more important in most cases.

Totally depends on a domain. In serious mission critical software you wont use libraries, but will use the language.

Re: Python Is Eating the World

#857

Post by marmaduke »

CydeWeys wrote: post #850
_coveredInBees wrote: post #842

Earlier quoted context omitted.

I don't think that's fair to be honest. If you had simply used Pycharm with default settings you would have easily caught the first bug due to the linting. It's a fair complaint, but this specific bug is easy to catch using any modern Python IDE.

I've never found the "Use this specific IDE" defense particularly valid, considering that many IDEs don't have these features and that in other languages the compiler itself protects you. Needless to say, I was not using Pycharm for this development, nor am I likely to install an entire IDE just for a small change I'm making on a random project. It's a non-trivial burden to configure and learn an entire IDE, vs just…

> a non-trivial burden to configure and learn

any new tool chain.

It's hard to take complaints like this seriously.

Re: Python Is Eating the World

#858

Post by tus88 »

icxa wrote: post #604
tus88 wrote: post #526

Earlier quoted context omitted.

Well in just glad this is the top comment, as Python really is taking over the world for a reason. And of all the bugs I have written in recent memory, not one came down to a lack of static typing. They were due simply to logic errors, flawed assumptions, misunderstood requirements, and good old race conditions. The static typing zealots like to think if it compiles is must be perfect, however this is a mirage. Unit…

Have you ever worked in a large engineering organization full of engineers with varying degrees of experience all trying to accomplish the same goal? I can't imagine anyone has ever tried to do engineering at scale (people wise) and did not find the value in static typing. It's why startups eventually moved off RoR once they started scaling. It's why there is such a large push to type JavaScript (have you seen the ro…

From the link:

> 1. Uncaught TypeError: Cannot read property If you’re a JavaScript developer, you’ve probably seen this error more than you care to admit. This one occurs in Chrome when you read a property or call a method on an undefined object.

Does typing stop null object errors in JS, Java or C for that matter? No. You need to continually check for null objects in all langs I use including Python. It seems most of the bugs on that page are of a similar vein.

Re: Python Is Eating the World

#859

Post by CydeWeys »

marmaduke wrote: post #857
CydeWeys wrote: post #850

Earlier quoted context omitted.

I've never found the "Use this specific IDE" defense particularly valid, considering that many IDEs don't have these features and that in other languages the compiler itself protects you. Needless to say, I was not using Pycharm for this development, nor am I likely to install an entire IDE just for a small change I'm making on a random project. It's a non-trivial burden to configure and learn an entire IDE, vs just…

> a non-trivial burden to configure and learn any new tool chain. It's hard to take complaints like this seriously.

It's even harder to take "The IDE should make up for deficiencies in the language" seriously. In languages that handle this stuff well, you can edit in Notepad and still not make these mistakes. Why push it up several levels to a few specific IDEs that most people don't even use?

Re: Python Is Eating the World

#860

Post by mark_l_watson »

icebraining wrote: post #668
mark_l_watson wrote: post #551

Earlier quoted context omitted.

Thanks for that! I am tired of messing with conda, virtualenv, etc. and since I use simple Makefiles to build and run most of my code, I can easily stick with the standard latest stable version Python installation when using your trick. EDIT: a question: when I have to use Python, I like to break up my code into small libraries and make wheel files for my own use. How do you handle your own libraries? Do you have one…

> How do you handle your own libraries? Do you have one special local directory that you build wheel files to and then reference that library in your requirements.txt files? We didn't build wheels. We had a centralized git host (Gitlab, but any of them works) with all our libraries, and just added the git url (git+ https://... ) to the requirements.txt

Even better, thanks.
Post reply on HN