Live data from Hacker News

Python Shouldn't Be the Top Programming Language

itprotoday.com

31–40 of 41 posts

Re: Python Shouldn't Be the Top Programming Language

#32
post #18

Earlier quoted context omitted.

It depends on what "graduate" means (I note your "scare quotes"). For some people, lexical styles matter a lot and it is easier to answer this question with that kind of constraint. While its ecosystem is surely much smaller than even Julia's, Nim [1] has a lot of the concise, lexical feel of Python, but semantics more like Modula3/Ada and with Lisp-like syntax macros/metaprogramming to fill in other gaps. Another po…

Python has PyPi and numba. PyPi is good for branchy things like RDF triple stores, business rules engines, etc. CPython (and most other interpreters) has the big problem of the global interpreter lock which prevents it from taking advantage of threads... And that's a problem in a world where (1) 8-core laptops are common, (2) much bigger machines can be found in the server room and (3) many workloads can be paralleli…

Cython lets you do `with nogil`. That said, often processes with communication are enough to leverage multi-core with no global interpreter lock (GIL). CPython's pickling junk for its multiprocessing library can add a lot of overhead to that, though. A simpler pure binary version of multiprocessing could lower that overhead enough to make multiprocessing competitive with multithread unless inputs/outputs are really big (in which case tossing them in files and passing around pathnames is a not crazy fallback...). (EDIT: In the Linux kernel processes and threads are both just created by a system call named "clone" with various sharing flags. Threads are just processes with very unsafe settings - settings that many prog.langs think they can "tame well enough".)

Re: Python Shouldn't Be the Top Programming Language

#33
post #29

I need this to be satire or bot-generated. 1. Python Is Not Fast It's fast enough and "fast" is relative 2. Python's Syntax Is Too Rigid WTF??? 3. Python Provides a Limited Programming Experience I'm cracking up at this point. 4. Nothing Really Big Has Been Written in Python Crying laughing at my keyboard. Django, NumPy, just to start with " you'd think someone would have done something more interesting with it by no…

Yeah, it has to be a joke right? Or this is a rather Stunning Dunning-Kruger case. I'll add to Django and NumPy that Python is a dominant presence in Machine Learning (pytorch for example) as another example of "something more interesting" and something "big".

Re: Python Shouldn't Be the Top Programming Language

#34
post #10

Earlier quoted context omitted.

In the ‘00s I found a python/C combination very effective. All control in python, compute in C and the class mechanism easily tied things together. I would recommend this for any new heavy cpu development as the needs for each portion are so different.

Right, that's one of the architectures for complex programs: use a scripting language for parts and a systems language for other parts. Video games are a great example. You'd like a level designer to be able to edit scripts that control arbitrary things about the game play, but you also need a performance and GFX pro to program other parts.

The way I hear it frequently is: declarative shell, imperative core.

Re: Python Shouldn't Be the Top Programming Language

#35
post #29

I need this to be satire or bot-generated. 1. Python Is Not Fast It's fast enough and "fast" is relative 2. Python's Syntax Is Too Rigid WTF??? 3. Python Provides a Limited Programming Experience I'm cracking up at this point. 4. Nothing Really Big Has Been Written in Python Crying laughing at my keyboard. Django, NumPy, just to start with " you'd think someone would have done something more interesting with it by no…

It would be a decent strategy if it were bot generated. Look at all the comments it has generated.

Re: Python Shouldn't Be the Top Programming Language

#37
post #11

Earlier quoted context omitted.

Aside from significant whitespace (which I suppose takes a little getting used to), is there anything that marks out Python's syntax as particularly rigid compared to other languages? I'm struggling to understand what the author is trying to argue here.

> Aside from significant whitespace (which I suppose takes a little getting used to), If Python's whitespace takes getting used to, then you're probably poorly formatting your code to begin with.

One thing I do find mildly annoying about the whitespace is that you can't jump to the end of a block with e.g. % in Vi (goes to the matching bracket). Not a huge deal but something I notice.

Re: Python Shouldn't Be the Top Programming Language

#38
post #16

2. and 3. sound like advantages to me. 1. seems straightforward, it would be better if a language was faster. 4. is debatable, most programs are not big, so most programmers shouldn't need to use a programming language better suited for big programs, as long as it provides other advantages, if they are not going to build a big program.

[deleted]

Re: Python Shouldn't Be the Top Programming Language

#39
Seen the same argument a decade ago over PHP for the same reasons a) PHP wasn't professional and enterprise ready, b) PHP cannot be taken seriously because it didn't have "this feature or that feature", and now look where we are. We at version 8 and PHP has still stood its ground in the face of how many other languages? Python is where PHP was a decade ago in relation to the points being argued over, and I believe Python will evolve enough to maintain its top place in years to come. And the reason for that is two points. First the huge community that underpins Python and secondly the continued development of the large library or module base it enjoys. And it has been said before. Each language is a tool and you apply the tool to the appropriate job best suited.

Re: Python Shouldn't Be the Top Programming Language

#40
Someone writing an article in 2022 about Python's speed, and only citing articles from 2020 is not being honest about Python's speed. There were major speed improvements in Python 3.8, which was quite new then -- the linked article was not specific about which subversion of Python it was using, so we don't really know what the comparison was. In addition: The article that actually compared the speeds of the languages did a really bad implementation of a speed test in Python. The time library in Python includes a function for performance testing, which wasn't used, so much of the speed difference could well be due to using the wrong resolution clock. Also, if you're doing numerical calculations for speed, you should be using numpy. So, yes, if you tie Python's ankles together, and time it using an analog clock on the wall, it will not post a faster time than an NCAA Division I sprinter at a track meet. Thanks, that's helpful.
Post reply on HN