In "What if CPU time is an issue?" we could also mention the nim language (and not only cython) because it compiles (not only) to C and feels like python.
Yes, Python is Slow, and I Don’t Care
121–130 of 206 posts
Re: Yes, Python is Slow, and I Don’t Care
#122The fact that Python is slow isn't its only problem. What I care more about nowadays is wasting my time hunting bugs that could have been avoided by a static type system.
Please tell me, do you write tests? I've learned that it's necessary. I do 100% code coverage and I'm enjoying TDD a lot.
Static types and tests check different things. Tests are for making things function as desired. Types are for making sure they actually connect sensibly where desired. Sometimes you can use them for the other purposes though that often produces ugly tests/types.
Re: Yes, Python is Slow, and I Don’t Care
#123Unless we are talking like circa 1999 I don't think I have heard a complaint yet that Python is slow. I'm curious who or where the author heard that from (not specifically the people themselves but the domain they are in). What I have heard complaints about Python are (and I don't agree with all these points): * Its not statically typed * The python 2/3 compatibility * It has some design flaws: GIL, variable assignin…
Could you elaborate on what are the complaints you've heard about "variable assigning, mutable variables, lambdas"? Just curious.
It unclear if you are introducing a new variable to the scope or mutating an existing one.
# Am I defining foo for the first time or am I mutating
foo = "stuff"
And of course you can't define constants.
IIRC for lambdas its that they can't span multiple lines and I believe they are getting removed (I'm not a python 3 expert)?
Re: Yes, Python is Slow, and I Don’t Care
#124"It doesn't matter than Python is slow, besides we can use compiled libraries to speed it up" "People saying it doesn't matter that Python is slow are deluding themselves and preventing Python from getting faster like JS did" "Python is inherently harder to optimize than JS since it has " "Smalltalk/Lisp/etc are also very dynamic yet are much faster" "The slowness of Python is harming the planet by being inefficient…
> "Python is inherently harder to optimize than JS since it has " Python is not a very dynamic language in the sense that you actually can't change a lot of stuff (and a number of the things you can change just segfault CPython). I think JS is more dynamic, for example. Or Ruby.
These are not my arguments, mind you; I don't know enough to make them.
You've piqued my interest, though: can you give me an example of those things that you can't change or that break CPython?
Re: Yes, Python is Slow, and I Don’t Care
#125Premise: It's more important to be productive than to have fast code.
Conclusion: Use Python.
Is the premise true? For many cases- yes, but it depends. If you are running an application on the cloud and your metric is $/user/year and you have many users then saving some compute resources for each user gets attractive and you don't want to just throw another VM at it.
Is the conclusion true? Garbage collection gives big productivity gains. Other languages have GC. It's not nice to see your Python code die after a few days because you messed up the type passed to a function. Other languages fix that at compile time. Multicore is now. Other languages are built with better multicore awareness.
Re: Yes, Python is Slow, and I Don’t Care
#126Earlier quoted context omitted.
'Dynamic languages' is too often used as a shorthand, or interchangeable with 'scripting language', as here. There are a ton of more relevant language features when it comes to productivity, automatic memory management being the biggest IMHO. Interpreted vs compiled makes a difference too because your code->launch->test cycle can be so fast. But I agree, I'm a huge Python fan and even though I appreciate not having t…
But with a statically typed language, you don't need to go through that code -> launch -> test cycle as often because everything is type-safe.
That falls down because most static languages have "representational types", not "semantic types". Here's a post of mine on the topic:
Re: Yes, Python is Slow, and I Don’t Care
#127Earlier quoted context omitted.
I see this stated as if its a universal fact, but it really true that static types reduce over-all bug density? I myself have found this to not be true, and I have found the same in reading / talking to others. However, if you have found a resource that has data on the contrary, I would find it very interesting to read. https://medium.com/javascript-scene/the-shocking-secret-abou...
A static type system doesn't protect you from choosing the wrong abstraction, and all the bugs that result from it. But if used properly I think it does help.
How? I don't think I've ever gotten a type I wasn't expecting in any of my python code. It's just not a problem for me.
That is, past the first time I run it. I've been known to pass something an x when it wanted a y, but that's a "fail early, fail loud" bug and not an actual problem.
Re: Yes, Python is Slow, and I Don’t Care
#128Earlier quoted context omitted.
Yes but there are no mainstream or production-ready dependently typed languages, so I didn't mention that. But I wouldn't be surprised if dependent typing really is going to be the distant future of programming languages. Perhaps not too distant. I also wouldn't be surprised if Clojure tends to do surprising things in this area with taking Clojure.spec more to the compilation stage; some of the most interesting resea…
> Yes but there are no mainstream or production-ready dependently typed languages, so I didn't mention that. (For a number-type that is limited to eg be between 0.0 and 1.0): Ada? http://www.adahome.com/rm95//rm9x-03-05-07.html
Ada provides ranged types but is not a dependently typed language. So I guess it sort of falls into this particular example, but would not apply to other examples in this arena.
Re: Yes, Python is Slow, and I Don’t Care
#129I was all ready to savage his opinion after reading the headline but I agree looking at my architecture that I designed for the company I work for, CPU isn't the bottleneck. Every time I try to increase performance by multi threading as much as possible, the databases start screaming. On the other hand, the idea that dynamic languages are more productive than static languages are laughable. Statically type languages…
>On the other hand, the idea that dynamic languages are more productive than static languages are laughable. Statically type languages prevent a lot of bugs and allow for a lot of automated provably correct refactorings that simple cannot be done with a statically typed languages. You can't even reliably do a "find usages" of classes using a dynamically typed languag Exactly, I get quick and precise code completion,…
>In Python I need to rescan all of the types into my head until I can understand what the program does.
Couldn't that be solved with sane variable naming conventions and docstrings/documentation?
Re: Yes, Python is Slow, and I Don’t Care
#130Earlier quoted context omitted.
Did you read the section on "Optimizing Python" ?? If so, I'm assuming you read about using CPython to migrate your package/program/module painlessly to C. So given that, can you elaborate on your objection? I'd like to know why you think the article is wrong about optimising your Python to make it fast enough.
"migrate your package/program/module painlessly to C" Do you or anyone on your python using team can use C professionally for things you'll use in production? I work with python everyday on a team that uses python everyday, and I worked professionally in C++ for a >2 years time, and I still wouldn't trust myself to write a reliable/safe C backend to something. And using C++ behind python with something like pybind11…
You should try python-cffi. Using python code as a shared library under C is pretty easy, and calling C from python is pretty easy. The documentation is a bit crappy, but it's alright once you get the hang of it.
I recently used it to prototype a shared library that overrides the `getenv` syscall, with the intent of providing decrypt-on-use environment variables. It's pretty simple, stolen from lua I believe.
https://cffi.readthedocs.io/en/latest/overview.html#embeddin...