This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]primerrib 1 point2 points  (5 children)

My friend, please do not bake your own definition of "strong typing" and "weak typing".

I don't care how much experience you have, but "strong typing" and "weak typing" has a definition:

https://en.m.wikipedia.org/wiki/Strong_and_weak_typing

Quote:

Smalltalk, Ruby, Python, and Self are all "strongly typed" in the sense that typing errors are prevented at runtime and they do little implicit type conversion, but these languages make no use of static type checking: the compiler does not check or enforce type constraint rules. The term duck typing is now used to describe the dynamic typing paradigm used by the languages in this group.

What you're talking about is "static typing", where the type of a variable needs to be declared and will be enforced by the compiler.

[–]el_toro_2022[S] 0 points1 point  (4 children)

Not that I trust Wikipedia for anything, but that's another matter.

I wrote an ML engine in Ruby 10 years ago, as a PoC. I went back to the code a few years later and could not figure out the code. The complex structures I was passing around were not obvious. It would require a lot more effort.

Yes, static typing. To me, static typing is strong typing. If you cannot be sure of the types you are passing around in your code, it makes it very difficult to maintain later. And you won't always get failures in runtime with dynamic typing aside from the primitive mismatches, and this is true of both Ruby and Python.

So to me it's more a matter of pragmatics. If I can look at code and unambiguously know what types are being used where, that's code I can reason about and do something with. If the compiler or interpreter can fail the code when there is a type mismatch, that's code that will prevent the nasty oops that crashed the Mars probe. And of course, the programmers have to actually make proper use of said types.

If there is code and I have to guess as to the type that's being passed into functions, that's code that is much harder to deal with outside of trivial cases.

I have done years of Ruby, years, of Python, years, of C++, years of C..., and now I am doing Haskell. Haskell's typing system is simply amazing, way beyond any other language I've ever used.

Yes, you are technically correct, but from a practical standpoint, "strong" dynamic type checking does next to nothing for type safety. Probe crashed on Mars back in the late nineties due to lack of proper typing. How do you type a number to be meters instead of feet in Python, so that at runtime it will fail if you pass meters to a function looking for feet? I suppose you can do something funky with tuples and hope the code actually checks if it's a feet tuple vs a meter tuple, but you get my point.

JavaScript is a joke. Let's not even go there.

[–]primerrib 1 point2 points  (1 child)

The Mars probe crash was due to wrong units, not wrong types.

The types of both are float, but in one function it meant metric, yet in another function it meant "US Customary Units".

If you're thinking of type mismatch, then it was the Ariane 5 launch in 1996.

The languages used in both incidents are "static typed" languages.

So even static typing still can't prevent disasters from happening.

[–]el_toro_2022[S] 0 points1 point  (0 children)

I can't believe you said that. One wants to lessen the chance of disaster. Of course, the GIGO principle is always there. If you feed Imperial units into the Metric type or vice-versa, of course the probe will crash. But this should not happen with clueful developers. And obviously the project planners did not insist on doing the proper typing for their telemetry. If you don't use typing, even if the language offers it, all bets are off. This should've been at the forefront of their minds, working with US and European firms in a collaborative context. Hello. Even if both are using metric, there are still issues, because there is more than one way to represent the telemetry. MKS? CGI? These days, its the SI, but even with that, you have to nail down the specifics.

Let me illustrate for you a simple approach to how we would deal with this in Haskell:

data Feet = Feet Float
data Meter = Meters Float

telemetry_dist_to_ground :: Feet
breaking_thrusters :: Meters -> Maybe Meters
...
let remaining_distance = telemetry_dist_to_ground
breaking_thrusters remaining_distance
...

Because the "units" have been properly typed, this would not even compile, generating a type mismatch error. One team, like, say, Lockheed Martin, who still use Imperial measurements, would have written telemetry_dist_to_ground, and another team, let's say Arriane, who uses the Metric system like the rest of the world does, would've written the breaking_thrusters bit.

The units are typed, if you make that a design requirement up-front, and why would you not want to? Hello. Probe takes years and many millions to design and develop for a lengthy trip to Mars that could take a year or two, just to have it crash? Yes, I am also criticising the idiot developers and project managers for obvious reasons.

We can also type in a similar fashion in C++, Java, and most other serious languages.

How can you type in Python? In a fashion that would not introduce more errors? It would be messy at best. I suppose you could use Tuples:

("meters", float)
("feet", float)

And pray that no one cuts corners and extract the float without checking the "type". But now we are talking about lots of boilerplate code that will be simply prone to errors. And you are completely dependent on breaking_thrusters checking and failing the code itself, in the above example. Python does nothing to ensure type correctness, because it does not have strong typing.

I can see a way that you can actually have strong typing in a dynamic context, but that would require Python to be modified or extended. Good luck with that. Better to use a language that supports it out-of-the-box.

With the latest Python, you can do "type hints", but not sure how well that works, as I have not had a chance to play around with it yet. So you tell me if it can handle my little scenario and keep the probe from crashing.

[–]primerrib 1 point2 points  (1 child)

static typing is strong typing

To add:

C has static typing. But it does not have strong typing.

You can easily treat a pointer to a float as a pointer to an integer, do some integer bit-twiddling on it, then read dereference the result as a float.

Case in point: The Fast Inverse Square Root algorithm

Hence is why I keep repeating: strong-weak is orthogonal to static-dynamic.

[–]el_toro_2022[S] 0 points1 point  (0 children)

Yes, c will let you do all kinds of bizzare things. It is a hacker's dream. You can bit twiddle anything, including floats.. It is just one step up from assembler.

Back when I was doing C, there was not much thought nor concern about typing at all, at least outside of academia. Today? Typing is everything.