Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Python keeps growing, explained

github.blog

Post reply on HN
Print view View original

421–430 of 459 posts

Re: Why Python keeps growing, explained

#421

Post by kajaktum »

t43562 wrote: post #336
kajaktum wrote: post #265

Earlier quoted context omitted.

I was thinking of using python as a script (duh). > GNU Make is really far more sophisticated than people give it credit for and it's not that easy to replace it. Since its turing complete, it should be able to do everything make can. For example, to compile a C project involves something like: 1. grab all the C files inside `src/`. 2. join the filenames with whitespace delimiter 3. execute `gcc ` It can also be used…

Well as I pointed out, it does happen e.g. in Meson. Make doesn't do any of the things you mention - it just works out what targets need to be rebuilt and the code to do it is in the rules that you have to write in a shell language like bash. I admit you can use builtin implicit rules for C and get away with that up to a point but only a fairly low point. python is far harder to use than bash when it comes to running…

>python is far harder to use than bash when it comes to running processes and doing things with them and doing the file-system manipulation that is usually wanted when building.

Can easily be solved by having libraries that does. Which is far better solution that hacking/chaining 5 different obscure unix tools to do string manipulation.

>you can introduce all sorts of ordering problems when a build runs on a different machine and doesn't work because it's executing build tasks in a different order.

Surely it is better than make? Even if make is "better" because it "just works". This is basically Hyrum's Rule waiting to be unleashed.

>If you really want to build by "writing a script" (groan - because that's the age old horrible solution) why bother with python?

Because I personally cannot decipher make and I think this is the experience of many developers as well. And how many make derivations are there? Its basically an arcane spell that needs to be chanted with every project (configure -> make -> make install).

Re: Why Python keeps growing, explained

#422

Post by jasfi »

noirscape wrote: post #418
dkarl wrote: post #270

Earlier quoted context omitted.

I sometimes think about what Python would be like if it were written today, with the hindsight of the last thirty years. Immutability would be the default, but mutability would be allowed, marked in some concise way so that it was easy to calculate things using imperative-style loops. Pervasive use of immutable instances would make it impossible for libraries to rely on mutating objects a la SQLAlchemy. The language…

This is pretty much what nim is btw. Very fun language in my experience.

Nim is fun, but it needs to be more popular.

Re: Why Python keeps growing, explained

#423

Post by _aavaa_ »

slt2021 wrote: post #420
_aavaa_ wrote: post #415

Earlier quoted context omitted.

Guess that'll depend on how much you need the performance and how much code it is. They're comparing numpy (SIMD plus parallelism) with straightforward C code and getting a 2-5x improvement.

I highly doubt that numpy can ever be a bottleneck. In typical python app - there are other things like I/O that consume resources and become bottleneck, before you run into numpy limits and justify rewrite in C.

I haven't personally run into IO bottlenecks so I have no idea how you would speed those up in Python.

But there's two schools of thoughts I've heard from people regarding how to think about these bottlenecks:

1. IO/network is such a bottleneck so it doesn't matter if the rest is not as fast as possible.

2. IO/network is a bottleneck so you have to work extra hard on everything else to make up for it as much as possible.

I tend to fall in the second camp. If you can't work on the data as it's being loaded and have to wait till it's fully loaded, then you need to make sure you process it as quickly as possibly to make up for the time you spend waiting.

Re: Why Python keeps growing, explained

#424

Post by cornholio »

Daishiman wrote: post #416
cornholio wrote: post #350

Earlier quoted context omitted.

Exception error handling - and their extensive use in the standard library -is the fundamental design mistake that prevented Python becoming a substantial programing language. Coupled with the dynamic typing and mutability by default, it guarantees Python programs won't scale, relegating the language to the role of a scratchpad for rough drafts and one off scripts, a toy beginner's language.

I have no idea why you say that it's a scratchpad or a toy language consdering that far more production lines of code are getting written in Python nowadays than practically any other language with the possible exception of Java.

But that's the same with Excel: massive usage for throwaway projects with loose or non-existing requirements or performance bounds that end-up in production. Python is widely used, but not for substantial programming in large projects - say, projects over 100 kloc. Python hit the "quick and dirty" sweet spot of programming.

Re: Why Python keeps growing, explained

#425

Post by [deleted] »

Yoric wrote: post #412
stevofolife wrote: post #309

Earlier quoted context omitted.

Python code can be production code. There are many people and companies shipping Python production code and generating substantial value.

You are correct, there are absolutely huge companies shipping Python production code and generating substantial value. Do we agree that this somewhat orthogonal to what I'm writing, though?

[deleted]

Re: Why Python keeps growing, explained

#426

Post by Too »

dkarl wrote: post #270
Yoric wrote: post #214

Earlier quoted context omitted.

I fully agree with the description. What worries me, though, is that the features that make Python quite good at prototyping make it rather bad at auditing for safety and security. And we live in a world in which production code is prototyping code, which means that Python code that should have remained a quick experiment – and more often than not, written by people who are not that good at Python or don't care about…

I sometimes think about what Python would be like if it were written today, with the hindsight of the last thirty years. Immutability would be the default, but mutability would be allowed, marked in some concise way so that it was easy to calculate things using imperative-style loops. Pervasive use of immutable instances would make it impossible for libraries to rely on mutating objects a la SQLAlchemy. The language…

Statically typed with duck typing is called structural typing. (As opposed to nominal typing, with inheritance hierarchies).

It’s already what you get with python and mypy. Using typing.Protocol or Unions.

Re: Why Python keeps growing, explained

#427

Post by t43562 »

kajaktum wrote: post #421
t43562 wrote: post #336

Earlier quoted context omitted.

Well as I pointed out, it does happen e.g. in Meson. Make doesn't do any of the things you mention - it just works out what targets need to be rebuilt and the code to do it is in the rules that you have to write in a shell language like bash. I admit you can use builtin implicit rules for C and get away with that up to a point but only a fairly low point. python is far harder to use than bash when it comes to running…

>python is far harder to use than bash when it comes to running processes and doing things with them and doing the file-system manipulation that is usually wanted when building. Can easily be solved by having libraries that does. Which is far better solution that hacking/chaining 5 different obscure unix tools to do string manipulation. >you can introduce all sorts of ordering problems when a build runs on a differen…

GNU make is the only variant that matters.

It's not arcane - you just don't want to learn it. You can write your own system and rediscover all the issues and resolve them if you like.

If you started from understanding make, though, you could do a better job than it has done because you don't have to be compatible.

Re: Why Python keeps growing, explained

#428

Post by BerislavLopac »

CE02 wrote: post #169

One thing I’d add to this conversation, though I’m certain it’s already been stated: As many have mentioned, there is a large subset of the user base that uses Python for applied purposes in unrelated fields that couldn’t care less about more granular aspects of optimization. I work as a research assistant for international finance faculty and I would say that compared to the average Hackernews reader, I’m technologi…

It's been said, quite correctly, that Python is the second best language for everything.

I feel that it has recently - like many really mature platforms - become very much like the elephant from that old apocryphal story [0]. It is being used for many different purposes, with very different requirements and needs, with users being so focused on their own use that anything outside that is considered "bloat" and "waste".

[0] https://en.wikipedia.org/wiki/Blind_men_and_an_elephant

Re: Why Python keeps growing, explained

#429

Post by dagw »

slt2021 wrote: post #420
_aavaa_ wrote: post #415

Earlier quoted context omitted.

Guess that'll depend on how much you need the performance and how much code it is. They're comparing numpy (SIMD plus parallelism) with straightforward C code and getting a 2-5x improvement.

I highly doubt that numpy can ever be a bottleneck. In typical python app - there are other things like I/O that consume resources and become bottleneck, before you run into numpy limits and justify rewrite in C.

In my typical python apps, it's 0.1-20 seconds of IO and pre-processing, followed by 30 seconds to 10 hours of number crunching, followed by 0.1-20 seconds of post processing and IO.

Re: Why Python keeps growing, explained

#430

Post by goto11 »

Kwpolska wrote: post #192
pharmakom wrote: post #6

Comparing Python to Java 8 and saying it’s more readable isn’t showing much. And it’s not very portable the second dependencies with native code (which is common since pure Python is too inefficient for many tasks) are used. I think Python is popular for two reasons: - it’s believed to be beginner friendly compared to other languages. I’m not really sure why - maybe the whitespace? - it has an enormous set of librari…

I agree comparing hello world code in Python and Java is a bit pointless. Hello worlds might be much shorter, but at scale, this becomes less relevant. Also, comparing to a language that hates change is unfair, if you compare it to C#, which is improving over time, you'll see the hello world also takes one line (but is 13 characters longer, so Python still wins!)

> if you compare it to C#, which is improving over time, you'll see the hello world also takes one line

Well yes it it does now, since C# 10 or, but in Python is have been a one liner since the beginning 30 years ago, and over the decades it has build a following. And even with recent efforts to cut down on boilerplate, C# still has more cryptic syntax than Python.

I'd argue C# is more maintainable in the long run due to the static typing, but there is no way it is as accessible to beginners.

Post reply on HN