4 ms·

I never understand these "dynamic vs. static" threads. All of the comments saying that types are somehow undesirable. Or trying to appear wise and above it al

I never understand these "dynamic vs. static" threads. All of the comments saying that types are somehow undesirable. Or trying to appear wise and above it all with some variant of the middle-ground fallacy. The advantages of a dynamic type system are two-fold: 1. Dynamic typing and a meta-object protocol allow for certain design patterns. Arguably makes it a bit easier to write DSL's. 2. You don't have to spend 500 milliseconds typing the word `string` or `int`. However, in reality: 1. Virtually no one in these threads are actually writing DSL's, or applying any of those design patterns. They're writing line-of-business CRUD apps, and simply don't feel like reading or typing `string` or `int`. 2. Most static languages are getting more sophisticated with type inference, such that you don't have to type `string` or `int` nearly as often (although we can debate whether this actually makes your code more readable or less). So in sum, most people aren't even getting much if any purported advantage, and in exchange they are giving up a slew of compile-time checks that must instead be manually implemented in (unreliable) tests. It's just madness. You don't want to type `string` or `int`. It really is as simple as that.

jiggawatts 5y ago
> You don't want to type `string` or `int`. It really is as simple as that. I prefer to write "string" or "int", but it can be borderline impossible to write the type of a complex query, the kind of thing returned by LINQ or the like. What's the type of a class or struct that has fifty non-optional (not null) fields of various types? Easy! It's just the name of the class or struct. What's the name of the same class after applying the "select" or "project" operator, with one of the fifty or so fields removed? Umm... Okay, next: How about the name of the type that is a projection that removes one arbitrary column based on a dynamic, runtime input? Can your static language express this at all? This is the most basic query operation possible, affecting one column or field, and your fancy static typing has fallen flat on its face. This is not about typing speed. It's about solving trivial problems with fit-for-purpose tools instead of fighting the compiler. This is why SQL is still a thing, and why a lot of people massage data with Python or R instead of C++.
- throwaway889900 5y ago
  Or, you compile your code and the compiler spits out the type it expects for you and you paste it in to fix the error. Simple and no fighting with the compiler needed!
- throw149102 5y ago
  This is definitely the best argument for dynamically typed languages I've seen yet, but I think I have an answer. I've been reading a book on Idris called "Type-Driven Development", and I think that Idris has this exact issue figured out. Instead of developing normally, writing code, then compiling, then testing, then raising a CR, you work with a REPL that helps you fill out parts of the code as you go. So what you can do is just type `> :t what_is_this_type?` where what_is_this_type is a hole for the thing you don't know how to type yet. So with this REPL based development you don't even have to try to figure out the type. So IMHO, it fundamentally comes down to the power of the statically typed language. If you're working with Java, C++, C#, etc, type inference can help a lot but ultimately can't give you everything you want. Precisely because of that dynamic, runtime input. But if you have a functional language, like Haskell, Idris, or Clojure, you actually can precisely type that input and have something reasonable looking come out at the other end.
  - jiggawatts 5y ago
    Precisely. I've been thinking of making a "toy" programming language, and that Idris feature gave me some ideas. I like to use the select/project operator as an example precisely because it is so basic, yet so revealing of the gaps in modern programming languages (static typed or dynamic). It really is very fundamental to not just verification of correctness, but also performance, data security, API surface design, and a whole host of things that are causing a lot of grief for a lot of programmers. The "ORM impedance mismatch" is in no small part caused by this issue. Imagine a not-so-hypothetical scenario of wanting to make a Web API for something like "get cloud virtual machine". A virtual machine might have hundreds of properties! Everything from creation time, licensing mode, SKU, status, etc, etc... So of course, for efficiency, you want the API to only return the relevant columns, right? Currently, there is no way to do this in most programming languages without reams and reams of dynamic typing of some sort, somewhere. One way or another you will be explicitly treating the returned rows as hashtables, arrays of "object", or something. More than likely, you'll have to dynamically generate the SQL/NoSQL query as text. You'll have to write nested loops to handle the rows and columns. Then all of this will have to be repeated on the client side, but likely with different languages. There's a decent chance that the trivial operation of "select {set of columns} from table" will end up executing a hundred megabytes of code in the end-to-end path and take multiple seconds to return a couple of kilobytes of data. It's madness.
olau 5y ago
I think part of what you are not understanding is that it is not the plain ints or the strings, it's the structs or the classes or what have you, that you didn't have to spec out beforehand. With rich but thinly-used data models in those line-of-business CRUD apps, the spec to usage ratio can approach 1:1. With duck typing you just stuff the data in there and pick it out again. I did not get it either until I had a couple of years of Python experience under my belt. And yes, you can do that in something like Java too, I'm sure. It's just not as convenient, and the culture will not tolerate it. And yes, there are downsides. (But there a downsides to the spec'ing too, one of them being proliferation of concepts, increasing the mental load of understanding the system.)
- tintt 5y ago
  That’s a very good point. Also explains why Data Scientists like their dynamic languages, and Embedded engineers prefer static typing.
- StevePerkins 5y ago
  If anyone really believes that an "Order" struct causes more "mental load", compared to passing around a tuple with a bunch of dollar amounts and random-looking strings, then I don't know what to tell them. The exact opposite seems obvious. I've never seen a Python codebase larger than 10,000 lines, that didn't require exhaustive archeology for newcomers to figure out the contracts. I'm sure that the original authors (who are always long gone) had fun, though.
bjourne 5y ago
> It's just madness. You don't want to type `string` or `int`. It really is as simple as that. Correct! I don't want to type it and, more importantly, I don't want to force others reviewing my code to have to read it. One of the very few empirically demonstrated facts about software engineering is that the number of defects is proportional to size of code, usually measured as the number of lines of code. Source: https://softwareengineering.stackexchange.com/questions/185660/is-the-average-number-of-bugs-per-loc-the-same-for-different-programming-languag https://softwareengineering.stackexchange.com/questions/1856... There's a lot of bullshit in software engineering, cargo cults, buzz words, bla bla oriented programming, etc. All with zero empirical evidence. But that the number of bugs per line of code remain roughly the same independent of language has actually been demonstrated. Thus, I pick Python over more verbose statically typed languages.
- watwut 5y ago
  > I don't want to force others reviewing my code to have to read it. Having it written there makes code review easier instead of harder. Because you see information instantly instead of having to guess it.
- arduinomancer 5y ago
  > One of the very few empirically demonstrated facts about software engineering is that the number of defects is proportional to size of code I think you're taking that too literally. It doesn't make sense applied to types. If you have the same piece of code, having types doesn't increase the complexity in any way. Its just more information shown and more validation. By that logic we should all use the shortest variable/function names possible so that we can minimize the length/lines of code
  - bjourne 5y ago
    Of course it makes sense. Researchers have found a positive correlation between code size and number of defects. Type declarations increases code size. > By that logic we should all use the shortest variable/function names possible so that we can minimize the length/lines of code Perhaps we should since there is no research to suggest that short names negatively affect software quality.

jiggawatts 5y ago

> You don't want to type `string` or `int`. It really is as simple as that. I prefer to write "string" or "int", but it can be borderline impossible to write the type of a complex query, the kind of thing returned by LINQ or the like. What's the type of a class or struct that has fifty non-optional (not null) fields of various types? Easy! It's just the name of the class or struct. What's the name of the same class after applying the "select" or "project" operator, with one of the fifty or so fields removed? Umm... Okay, next: How about the name of the type that is a projection that removes one arbitrary column based on a dynamic, runtime input? Can your static language express this at all? This is the most basic query operation possible, affecting one column or field, and your fancy static typing has fallen flat on its face. This is not about typing speed. It's about solving trivial problems with fit-for-purpose tools instead of fighting the compiler. This is why SQL is still a thing, and why a lot of people massage data with Python or R instead of C++.

throwaway889900 5y ago
Or, you compile your code and the compiler spits out the type it expects for you and you paste it in to fix the error. Simple and no fighting with the compiler needed!
throw149102 5y ago
This is definitely the best argument for dynamically typed languages I've seen yet, but I think I have an answer. I've been reading a book on Idris called "Type-Driven Development", and I think that Idris has this exact issue figured out. Instead of developing normally, writing code, then compiling, then testing, then raising a CR, you work with a REPL that helps you fill out parts of the code as you go. So what you can do is just type `> :t what_is_this_type?` where what_is_this_type is a hole for the thing you don't know how to type yet. So with this REPL based development you don't even have to try to figure out the type. So IMHO, it fundamentally comes down to the power of the statically typed language. If you're working with Java, C++, C#, etc, type inference can help a lot but ultimately can't give you everything you want. Precisely because of that dynamic, runtime input. But if you have a functional language, like Haskell, Idris, or Clojure, you actually can precisely type that input and have something reasonable looking come out at the other end.
- jiggawatts 5y ago
  Precisely. I've been thinking of making a "toy" programming language, and that Idris feature gave me some ideas. I like to use the select/project operator as an example precisely because it is so basic, yet so revealing of the gaps in modern programming languages (static typed or dynamic). It really is very fundamental to not just verification of correctness, but also performance, data security, API surface design, and a whole host of things that are causing a lot of grief for a lot of programmers. The "ORM impedance mismatch" is in no small part caused by this issue. Imagine a not-so-hypothetical scenario of wanting to make a Web API for something like "get cloud virtual machine". A virtual machine might have hundreds of properties! Everything from creation time, licensing mode, SKU, status, etc, etc... So of course, for efficiency, you want the API to only return the relevant columns, right? Currently, there is no way to do this in most programming languages without reams and reams of dynamic typing of some sort, somewhere. One way or another you will be explicitly treating the returned rows as hashtables, arrays of "object", or something. More than likely, you'll have to dynamically generate the SQL/NoSQL query as text. You'll have to write nested loops to handle the rows and columns. Then all of this will have to be repeated on the client side, but likely with different languages. There's a decent chance that the trivial operation of "select {set of columns} from table" will end up executing a hundred megabytes of code in the end-to-end path and take multiple seconds to return a couple of kilobytes of data. It's madness.

olau 5y ago

I think part of what you are not understanding is that it is not the plain ints or the strings, it's the structs or the classes or what have you, that you didn't have to spec out beforehand. With rich but thinly-used data models in those line-of-business CRUD apps, the spec to usage ratio can approach 1:1. With duck typing you just stuff the data in there and pick it out again. I did not get it either until I had a couple of years of Python experience under my belt. And yes, you can do that in something like Java too, I'm sure. It's just not as convenient, and the culture will not tolerate it. And yes, there are downsides. (But there a downsides to the spec'ing too, one of them being proliferation of concepts, increasing the mental load of understanding the system.)

tintt 5y ago
That’s a very good point. Also explains why Data Scientists like their dynamic languages, and Embedded engineers prefer static typing.
StevePerkins 5y ago
If anyone really believes that an "Order" struct causes more "mental load", compared to passing around a tuple with a bunch of dollar amounts and random-looking strings, then I don't know what to tell them. The exact opposite seems obvious. I've never seen a Python codebase larger than 10,000 lines, that didn't require exhaustive archeology for newcomers to figure out the contracts. I'm sure that the original authors (who are always long gone) had fun, though.

bjourne 5y ago

> It's just madness. You don't want to type `string` or `int`. It really is as simple as that. Correct! I don't want to type it and, more importantly, I don't want to force others reviewing my code to have to read it. One of the very few empirically demonstrated facts about software engineering is that the number of defects is proportional to size of code, usually measured as the number of lines of code. Source: https://softwareengineering.stackexchange.com/questions/185660/is-the-average-number-of-bugs-per-loc-the-same-for-different-programming-languag https://softwareengineering.stackexchange.com/questions/1856... There's a lot of bullshit in software engineering, cargo cults, buzz words, bla bla oriented programming, etc. All with zero empirical evidence. But that the number of bugs per line of code remain roughly the same independent of language has actually been demonstrated. Thus, I pick Python over more verbose statically typed languages.

watwut 5y ago
> I don't want to force others reviewing my code to have to read it. Having it written there makes code review easier instead of harder. Because you see information instantly instead of having to guess it.
arduinomancer 5y ago
> One of the very few empirically demonstrated facts about software engineering is that the number of defects is proportional to size of code I think you're taking that too literally. It doesn't make sense applied to types. If you have the same piece of code, having types doesn't increase the complexity in any way. Its just more information shown and more validation. By that logic we should all use the shortest variable/function names possible so that we can minimize the length/lines of code
- bjourne 5y ago
  Of course it makes sense. Researchers have found a positive correlation between code size and number of defects. Type declarations increases code size. > By that logic we should all use the shortest variable/function names possible so that we can minimize the length/lines of code Perhaps we should since there is no research to suggest that short names negatively affect software quality.