> there is no question that type safety matters for building and maintaining large-scale distributed systems in the enterprise. Some of the largest-scale enterprise distributed systems, as in, at the telecoms level, are written in erlang, which is dynamically typed, and highly reliable.
Aren't Erlang variables immutable by default? I find that makes a huge difference to the reliability of a program.
All the things I hate about Python
81–87 of 87 posts
Re: All the things I hate about Python
#82Python is the worst programming language, except for all the others I tried (Fortran, C++, Java, Scala, Clojure, PHP, Ruby, Mathematica, IDL). But seriously, the points raised by the author are valid. However despite this Python is still a pleasure to use. In addition the author fails to mention some newer things, which can help with some of the problems Python has: 1. Python Type annotations https://docs.python.org/…
Also there are very few packages actually using Numba. It seems that more people like to talk about possibly using it than actually use it.
Re: All the things I hate about Python
#83Earlier quoted context omitted.
OK, Wikipedia it is. Wikipedia lists C’s typing discipline as “Static, weak, manifest, nominal“, and Python’s as “ Duck, dynamic, strong since version 3.5: Gradual[4]”. > I’m not sure why evidence that “strongly typed” python in practice suffers from all sorts of typing errors that “weakly typed” C/C++ avoids is not relevant to your point. > I also don’t understand why you dislike the string examples, which explains…
There are examples of string operators two comments up. Those are the examples I’m referring to. To any readers that made it this far, and are hoping for something precise, here is a minimally useful definition of “strongly typed”. I’ve never heard of a broader definition of “strongly typed”: The language’s type system must be embedable in a lattice, and at runtime, it is guaranteed that functions aren’t passing the…
In C++, the only thing passed around at runtime is void* . The pointer is then used as a concrete type without any explicit downcast.
Any conversation about strong typing should not involve the word "static". Nothing about strong typing is "static". It is entirely a runtime concept. Functions potentially having multiple return types is entirely an issue of static typing. Not strong typing.
This is obvious because you can annootate python code with the type information. This makes it strongly typed, but not statically typed, even though it makes all unions compile time defined.
In other words, if I take python with type annotations (which is statically typed), and remove the annotations, you claim this would make the language weakly typed, but this makes no sense. There would be no difference between strength and dynamicness.
A better definition might be that a language is weakly typed of it allows transformation from type a to b, where a and b are unrelated (ie neither inherits from the other), without a call to a constructor. Python does not meet this definition, the only way to cast is via a constructor call.
C and c++ do not, void* allows arbitrary transforms. Java will throw a classcastexception, but can only do so at runtime, bit will do so at the bad cast.
C and c++ will keep chugging until the miscast object is misused. That's weak typing.
Re: All the things I hate about Python
#84> there is no question that type safety matters for building and maintaining large-scale distributed systems in the enterprise. Some of the largest-scale enterprise distributed systems, as in, at the telecoms level, are written in erlang, which is dynamically typed, and highly reliable.
Aren't Erlang variables immutable by default? I find that makes a huge difference to the reliability of a program.
All Erlang variables are immutable; it's not just a default.
Re: All the things I hate about Python
#85> However, Python does not have a real privacy model. > This is unsettling if you’re coming from a Java or C/C++ world and are expecting access modifiers It's unsettling to a lot of people, but so what? I still don't see a solid use case for where member access (not "privacy") is a good idea. Python is one of the only languages to get access modifiers right (convention), imo and I don't even like Python. You could im…
The author makes a lot of strong statements based on their opinions. I wrote a bit about their dynamic/weak typing gaffe in another top-level comment. > lambda closure Just FYI (not intended to be mean or anything), in formal PL theory this phrasing doesn't make sense. A closure is the pairing of an anonymous function (a "lambda") with an environment. Python's "lambda" is really just a lambda --- it is not a closure.…
Re: All the things I hate about Python
#861. Significant whitespace. If I had a dollar for every time a bug was introduced in Python code due to incorrect indentation during code refactoring, I would retire already.
Re: All the things I hate about Python
#87Earlier quoted context omitted.
The idea is to create a lambda that's sole purpose is to act as a closure for member access restriction. I'm not sure how that could be misinterpreted, but here's your prize.
I guess my point was that you should have just said "closure" instead of "lambda closure", since that phrasing doesn't make any sense in a formal context. Lambdas and closures are different things entirely. I really wasn't trying to be patronizing or anything; I was just trying to offer information in case you found it interesting, but I guess I missed the mark there. My apologies.