Specs/contracts are cool but ultimately don't afford the same kind of descriptive and expressive power that a static type system does.
> static types in most languages[2] don't reduce this burden much: there isn't an alternative to thorough testing.
However, there definitely is a burden about how much testing you have to write. I generally don't want to have to test every branch of my program to make sure a string doesn't slip through where an int should be or that variables are initialized and not null, etc.
While I personally prefer certain statically typed languages over dynamic ones for new projects, In practice, for small to medium sized projects, runtime type errors is in my opinion much less of an issue as some people make it out to be. Except for null exceptions they rarely make it into production and if, are easy to track down and fix.
Interestingly, a lot of the people I have seen constantly running into type problems in say Python, are the ones coming from statically typed languages that keep insisting doing thing the way they are used to instead of embracing the duck.
"If you drive carefully enough, a car without seatbelts shouldn't be a problem!"
The correct completion to this sentence is "irrelevant.", because that's not what anyone is proposing.
The fact is, behavioral tests catch a lot of type errors even without intending to, and more to the point, if you test all the behavior you care about, then you don't care if there are type errors, because they only occur in situations where you don't care.
f = fn
{:ok, message} -> "It worked #{message}"
{:eror, message} -> "There was an error #{message}"
end
iex(2)> f.({:ok, "yay"})
"It worked yay"
iex(3)> f.({:error, "oh no"})
** (FunctionClauseError) no function clause matching in :erl_eval."-inside-an-interpreted-fun-"/1
Contrast with Scala, where using Either (which can be Left or Right):
def f(x: Either[String, String]) = x match {
case Right(x) => s"It worked $x"
case Left(x) => s"There was an error $x"
}
scala> def f(x: Either[String, String]) = x match {
| case Right(x) => s"It worked $x"
| }
^
warning: match may not be exhaustive.
It would fail on the following input: Left(_)
scala> sealed trait Status
| case object Ok extends Status
| case object Error extends Status
trait Status
object Ok
object Error
scala> def f2(x: (Status, String)) = x match {
| case (Ok, msg: String) => s"It worked $msg"
| case (Error, msg: String) => s"There was an error $msg"
| }
def f2(x: (Status, String)): String
scala> def f2(x: (Status, String)) = x match {
| case (Ok, msg: String) => s"It worked $msg"
| }
^
warning: match may not be exhaustive.
It would fail on the following input: (Error, _)
def f2(x: (Status, String)): String
scala> def f2(x: (Status, String)) = x match {
| case (Ok, msg: String) => s"It worked $msg"
| case (Eror, msg: String) => s"There was an error $msg"
| }
case (Eror, msg: String) => s"There was an error $msg"
^
On line 3: error: not found: value Eror
If I test all the situations I care about, the one situation I thought I didn't care about is going to fuck me in production.
Not to say I haven't had benefits from catching type errors but generally not as great as those I have from having an automated GUI test running.
I don't think that's a reasonable assumption at all. Even if, as you assert, the average person doesn't understand that types exist in dynamically-typed languages, I don't think that means I have to conform to common misconceptions.
> Specs/contracts are cool but ultimately don't afford the same kind of descriptive and expressive power that a static type system does.
True, but not what I was talking about.
Could you explain what descriptive and expressive power is missing here?
class Square(Rectangle):
def __init__(self, side_length):
self.side_length = side_length
@property
def height(self):
return self.side_length
@property
def width(self):
return self.side_lengthtldr: i haven't seen a runtime typechecker that handles generics and function types in a satisfactory manner.
i've used various Python libraries for runtime type-checking (based on `typing` annotations) like `typeguard`. and they work okay for simple types, but suck for anything involving generics and function types. checking if something is a `List[int]` every time it's passed as a parameter is too expensive, because you have to go through the whole list (and you're out of luck if it's an Iterator[int] - can't traverse that without exhausting it). runtime typecheckers don't have enough information to check if something is a valid `CustomList[int]`. and they have no way of checking if e.g. a function (passed as a parameter) is actually a `str -> int`, at best you'll find out when you call it.
and runtime checkers, at least the ones i've used, often end up requiring more annotations than i'd have to write in a type-inferred language. it might be possible to work around that to some degree, but I think that's a fundamental limitation – unlike a static checker, they only have info about code that already ran. so you'll have to annotate code like this:
f xs = cons 'a' xs
Let's just stop right there, since it's immediately clear you aren't answering the question I asked. You're talking about type checking, not descriptive and expressive power.
The topic is whether dynamic types are suitable for domain modeling, not whether dynamic types provide static type checking. We all agree that dynamic types don't provide static type checking.
Again, this is needlessly uncharitable as to what people mean when they talk about type systems, which is obviously about the capabilities of defining new types for program analysis, not that the runtime has an internal conception of types.
> Could you explain what descriptive and expressive power is missing here?
Sure! Looking at this, I have no idea what the size of side_length is, whether it's possible for it to be negative, or whether it's possible it to be null.
Of course, unless you're writing purely square based software, most domains are more complex than this. But I still think it's pretty helpful to know the properties of the parameters being passed to build your square are!
> Again, this is needlessly uncharitable as to what people mean when they talk about type systems, which is obviously about the capabilities of defining new types for program analysis, not that the runtime has an internal conception of types.
There is nothing "internal" about the example I gave. That's valid Python code that creates a type.
My definition (which happens to be the actual definition of the word) charitably assumes that people know dynamic type systems exist, so I don't think you can really accuse me of being uncharitable. If anything I'm being too charitable, as evidenced by this conversation.
> Sure! Looking at this, I have no idea what the size of side_length is, whether it's possible for it to be negative, or whether it's possible it to be null.
> Of course, unless you're writing purely square based software, most domains are more complex than this. But I still think it's pretty helpful to know the properties of the parameters being passed to build your square are!
Do you really not know whether side_length can be negative or null? Or are you just saying that to be argumentative? If we're pretending we don't know obvious things, why not just go all the way and pretend we don't know that side_length is a number?
As for not knowing the size: why would you want to have to know the size? The fact that this square will work with any numeric type is a feature, not a bug.
Now, consider this (disclaimer: my C++ is rusty, and I didn't syntax check this):
class Square: Rectangle {
private:
double sideLength;
public:
Square(double sideLength) {
this.sideLength = sideLength;
}
}
1. The size of sideLength. Well, yes, this example does tell you what size it is. Which is rather annoying, since now you have to cast if you want to pass in an integer, and you might overflow your bounds. This is an annoyance, not a feature.[1]
2. We know that sideLength can't be negative because we know what squares are. The type doesn't enforce that. You could enforce that by using unsigned int, but then you can't handle decimals. And in either case, you can't use very very large numbers. I haven't worked in a static typed codebase which has an unsigned BigDecimal type, have you?[1]
3. We know that sideLength can't be null because we know what squares are. The type system technically also tells us that, but the type system telling us what we already know isn't particularly useful.
[1] Haskell's numeric type can actually handle this much more cleanly than C++, as I mentioned upthread. But in typical Haskell, you'd probably just let the types be implicit in a lot of cases.
However, there definitely is a burden about how much
testing you have to write. I generally don't want to
have to test every branch of my program to make sure
a string doesn't slip through where an int should be
or that variables are initialized and not null, etc.
I've been writing Ruby full-time for about six years (including one of the largest Rails apps in the world) and I don't find this particular aspect of Ruby to be a problem whatsoever relative to statically-typed language.
Ruby is famously easy to write tests for. Creating mocks in a dynamic language is such a breeze. There are plenty of problems with Ruby but an increased test suite burden is NOT one of them. "Confident Ruby" by Avdi Grimm is a great read in this vein; not about testing specifically but writing confident Ruby code in general.
Part of it is simple, human-friendly code hygiene. Give your arguments descriptive names and use keyword params when possible. If you have a method:
foo(user_name:, height_cm:)
foo(user_name: 157, height_cm: "Smith")
Of course, I do get type errors all the time in Ruby, but that's when I'm parsing JSON or something and that's generally not something static typing's gonna help you with anyway.
Now... there ARE places where I miss strong typing in Ruby.
One, I miss having extremely intelligent IDEs like you can have with Java or C#. I absolutely loved Visual Studio and Resharper in the C# world. The amount of reasoning it can do about your code and the assistance it can give you is absolutely bonkers.
Two, obviously, there is a price in runtime execution speed and RAM usage to be paid for dynamic typing. I don't find raw execution speed to be much of a bottleneck in a Ruby app because Postgres/Redis/etc are doing all my heavy lifting anyway. RAM usage and app startup times with large applications is more of a real-world issue.
First, if you're writing any kind of big code, than somewhere, in your code base, someone else is writing a code where the user name is spelled `username`. Or `user`. You don't have to be "asleep at the wheel" to not remember, or not know, which is which. So you're going to type the wrong one (not necessarily on purpose), and you'll get a runtime error. Not that bad, sure, but you'll get it.
Also, at some point, you'll realize that a string is not the ideal way to represent a user name [1], and some of the functions that deal with users are going to start returning a Struct %User{first_name: ..., middle_name: ....}. Or will it be a Map %{"first_name" => ...} ? And surely you're going to track all the calls of `foo` to fix them. And all the calls of all the calls of `foo`, because, who knows ? And suddenly you're doing the mental job of a static type checker. Surely you're not "asleep at the wheel" anymore, because you're doing the work of the wheel by manipulating the gears by hand.
Bottom line: I'll gladly admit that I'm too old and stupid to do that anymore. I had typechecking in the 90s. Give it back.
[1]: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
So you're going to type the wrong one (not
necessarily on purpose), and you'll get a runtime
error. Not that bad, sure, but you'll get it.
Now, it's certainly true that in a static language, your compiler would catch this for you. In a decent IDE it would be pointed out to you while you type.
However, static or dynamic, you're going to be writing tests anyway, so I can't view this as some sort of increased burden when it comes to writing tests.
Also, at some point, you'll realize that a string is not the
ideal way to represent a user name [1]
I don't think your examples are realistic, at all, though.
1. If you replace `User#first_name` and `User#last_name` with `User#name` (which returns a `Name` object) your test suite is going to blow up all over the place every time you call the deleted `User#first_name` or `User#last_name` methods anyway. And now you have a list of places where you need to fix your code.
2. But, what if you update the internal structure of `Name` over time? Some of the above applies. But also callers of `Name` shouldn't know too much about `Name` anyway - it should be providing some kind of `Name#display_name` or whatever function that handles all of the complexity and returns a dang string anyway.
Everything I've written here presumes the existence of a test suite, of course. Which of course takes time to write and maintain. But any nontrivial project needs one anyway regardless of language or type paradigm, right?
Bottom line: I'll gladly admit that I'm too old and
stupid to do that anymore. I had typechecking in
the 90s. Give it back.
I miss static types when I'm writing code. I want my IDE to tell me the types and type signatures when I type, and draw a little squiggly line under my code when I get it wrong. In Ruby, I wind up having 10 different files open at a time in my text editor so I can see what various methods are expecting.
This is mitigated somewhat by simply bashing out a lot of my code in irb/pry directly, since pry's `show-source` can at least tell me stuff.
Really? You're going to go with "most languages implement static typing"?
That seems like a bold statement.
What exactly dialyzer type checking lacks compared to static type systems?