9 ms·

People who like static typing seem to really like static typing. I'm honestly not convinced it helps that much. And it seems to cost a lot to me. I like datab

by GlennS 6y ago

People who like static typing seem to really like static typing. I'm honestly not convinced it helps that much. And it seems to cost a lot to me. I like database and API schemas though. And I like clojure.spec and function preconditions a lot.

nafey 6y ago
I think it gives people a sense of satisfaction in modeling real world in the relations between classes. The assertion seems to be that if to solve a problem it has to be correctly modelled into the type system of the language. Once the modelling is done correctly solution will arise by itself. On the other end people who prefer weakly typed languages see problems as primarily that of data transformation. For example from HTML Form to Http Request to SQL Db to CSV File and so on. Both approaches are differentiated by the perspective on the problem.
- quonn 6y ago
  But I rarely use classes in TypeScript. I do think of things as data transformations but the types certainly help a lot.
- protonfish 6y ago
  Please don't use weak/strong to denote type systems. Those terms are highly subjective and even non-technical people would quickly form an opinion about which is better. (Strong is good, weak is bad.) Static/dynamic is more accurate and less opinionated terminology.
  - albntomat0 6y ago
    They are not the same, at least according to the definitions I'm familiar with. Static/dynamic is whether type checking is done at compile time or run type. Strong/weak is how flexible the language is with type conversion. Another explanation: https://en.hexlet.io/courses/intro_to_programming/lessons/types/theory_unit https://en.hexlet.io/courses/intro_to_programming/lessons/ty...
    - nafey 6y ago
      Are these dimensions orthogonal though? For example is there any Strongly typed dynamic language?
      - teddyh 6y ago
        I think Python is mentioned as the usual example.
      - elbear 6y ago
        Python is considered strongly typed, but usually it's placed in opposition with PHP or JavaScript. That's why I don't understand why the previous poster used strongly typed. The conversation was about static and dynamic programming languages.
      - rowanG077 6y ago
        Yes. Completely orthogonal. Strongly typed dynamic: Python Weakly typed dynamic: Javascript Strongly typed static: Haskell Weakly typed static: C
    - JAlexoid 6y ago
      Static vs dynamic is not for type checking, it's about conversion. As in: Static typing - 1 == "1" is false (Python style, integer isn't converted to string for comparison) Dynamic typing - 1 == "1" is true (PHP style, integer or string may be converted)
      - albntomat0 6y ago
        Where are you getting your definitions from? What you posted is what I understand to be weak vs strong.
        JAlexoid 6y ago
        Barbara Liskov defines strong typing as a compiler feature that prevents wrong type usage. Liskov, B; Zilles, S (1974). "Programming with abstract data types". http://web.cs.iastate.edu/~hridesh/teaching/362/07/01/papers/p50-liskov.pdf http://web.cs.iastate.edu/~hridesh/teaching/362/07/01/papers...
  - deleted 6y ago
    [deleted]
pantaloony 6y ago
I don’t get the cost claims. The time it takes to note which type I intend something to be is mostly either so low that I recover it via improved hints and such very quickly, or larger but only because I’m documenting something complex enough that I should have documented it anyway, whether or not I was using static types, because it’ll be hell for other people or future-me to figure out otherwise. It seems like a large time savings to me—throw in faster and more confident refactoring and stuff like that, and it’s not even close. I just don’t get how people are working that it represents a time cost rather than a large time savings. I don’t mean that as a dig, I just mean I genuinely don’t know what that must look like. And I’ve written a lot more code in dynamic languages, and got my start there, so it’s not like I “grew up” writing Java or something like that.
- GlennS 6y ago
  I would like to be able to explain the cost part better. It may just be personal bias of course. 1. There's no guarantee the correct theoretical model of your program fits the type system of your programming language. 2. Sometimes there are multiple correct models for different purposes in the same program, similar to how sometimes you need multiple views onto the same database tables. 3. Sometimes you just need the ability to bodge things.
  - wtetzner 6y ago
    > 2. Sometimes there are multiple correct models for different purposes in the same program, similar to how sometimes you need multiple views onto the same database tables. Just wanted to point out that even though you can have multiple views or your database tables, they all still adhere to the same type system.
    - GlennS 6y ago
      I guess it's a problem that can be overcome with type inference then? (I don't have to declare types on queries, updates, or views, just on the base tables.)
- simiones 6y ago
wccrawford 6y ago
It depends on the situation. I've had code that absolutely benefited from static types and it helped me find bugs before they happened. But my current job has very, very little that would benefit from static typing. Adding it into the mix would slow us down, both literally and figuratively.
- albntomat0 6y ago
  > But my current job has very, very little that would benefit from static typing Would you mind expanding on this? I'd be interested in what processes you have and if you use any additional tooling. Thanks!
  - wccrawford 6y ago
    Most of what we do is just data input and data display. And most of that is text. There aren't really any calculations or anything, beyond some simple sizing of UI stuff. For database stuff, an ORM with some validation rules is generally enough, and couldn't be replaced with static typing anyhow. For anything that absolutely has to be a certain kind of data, there are things built into dynamic languages to check the type of something, and you just call it as needed on a case-by-case basis.
pixelrevision 6y ago
Clojure spec seems like the way to go. I really like that it defines what should be going in and out while leaving it really easy to merge incoming data without having to write a bunch of extra code.
- deleted 6y ago
  [deleted]
orangecat 6y ago
In my experience both the benefits and costs of static typing are overstated. It doesn't mean that your code works if it compiles, and it doesn't mean that you can get rid of half your tests. But it's great for refactoring, and it's a useful form of documentation that can't lie, unlike comments. And if you're using a reasonable language it's not much additional work to add types; often with type inference it's zero work.
nicoburns 6y ago
I hated statix typing until I used Rust. Rust has Sum types (super powered enums), which provide what I was missing from dynamically typed langauges in languages like Java, C#, etc: namely the ability to have an "or" type (e.g. this is an integer or a string, and I want to be able to branch on that at runtime). That, plus type inference makes the static typing pretty painless.
- the_af 6y ago
  Agreed. Do note that many other languages before Rust do provide good static typing with the niceties you'd expect (and that are often missing from Java), such as type inference, sum types, etc. Some examples include, but are not limited to, Scala, Haskell, the ML family of languages, etc.
- Multicomp 6y ago
  Could not agree more. That's why I'm going to Rust next once done with my current F# project - I want to have experience with both JIT and AOT languages that support sum types and Option / Discriminated Unions. These data types are much more powerful than the fancy arrays that wowed me back in the day :)
wolfadex 6y ago
For me it depends on the style of static types. I do find Java or C#'s static types to be helpful, but also time consuming. Elm or Haskell on the other hand don't force me to write out the static types while still giving me the benefits of them. There's also the case that I find the type systems of Rust, Elm, etc to be much more helpful than the type systems of C++ or Sorbet (type system for Ruby).

by GlennS 6y ago

nafey 6y ago

I think it gives people a sense of satisfaction in modeling real world in the relations between classes. The assertion seems to be that if to solve a problem it has to be correctly modelled into the type system of the language. Once the modelling is done correctly solution will arise by itself. On the other end people who prefer weakly typed languages see problems as primarily that of data transformation. For example from HTML Form to Http Request to SQL Db to CSV File and so on. Both approaches are differentiated by the perspective on the problem.

quonn 6y ago
But I rarely use classes in TypeScript. I do think of things as data transformations but the types certainly help a lot.
protonfish 6y ago
Please don't use weak/strong to denote type systems. Those terms are highly subjective and even non-technical people would quickly form an opinion about which is better. (Strong is good, weak is bad.) Static/dynamic is more accurate and less opinionated terminology.
- albntomat0 6y ago
  They are not the same, at least according to the definitions I'm familiar with. Static/dynamic is whether type checking is done at compile time or run type. Strong/weak is how flexible the language is with type conversion. Another explanation: https://en.hexlet.io/courses/intro_to_programming/lessons/types/theory_unit https://en.hexlet.io/courses/intro_to_programming/lessons/ty...
  - nafey 6y ago
    Are these dimensions orthogonal though? For example is there any Strongly typed dynamic language?
    - teddyh 6y ago
      I think Python is mentioned as the usual example.
    - elbear 6y ago
      Python is considered strongly typed, but usually it's placed in opposition with PHP or JavaScript. That's why I don't understand why the previous poster used strongly typed. The conversation was about static and dynamic programming languages.
    - rowanG077 6y ago
      Yes. Completely orthogonal. Strongly typed dynamic: Python Weakly typed dynamic: Javascript Strongly typed static: Haskell Weakly typed static: C
  - JAlexoid 6y ago
    Static vs dynamic is not for type checking, it's about conversion. As in: Static typing - 1 == "1" is false (Python style, integer isn't converted to string for comparison) Dynamic typing - 1 == "1" is true (PHP style, integer or string may be converted)
    - albntomat0 6y ago
      Where are you getting your definitions from? What you posted is what I understand to be weak vs strong.
      - JAlexoid 6y ago
        Barbara Liskov defines strong typing as a compiler feature that prevents wrong type usage. Liskov, B; Zilles, S (1974). "Programming with abstract data types". http://web.cs.iastate.edu/~hridesh/teaching/362/07/01/papers/p50-liskov.pdf http://web.cs.iastate.edu/~hridesh/teaching/362/07/01/papers...
- deleted 6y ago
  [deleted]

pantaloony 6y ago

I don’t get the cost claims. The time it takes to note which type I intend something to be is mostly either so low that I recover it via improved hints and such very quickly, or larger but only because I’m documenting something complex enough that I should have documented it anyway, whether or not I was using static types, because it’ll be hell for other people or future-me to figure out otherwise. It seems like a large time savings to me—throw in faster and more confident refactoring and stuff like that, and it’s not even close. I just don’t get how people are working that it represents a time cost rather than a large time savings. I don’t mean that as a dig, I just mean I genuinely don’t know what that must look like. And I’ve written a lot more code in dynamic languages, and got my start there, so it’s not like I “grew up” writing Java or something like that.

GlennS 6y ago
I would like to be able to explain the cost part better. It may just be personal bias of course. 1. There's no guarantee the correct theoretical model of your program fits the type system of your programming language. 2. Sometimes there are multiple correct models for different purposes in the same program, similar to how sometimes you need multiple views onto the same database tables. 3. Sometimes you just need the ability to bodge things.
- wtetzner 6y ago
  > 2. Sometimes there are multiple correct models for different purposes in the same program, similar to how sometimes you need multiple views onto the same database tables. Just wanted to point out that even though you can have multiple views or your database tables, they all still adhere to the same type system.
  - GlennS 6y ago
    I guess it's a problem that can be overcome with type inference then? (I don't have to declare types on queries, updates, or views, just on the base tables.)
simiones 6y ago

wccrawford 6y ago

It depends on the situation. I've had code that absolutely benefited from static types and it helped me find bugs before they happened. But my current job has very, very little that would benefit from static typing. Adding it into the mix would slow us down, both literally and figuratively.

albntomat0 6y ago
> But my current job has very, very little that would benefit from static typing Would you mind expanding on this? I'd be interested in what processes you have and if you use any additional tooling. Thanks!
- wccrawford 6y ago
  Most of what we do is just data input and data display. And most of that is text. There aren't really any calculations or anything, beyond some simple sizing of UI stuff. For database stuff, an ORM with some validation rules is generally enough, and couldn't be replaced with static typing anyhow. For anything that absolutely has to be a certain kind of data, there are things built into dynamic languages to check the type of something, and you just call it as needed on a case-by-case basis.

pixelrevision 6y ago

Clojure spec seems like the way to go. I really like that it defines what should be going in and out while leaving it really easy to merge incoming data without having to write a bunch of extra code.

deleted 6y ago
[deleted]

orangecat 6y ago

In my experience both the benefits and costs of static typing are overstated. It doesn't mean that your code works if it compiles, and it doesn't mean that you can get rid of half your tests. But it's great for refactoring, and it's a useful form of documentation that can't lie, unlike comments. And if you're using a reasonable language it's not much additional work to add types; often with type inference it's zero work.

nicoburns 6y ago

I hated statix typing until I used Rust. Rust has Sum types (super powered enums), which provide what I was missing from dynamically typed langauges in languages like Java, C#, etc: namely the ability to have an "or" type (e.g. this is an integer or a string, and I want to be able to branch on that at runtime). That, plus type inference makes the static typing pretty painless.

the_af 6y ago
Agreed. Do note that many other languages before Rust do provide good static typing with the niceties you'd expect (and that are often missing from Java), such as type inference, sum types, etc. Some examples include, but are not limited to, Scala, Haskell, the ML family of languages, etc.
Multicomp 6y ago
Could not agree more. That's why I'm going to Rust next once done with my current F# project - I want to have experience with both JIT and AOT languages that support sum types and Option / Discriminated Unions. These data types are much more powerful than the fancy arrays that wowed me back in the day :)

wolfadex 6y ago

For me it depends on the style of static types. I do find Java or C#'s static types to be helpful, but also time consuming. Elm or Haskell on the other hand don't force me to write out the static types while still giving me the benefits of them. There's also the case that I find the type systems of Rust, Elm, etc to be much more helpful than the type systems of C++ or Sorbet (type system for Ruby).