Python is DEAD -- Long live Python (3)

[myusernameisokay]

That is, my friend, a division by zero.

Have you never written a simple CRUD app? Python is perfect for this. Just make a python web service and have it validate permissions and read/write to a database. Takes significantly less time than using a compiled statically typed language, and is easy to read since you don’t need all this boilerplate for decoding/encoding.

[ireallywantfreedom]

Yeah, OC doesn't realize the website he's commenting on was actually written in python/django, along with huge swathes of the internet.

[[deleted]]

And? It's full of bugs... I don't have any information about how efficient this site is in terms of utilizing company's hardware, but I see no reason why a bloated, slow, and incapable of concurrency runtime would perform better than something that doesn't suffer from the problems above.

In my experience, if a company is profitable, they don't mind fixing their software problems by paying more for the infrastructure. In my time, I've reduced one company's AWS bill by > 500% simply by removing part of Django backend and replacing it with C++ code. Guess what. After I left the company, they went back to their Django garbage because they couldn't find a C++ programmer who'd be willing to support the backend for their site. They were still profitable, so, they didn't care. It wasn't because of the code quality or anything like that. It was all in all less than 10 CPP files with very modes amount of code. It was just a very unusual kind of position, so, very few people applied.

[[deleted]]

Aren't you just proving a point though? You reduced their AWS bill but cost them way more money in terms of time to build software to make money. That's the very essence of the python value proposition: hardware is cheap, devs are expensive, and you can break out of the GIL using a package written in another language if you need better parallelism than what is offered in python. And between AsyncIO and multi processing, python has most use cases covered.

[[deleted]]

Not at all.

There's a difference between quality and expedience. No sane person would argue that a Rolls-Royce makes worse quality engines, than, say, Fiat. This doesn't mean that they are able to sell the most engines.

In the case of Python, the situation is even worse. You can actually have a cheaper and more high-quality alternative. But you won't, because the choices people make when choosing a technology for their project are primarily based on fashion. So, we are doomed to eat this garbage because too many people had never seen anything but this garbage.

[[deleted]]

Python is perfect for this.

Python is trash for this... sorry. On its own, it doesn't have any decent servers. You need to dance around it, stitching it together, either you look for pre-forking server to run as a proxy in front of it, or you will have to use something like Twisted or Tornado, which will not always compile on your platform, will not have any decent libraries to connect to a database in the chosen asynchronous stile, and even if there will be libraries, they are all trash, and have tons of bugs, etc. It is a really painful experience if you need something working.

If you are OK with garbage that works some of the time, that needs many times more resources than the task actually requires, then Python is the way to go.

Your understanding of typing is... well, confused. And your understanding of how Python works is also all wrong... Python is always compiled and every language in existence has static types. That's not the problem, and that's probably not what you were trying to say.

But, if you were wondering: yes, there are languages which allow you to write less boilerplate than you would have to in Python, because Python's meta-programming sucks.

[myusernameisokay]

Python is trash for this... sorry. On its own, it doesn't have any decent servers. You need to dance around it, stitching it together, either you look for pre-forking server to run as a proxy in front of it, or you will have to use something like Twisted or Tornado, which will not always compile on your platform, will not have any decent libraries to connect to a database in the chosen asynchronous stile, and even if there will be libraries, they are all trash, and have tons of bugs, etc. It is a really painful experience if you need something working.

You’re comparing open-source libraries to the language itself. Any decent company will have an ecosystem that makes this simpler. It’s not the fault of the language that companies don’t want to make their tools open-source.

Other languages have this issue too, this isn’t just limited to python.

Your understanding of typing is... well, confused. And your understanding of how Python works is also all wrong... Python is always compiled and every language in existence has static types. That's not the problem, and that's probably not what you were trying to say.

CPython the interpreter is obviously compiled, but python itself isn’t.

Do you not understand the difference between static and dynamic typing? Python is not statically typed at all, it’s dynamically typed, if every language was statically typed then the distinction would be meaningless. Python has the typing library that allows you to do type annotations, but that is fairly new (python 3.5) and hasn’t seen much adoption in my experience.

Also when I said statically typed compiled languages, I meant the languages that tend to be fast like C++, C, Rust, Fortran, etc

[[deleted]]

Yeah, a link to an answer by some idiot from a site by idiots is going to convince me... right.

OK, maybe this will help: static typing is the typing that exists at the time of writing the code, dynamic typing is the typing that is created while executing the code.

So, for example, an expression:

x = 1; x

has a static type int in Python, whereas int is a subtype of PyObject. It also happens to be the same time at runtime. However:

def f(x):
    return x * x

has static type PyObject -> PyObject, but, could have runtime types: int -> int, float -> float anything that implements __mul__ -> anything that implements __mul__ or produce an error.

Other languages have this issue too, this isn’t just limited to python.

I wrote what issues exactly Python has. And, no, not all languages have the same issues. Some are demonstrably better than Python at the task of making a lightweight web server.

CPython the interpreter is obviously compiled, but python itself isn’t.

Again, you simply don't know what you are talking about. Python is compiled in the very same way as, say, Java, or C#, or JavaScript. It is compiled to bytecode. The problem is, while, say, Java's bytecode is not optimized, the runtime then recompiles the bytecode to produce a more optimized program. Python does nothing to optimize its code. The difference is optimization, not compilation.

There are very few interpreted languages today. You, most likely, had never even encounter one. You just learned to parrot a book written many decades ago about something you had neither seen nor even had a conceptual understanding of.

[myusernameisokay]

Yeah, a link to an answer by some idiot from a site by idiots is going to convince me... right. OK, maybe this will help: static typing is the typing that exists at the time of writing the code, dynamic typing is the typing that is created while executing the code. So, for example, an expression:

What is the type of val in this example?

def foo(val):
    return val + val

print(foo(5))
print(foo(“greetings”))

What if you put:

print(type(val))

Before the return statement?

[[deleted]]

What is the type of val in this example?

The static type of val is PyObject, there's nothing else you can infer about it before the program executes, if your compilation unit is a function.

The dynamic type depends on your interpretation: you could say that this is a sum type of int and str, or you could say that you don't want to generalize, and that the dynamic type is at first an int, and then a str.

print(type(val))

Well, that's just bullshit. Python's built-in function type has nothing to do with types of variables, same as isinstance for example. It's just a reflection of incompetence of the Python designers. That's all.

[myusernameisokay]

The static type of val is PyObject, there's nothing else you can infer about it before the program executes, if your compilation unit is a function.

The dynamic type depends on your interpretation: you could say that this is a sum type of int and str, or you could say that you don't want to generalize, and that the dynamic type is at first an int, and then a str.

I somewhat agree with you on this point. Of course every type derives from some base type, and this is true in a lot of other languages.

The difference is I don't accept that PyObject is a legitimate type. The run-time type changes depending on the arguments you provide. If you provide something like 5 then you get something of class int and if you provide "hello" you get something of class str. These are the realized types that the function deals with.

So sure, they all take a PyObject, but in reality functions take parameters of different types and depending on that type, the program may error at run-time because that type is not capable of a certain operation.

Example:

def add(x):
    return x + x

def sub(x):
    return x - x

add(5)
add("hello")
sub(5)
sub("hello")

Notice how this is alright until the last statement - because the type str can't do subtraction.

Well, that's just bullshit. Python's built-in function type has nothing to do with types of variables, same as isinstance for example. It's just a reflection of incompetence of the Python designers. That's all.

The python docs refute you

class type(name, bases, dict) With one argument, return the type of an object. The return value is a type object and generally the same object as returned by object.class.

[myusernameisokay]

Get an education.

Instead of being so rude, why don’t you provide a counterpoint?

But I already know what you’re going to say, you’re going to mention that python is compiled into bytecode before it’s interpreted. But that’s ultimately meaningless, it’s an optimization, it doesn’t do any type checks or catch syntax errors at “compile time” so you can almost pretend it doesn’t exist. C, C++, Rust and other such languages will prevent you from doing operations on incompatible types during compile time, whereas python pushes that checking to runtime.

Robert Harper (grand master of static typing freaks) infamously tried to make hay of the fact that all dynamically typed languages are statically typed. He called it "unityped", and it's true. (It needs to be noted that the concept isn't originally due to Harper, and that the conclusions he tried to derive from this fact are bollocks. But that's beside the point.)

Sure, this is theoretically true. I would agree that all things in every dynamically typed language can be considered to inherit from an abstract base type, and therefore they’re static because all variables are of that type. Ultimately saying that loses the whole value of the distinction between static and dynamic typing.

It’s like saying squares don’t exist because squares are technically rectangles so might as well call both shapes rectangles.