6 ms·

I think dynamic code bases can have the choice now. Python has hints, JS can gradually turn to Typescript. Ruby got Sorbet. It's nice to have a choice. I person

I think dynamic code bases can have the choice now. Python has hints, JS can gradually turn to Typescript. Ruby got Sorbet. It's nice to have a choice. I personally don't like types but yeah if some monolith grows to uncontrollable size like Shopify/Stripe it makes sense to type certain areas.

lionkor 5y ago
I've always wondered, and maybe you can clear this up, why? What about static typing is "worse", so to speak?
- jimsimmons 5y ago
  It’s slow and cumbersome to write. Makes code verbose and harder to read.
  - einherjae 5y ago
    Except that very verbosity may make it easier to read, as the types themselves may supply further information to the reader about what the variable actually means.
  - skohan 5y ago
    Yeah this might be true of Java, but I think for modern languages with good type inference it adds a lot to readability without much cost in terms of verbosity. After working with more strongly typed languages, it actually seems crazy to go back to JS or Python and not have type information in function signatures. Like how are people supposed to read code and understand what this function is allowed to take?
    - joelbluminator 5y ago
      Functional programmers also say "how can I go back to mutable state and OOP". The fact is people get stuff done in many different ways and paradigms. You found what works for you and that's good, stick to it. Others found theirs.
    - arcturus17 5y ago
      You can annotate types in Python and Typescript. Before that large companies like Google got around it by annotating in the comments. It may be an inferior solution but huge codebases serving hundreds of millions of users have worked this way.
      - gefhfff 5y ago
        Huge code bases serving hundreds of millions have been written in wasm, so...? Bad argument
        arcturus17 5y ago
        There was no argument, the commenter was just asking “how”.
    - kaba0 5y ago
      Modern Java is not what people may remember. It has var keyword for local type inference, lambdas, etc.
  - user-the-name 5y ago
    Verbosity aids readability a lot of the time.
  - jim-jim-jim 5y ago
    I think this is noisy. f(x: a, y: b): c = ... I think this is nice. f :: a -> b -> c f x y = ... Signatures are useful as self-documentation, and keeping them separate makes that easy to scan. It also comes down to the compiler. If you're "annotating" your code with type "sugestions," but don't get any ironclad guarantees from it, then it's reasonable to question whether it's even worth the effort. I may be misremembering things, but "typed" versions of Python and Scheme aren't particularly rigorous.
- joelbluminator 5y ago
  Hard to explain. It's more verbose and restrictive. Ruby is the complete opposite, you can do anything you want. I know what people say about Monkey Patching but what Rails did with ActiveSupport is mostly beautiful. I can see the advantages in types I'm not denying them. I am just so comfortable with Ruby/Rails and js I never bothered looking deeply into anything else. The Java I did in college, and then the experiments I did with Spring framework a couple of years ago (tried a couple of todo apps) made it clear to me it's not my thing. Ruby/Rails made programming actually fun. It may have improved since then but I think even getting a shell (like Rails console) was difficult with Spring. Maybe if I stuck to Spring for months or years I would have felt differently, impossible to tell most of the time because we usually stick to what we like and avoid delving too deep into what we don't like. Spring was just a massive complicated thing, or at least that's the impression I got. People go on and on about Rails being magical, I suspect most of them have a very vague understanding of how Spring actually works under the hood. Not to mention those hundreds of Beans you need to get to know, I dread those! I can see myself doing Go or Swift, something not too verbose, but again, I don't really care for performance (it's not at the top of my wish list as a web developer) that much or types. So to sum it up: I just like Ruby/Rails and not a big Java fan. I know there are many other static languages to choose from but life is short, I am happy doing my thing with Ruby. If I have to jump ship it will probably be to Python.
  - omegalulw 5y ago
    I absolutely disagree with the assertion that static typing is restrictive. It's not, though of course you need to be more verbose. But you are doing this largely for correctness so it's a worth tradeoff. Needing overly generic types or no type restrictions is very strong code smell.
- belorn 5y ago
  A static type system requires the programmer to think about the types. It distracts and takes up mental space, especially when one is returning to old code and "just" want to quickly add a small feature that sound simple in concept but first require that one parse the thought process behind the old code.
  - gefhfff 5y ago
    And with dynamic ts the programmer is not required to think about it? You don't think anymore if you return a number or a string or a map? I doubt it. Static TS require you to think correct (and occasionally write it down - depends on the language) before you run the code.
    - belorn 5y ago
      Here is a real life example. I have a library that communicate with an API that extract information, and now I want it to also grab an additional field and extract it to a database. The goal is to figure out which functions in the code accesses the field, where the best spot is to extract the information, and what the best way to call into the database without adding too much code in places where it shouldn't be. In addition I need to keep the information synced over time. Do I care what the different functions in the library return? No. The field could exist in everything from an XML object, a dict, a string, a byte array, or a custom object made for easy interaction. What I need to know is where in the flow I can best inject my new code, and in order to do so I need to know when and where the information can be accessed. In an optimal world I would have written a shell script, and in that case every function has a single return type which is string.
      - scrollaway 5y ago
        If you do not care about the type, and indeed do not do anything special with it other than pass it through to somewhere (that may or may not care about it), then there are types that let you do that. A good typed language will allow you to be more or less strict about what you accept (eg. a specific literal string, a set of strings, any string, any string like object, any object...)
- blacktriangle 5y ago
  Fundamental difference between static and dynamic: static typing disallows writing a certain set of perfectly valid programs while also having the advantage of disallowing many invalid programs. So the question becomes: how badly do you want to work in that space that is not permitted by static systems? And that space is where your data itself is highly dynamic. When you just want to represent data as maps, do generic operations on maps, then spit out more maps back to something else. This description applies to many many real world systems, particular in the more business-type domains. Another space where dynamic really shines is dealing with relational data in a relational way. Relations are just sets of maps, the most natural thing in the world to work with dynamically. In a dynamic language I can just write code that peaks into the map, transforms certain fields, then passes the whole thing on down the line. I don't care what combination of selects and joins got me that relation, and in reality there will be many, I want to reuse my functions regardless. Although this is where more structural type systems can help ease the pain over nominal type systems. I feel like this is a great blog post talking about the downsides of static typing in a real world system: https://lispcast.com/user-wizard-scenario/ https://lispcast.com/user-wizard-scenario/. I appreciate that the author has real world experience with both Haskell and Clojure and comes from that perspective. Ultimately I'd say that if a program can be written in a static language, it should be, however some programs deal with information that just defies fitting into your type system without herculean efforts. Just like static languages will look down on dynamic languages for reimplementing poor ad-hoc type checking, dynamic languages can also look down on static languages for poorly reimpelmenting dynamic behavior with a bunch of functions mapping Any to Any.
  - joelbluminator 5y ago
    Thanks for the link. Finally somebody using actual comprehensible examples to build a case.

lionkor 5y ago

I've always wondered, and maybe you can clear this up, why? What about static typing is "worse", so to speak?

jimsimmons 5y ago
It’s slow and cumbersome to write. Makes code verbose and harder to read.
- einherjae 5y ago
  Except that very verbosity may make it easier to read, as the types themselves may supply further information to the reader about what the variable actually means.
- skohan 5y ago
  Yeah this might be true of Java, but I think for modern languages with good type inference it adds a lot to readability without much cost in terms of verbosity. After working with more strongly typed languages, it actually seems crazy to go back to JS or Python and not have type information in function signatures. Like how are people supposed to read code and understand what this function is allowed to take?
  - joelbluminator 5y ago
    Functional programmers also say "how can I go back to mutable state and OOP". The fact is people get stuff done in many different ways and paradigms. You found what works for you and that's good, stick to it. Others found theirs.
  - arcturus17 5y ago
    You can annotate types in Python and Typescript. Before that large companies like Google got around it by annotating in the comments. It may be an inferior solution but huge codebases serving hundreds of millions of users have worked this way.
    - gefhfff 5y ago
      Huge code bases serving hundreds of millions have been written in wasm, so...? Bad argument
      - arcturus17 5y ago
        There was no argument, the commenter was just asking “how”.
  - kaba0 5y ago
    Modern Java is not what people may remember. It has var keyword for local type inference, lambdas, etc.
- user-the-name 5y ago
  Verbosity aids readability a lot of the time.
- jim-jim-jim 5y ago
  I think this is noisy. f(x: a, y: b): c = ... I think this is nice. f :: a -> b -> c f x y = ... Signatures are useful as self-documentation, and keeping them separate makes that easy to scan. It also comes down to the compiler. If you're "annotating" your code with type "sugestions," but don't get any ironclad guarantees from it, then it's reasonable to question whether it's even worth the effort. I may be misremembering things, but "typed" versions of Python and Scheme aren't particularly rigorous.
joelbluminator 5y ago
Hard to explain. It's more verbose and restrictive. Ruby is the complete opposite, you can do anything you want. I know what people say about Monkey Patching but what Rails did with ActiveSupport is mostly beautiful. I can see the advantages in types I'm not denying them. I am just so comfortable with Ruby/Rails and js I never bothered looking deeply into anything else. The Java I did in college, and then the experiments I did with Spring framework a couple of years ago (tried a couple of todo apps) made it clear to me it's not my thing. Ruby/Rails made programming actually fun. It may have improved since then but I think even getting a shell (like Rails console) was difficult with Spring. Maybe if I stuck to Spring for months or years I would have felt differently, impossible to tell most of the time because we usually stick to what we like and avoid delving too deep into what we don't like. Spring was just a massive complicated thing, or at least that's the impression I got. People go on and on about Rails being magical, I suspect most of them have a very vague understanding of how Spring actually works under the hood. Not to mention those hundreds of Beans you need to get to know, I dread those! I can see myself doing Go or Swift, something not too verbose, but again, I don't really care for performance (it's not at the top of my wish list as a web developer) that much or types. So to sum it up: I just like Ruby/Rails and not a big Java fan. I know there are many other static languages to choose from but life is short, I am happy doing my thing with Ruby. If I have to jump ship it will probably be to Python.
- omegalulw 5y ago
  I absolutely disagree with the assertion that static typing is restrictive. It's not, though of course you need to be more verbose. But you are doing this largely for correctness so it's a worth tradeoff. Needing overly generic types or no type restrictions is very strong code smell.
belorn 5y ago
A static type system requires the programmer to think about the types. It distracts and takes up mental space, especially when one is returning to old code and "just" want to quickly add a small feature that sound simple in concept but first require that one parse the thought process behind the old code.
- gefhfff 5y ago
  And with dynamic ts the programmer is not required to think about it? You don't think anymore if you return a number or a string or a map? I doubt it. Static TS require you to think correct (and occasionally write it down - depends on the language) before you run the code.
  - belorn 5y ago
    Here is a real life example. I have a library that communicate with an API that extract information, and now I want it to also grab an additional field and extract it to a database. The goal is to figure out which functions in the code accesses the field, where the best spot is to extract the information, and what the best way to call into the database without adding too much code in places where it shouldn't be. In addition I need to keep the information synced over time. Do I care what the different functions in the library return? No. The field could exist in everything from an XML object, a dict, a string, a byte array, or a custom object made for easy interaction. What I need to know is where in the flow I can best inject my new code, and in order to do so I need to know when and where the information can be accessed. In an optimal world I would have written a shell script, and in that case every function has a single return type which is string.
    - scrollaway 5y ago
      If you do not care about the type, and indeed do not do anything special with it other than pass it through to somewhere (that may or may not care about it), then there are types that let you do that. A good typed language will allow you to be more or less strict about what you accept (eg. a specific literal string, a set of strings, any string, any string like object, any object...)
blacktriangle 5y ago
Fundamental difference between static and dynamic: static typing disallows writing a certain set of perfectly valid programs while also having the advantage of disallowing many invalid programs. So the question becomes: how badly do you want to work in that space that is not permitted by static systems? And that space is where your data itself is highly dynamic. When you just want to represent data as maps, do generic operations on maps, then spit out more maps back to something else. This description applies to many many real world systems, particular in the more business-type domains. Another space where dynamic really shines is dealing with relational data in a relational way. Relations are just sets of maps, the most natural thing in the world to work with dynamically. In a dynamic language I can just write code that peaks into the map, transforms certain fields, then passes the whole thing on down the line. I don't care what combination of selects and joins got me that relation, and in reality there will be many, I want to reuse my functions regardless. Although this is where more structural type systems can help ease the pain over nominal type systems. I feel like this is a great blog post talking about the downsides of static typing in a real world system: https://lispcast.com/user-wizard-scenario/ https://lispcast.com/user-wizard-scenario/. I appreciate that the author has real world experience with both Haskell and Clojure and comes from that perspective. Ultimately I'd say that if a program can be written in a static language, it should be, however some programs deal with information that just defies fitting into your type system without herculean efforts. Just like static languages will look down on dynamic languages for reimplementing poor ad-hoc type checking, dynamic languages can also look down on static languages for poorly reimpelmenting dynamic behavior with a bunch of functions mapping Any to Any.
- joelbluminator 5y ago
  Thanks for the link. Finally somebody using actual comprehensible examples to build a case.