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

411–420 of 993 posts

Re: Python Is Eating the World

#411

Post by 9q9 »

momentoftop wrote: post #267
ComputerGuru wrote: post #212

Earlier quoted context omitted.

> honestly I think "don't use exceptions for control flow" is more of a convention that a "truth" In absolute terms or when coding on paper, perhaps. But in the real world and if performance even remotely matters, it’s as close to a universal rule all languages end up embracing or turning into creaking hulks of slow code given how exceptions work in practice at the level of cpu execution units. C#/IL/.NET embraced ex…

The Ocaml exception implementation is comparatively very performant, and so its exceptions are routinely used for control flow.

I'd be interested to learn about how exceptions are typically using in Ocaml for non-local control flow.

Exceptions have two core properties: (1) non-local jump (carrying a value) and (2) dynamic binding of place to jump to. Contrast this with e.g. break / continue in loops where (2) does not hold. If most use cases of performant OCaml exceptions were not making use of (2) that would be an interesting insight for programming language design.

Have you got data on this matter?

Re: Python Is Eating the World

#412

Post by 6thaccount2 »

ChrisRackauckas wrote: post #80
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…

Python's dependency hell is what made me first look at Julia. I develop on Windows (someone has to :) ), and it was just impossible to get all of the numerical libraries like pydstool, scipy, FEniCS, Daedalus, etc. playing nicely together... so I gave Julia a try. And now the only time I have issues getting a package to run are Julia packages which have a Python dependency. Python is a good language, but having every…

Julia really is nice in this way. It is nice to see the package manager that actually works for me unlike a lot of what I try with pip.

Re: Python Is Eating the World

#413

Post by mooreds »

BinaryIdiot wrote: post #372
zys5945 wrote: post #54

Earlier quoted context omitted.

> Yes, those are caught when using pip freeze. No they are not. Pip freeze does not resolve transitive dependencies, nor does pip know what to do if your transitive dependencies conflict with each another.

I'm not sure about conflict resolution when but I run a pip freeze it adds TONS of dependencies outside of the 2-3 I had in my app because those were the dependencies of my dependencies.

I think that is what you want. Having all your dependencies, including their dependencies, explicitly specified (including name and version) is what gives you reproducible builds.

Ruby does the same thing with Gemfile.lock. npm does the same thing with package-lock.json.

Re: Python Is Eating the World

#414

Post by mooreds »

estsauver wrote: post #379
pmontra wrote: post #330

Earlier quoted context omitted.

I've been working since the 90s and I never attempted to do FizzBuzz. Is it really relevant? Maybe to screen junior developers out of college?

So, as someone who spends maybe 20% of their time hiring, it's still a very effective screen. You wouldn't believe how many people can't do it. People at big companies, respected places. It's surprising.

Wow, that's depressing.

I used a different screen (having people make change based on an arbitrary amount, so if the input was 81, you'd return [25, 25, 25, 5, 1], as we were in the USA) and it was also helpful. I didn't track the number of people that it stymied though.

Re: Python Is Eating the World

#415

Post by metroholografix »

odonnellryan wrote: post #407
metroholografix wrote: post #337

Earlier quoted context omitted.

Same here. I've used Python daily or almost daily for the last ~10 years (thankfully I've used other languages too). I've architected reliable systems on top of it but it was obvious to me almost from the get-go that Python is a terrible language. I credit my previous years of programming in Lisp that trained my mind to see through the Python mirage. One issue is that veneer of Python user friendliness that lures peo…

I honestly think you've just worked on bad projects. Python isn't the perfect language but the quality of the available libraries makes it awesome. The individual quality of projects in any language will always vary.

My criticism is mostly aimed at the language (and its standard library) itself. The major projects I worked on, I architected from the beginning. It is when designing and architecting reliable systems that Python's terrible nature hits you in the face, especially if you're used to better languages.

Take the nonsensical but alluring Python motto "There should be one -- and preferably only one -- obvious way to do it." Assuming this was even true, which it isn't as a series of Python debacles - by its designers no less - over the years has proven, I don't want a language that shoehorns my thinking into "one"-ness. One-ness doesn't solve hard problems. I want modeling flexibility, the ability to examine a problem from multiple perspectives and explore the solution space in-parallel from multiple angles of attack. C and C++, bad as they are, let you do this. Perl lets you do that. Common Lisp is the best language I know on that front, it is _designed_ to let you do this.

I'm not going to say that Python is outright hostile to that mode of working, but it's not designed to bend / be stretched or mold with your mind in the same way that great languages are. Sooner (if you're solving fuzzy problems) or later , you'll run into its limitations and then you can't help but think that you're wasting your time.

Re: Python Is Eating the World

#416

Post by nabdab »

edflsafoiewq wrote: post #226
geofft wrote: post #145

Earlier quoted context omitted.

Thanks, that definitely looks like useful data as a starting point. 1. What is the impact of a continuous long-running process? That is, if instead of trying to calculate a result and then shut down, I'm running a web server 24/7, what's the impact of an interpreted language over a compiled language? (Assume requests are few and I'm happy with performance with either.) This not models web servers but things like data…

> Put another way, if using the interpreted language saved even one minute of developer time, it was a net win for the carbon emissions of the program Developers continue breathing even when they aren't programming.

Sure and trains burn fuel even when you aren’t using them. But if we look at you carbon footprint it doesn’t seem wise to factor in every single train on the planet in your specific account har because they don’t all air still when you aren’t using them.

When talking about the footprint of a company or a project, then you need to restrict the calculations to the resources they actually use. So if a project uses tools to get a product out quicker that means they’ve spend less human-hours, which have a co2 cost associated with them. Then you can weigh the cost of that tool versus the Human Resources both in a financial sense but also with respect to emissions.

Re: Python Is Eating the World

#417

Post by marble-drink »

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…

It's not that bad if you use the right tools. The two main options are an all-in-one solution like poetry or pipenv, and an ensemble of tools like pyenv, virtualenvwrapper, versioneer and pip-tools. I prefer the latter because it feels more like the Unix way.

Why should Python have some "official" method to do this? Flexibility is a strength, not a weakness. Nobody ever suggests that C should have some official package manager. Instead the developers build a build system for their project. After a while every project seems to get its own unique requirements so trying to use a cookie-cutter system seems pointless.

Re: Python Is Eating the World

#419

Post by marble-drink »

astonex wrote: post #42
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…

>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

The only problem with that is it's hard to keep the dependencies up to date. Pip-tools solves this problem.

Re: Python Is Eating the World

#420

Post by zuuow »

ragerino wrote: post #409

I would argue that Pythons biggest issue is performance, which translates in large applications directly into costs. You will need more machines to scale and you will need more power per operation compared to other programming languages. see here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... I think Python makes sense for prototyping and stuff like Jupyter Notebooks. But once mature and going into…

Let's count the minutes until someone comes saying "but you can just write C and bind it to Python", completely missing the point.
Post reply on HN