4 ms·

"smug static weenies" LOL. I really, really don't mind if people have preference for static typing. I do too - not as strong as the 2022 zeitgeist to be sure b

"smug static weenies" LOL. I really, really don't mind if people have preference for static typing. I do too - not as strong as the 2022 zeitgeist to be sure but I still have it. What I dislike is the inference that people who prefer dynamic typing are ignorant, that they just haven't discovered hindley-milner and need to be converted. A lot of incredibly smart, talented programmers chose (and choose) to do work with dynamically typed languages. Don't assume it was because they knew less than you.

claytongulick 4y ago
Thanks for this. After ~30 years of professional software development in pretty much every major language created, I prefer dynamic languages to statically types ones for a whole host of reasons, none of which amount to me being a n00b or uneducated, which is frequently implied by the static types die-hard folks.
- tines 4y ago
  Language researcher here, would you be willing to list out some of those reasons you mentioned? Always interested in hearing these perspectives!
  - diffxx 4y ago
    Not the OP, but most compilers for languages with static type systems are too slow for my taste. I have a workflow for writing lua programs in which I embed all of my tests in the same file that contains all of the runtime logic. Whenever that file changes, I have a monitor script that runs the program and validates my tests. This process typically happens in less than 20ms, so I've configured my editor to save my lua files whenever I type a single keystroke. It's like having a living REPL session that is persistently stored in the file. When you develop in this style, you tend not to write type errors because you are constantly validating your program inputs and outputs, which the tight feedback loop encourages. Most statically typed languages have slow compilers. It is not uncommon for an incremental compile to take at least 1s, which is 50-100x slower than what I'm used to. Indeed, I find it distracting when compilation is that slow so with such a language I will still use a monitor script for iteration but I will manually save when I want validation. This means that I am not only getting slower feedback, I am getting less of it, which ultimately makes me less confident in my program. If I were making lots of type errors, maybe it would be worth it to have a type checker, but I'm generally not.
  - claytongulick 4y ago
    Sure, thanks for asking! I think it's mostly about time to market and reduced total LOC. I find that in strongly typed languages, frequently up to 30% or more of the total lines of code are dedicated to nothing but type satisfaction. Sometimes this formalism is warranted, depending on the problem domain (banking, air craft systems, etc) but most of the time I find that the type systems are merely mental abstractions that are created to assist the developer in modeling the solution. There's value in that. As I've gained more experience, trivialities like the compiler catching junior programmer level silly type mistakes has become less valuable. Type systems don't address logic errors. The flexibility of duck typing with loose contracts reduces total time to market for applications where that's a primary constraint. This happens to be true in a vast class of problem domains, where having something quickly is more important than performance or formal correctness. Since I tend to live in the startup space where TTM and MVPs are critical to business success, I'm inclined towards languages that support this. I typically don't have to deal with large team coordination issues or extremely complex interdependence, and my systems are normally fairly basic - crud with business rules and a fancy UI. In this case, things like type errors present themselves immediately in the UI and are easy to catch during development, reducing the value of compile time error detection.
ReflectedImage 4y ago
Personally I do both. If I'm using a scripting language like Python I'm all for dynamic typing and if I'm using a programming language like Rust I'm all for static typing. They are different development experiences, one isn't better than the other. If you want to ship something to market tomorrow use Python with dynamic typing. If you want something to run fast and be error free use Rust with static typing. Both are good options.
CoastalCoder 4y ago
It's honestly the opposite for me. I need the mental crutches provided by strong static typing. TL;DR: I work with a lot of very smart, very talented software developers who thrive with Python's dynamic qualities. They have little problem reasoning about our software's runtime behavior. Unfortunately, I'm a bit less intelligent than them. I have a much harder time understanding the code's design and behavior due to that dynamism. I would really benefit from the crutch of strong static typing, and the more obvious relationship between static source code and runtime behavior.
- ReflectedImage 4y ago
  Why "strong static typing" in particular? Surely there are many other things that could help.
  - CoastalCoder 4y ago
    I find that in software with a strong static typing, I can generally understand each function or class on its own, without much consideration of the context(s) in which it's used. If that same software were written in e.g. idiomatic Python without the use of typing hints, I often need to read a lot more comments, and look at the particular contexts in which that function or class is used, in order to understand its intended purpose and supported use-cases. Things like monkey-patching make it even harder for me. So for someone accustomed to understanding a piece of software by reading the source code (i.e., human, static analysis), a big software system written in highly dynamic Python has a really long learning curve.
    - ReflectedImage 4y ago
      But generally speaking the code is only 1/3rd of the size. So you have a lot less to read. The only place monkey patching is typically used is in places it has no effect on code meaning such as GEvent.
      - kaashif 4y ago
lazide 4y ago
As someone who does Perl, python, Java, C#, and various flavors of JavaScript on the regular - it’s different tools for different situations. I’ve worked on million+ line Perl codebases, and even bigger FAANG codebases in each of those languages, and untyped large code bases turn into impenetrable balls of mud much quicker than typed ones. And myself and others were doing runtime meta programming in Perl long before it was cool or anyone we knew was calling it that. But never underestimate the ability for a software engineer to create code in any language that will perplex and mystify them a year later. And I’ve not met a codebase in any language yet that couldn’t be turned into a ball of mud pretty quickly.
- zelphirkalt 4y ago
  Becoming an impenetrable balls of mud also depends a bit on the language design. For example in Python one can implement how objects respond to operators (double underscore stuff), but that hides the characters of the object. In other languages one has separate functions for doing things with different types like string-length, vector-length, and so on. When you see that in the code, you immediately know the type of that argument of the function, because it is explicitly in the name of standard library functions. It is a language design choice.

claytongulick 4y ago

Thanks for this. After ~30 years of professional software development in pretty much every major language created, I prefer dynamic languages to statically types ones for a whole host of reasons, none of which amount to me being a n00b or uneducated, which is frequently implied by the static types die-hard folks.

tines 4y ago
Language researcher here, would you be willing to list out some of those reasons you mentioned? Always interested in hearing these perspectives!
- diffxx 4y ago
  Not the OP, but most compilers for languages with static type systems are too slow for my taste. I have a workflow for writing lua programs in which I embed all of my tests in the same file that contains all of the runtime logic. Whenever that file changes, I have a monitor script that runs the program and validates my tests. This process typically happens in less than 20ms, so I've configured my editor to save my lua files whenever I type a single keystroke. It's like having a living REPL session that is persistently stored in the file. When you develop in this style, you tend not to write type errors because you are constantly validating your program inputs and outputs, which the tight feedback loop encourages. Most statically typed languages have slow compilers. It is not uncommon for an incremental compile to take at least 1s, which is 50-100x slower than what I'm used to. Indeed, I find it distracting when compilation is that slow so with such a language I will still use a monitor script for iteration but I will manually save when I want validation. This means that I am not only getting slower feedback, I am getting less of it, which ultimately makes me less confident in my program. If I were making lots of type errors, maybe it would be worth it to have a type checker, but I'm generally not.
- claytongulick 4y ago
  Sure, thanks for asking! I think it's mostly about time to market and reduced total LOC. I find that in strongly typed languages, frequently up to 30% or more of the total lines of code are dedicated to nothing but type satisfaction. Sometimes this formalism is warranted, depending on the problem domain (banking, air craft systems, etc) but most of the time I find that the type systems are merely mental abstractions that are created to assist the developer in modeling the solution. There's value in that. As I've gained more experience, trivialities like the compiler catching junior programmer level silly type mistakes has become less valuable. Type systems don't address logic errors. The flexibility of duck typing with loose contracts reduces total time to market for applications where that's a primary constraint. This happens to be true in a vast class of problem domains, where having something quickly is more important than performance or formal correctness. Since I tend to live in the startup space where TTM and MVPs are critical to business success, I'm inclined towards languages that support this. I typically don't have to deal with large team coordination issues or extremely complex interdependence, and my systems are normally fairly basic - crud with business rules and a fancy UI. In this case, things like type errors present themselves immediately in the UI and are easy to catch during development, reducing the value of compile time error detection.

ReflectedImage 4y ago

Personally I do both. If I'm using a scripting language like Python I'm all for dynamic typing and if I'm using a programming language like Rust I'm all for static typing. They are different development experiences, one isn't better than the other. If you want to ship something to market tomorrow use Python with dynamic typing. If you want something to run fast and be error free use Rust with static typing. Both are good options.

CoastalCoder 4y ago

It's honestly the opposite for me. I need the mental crutches provided by strong static typing. TL;DR: I work with a lot of very smart, very talented software developers who thrive with Python's dynamic qualities. They have little problem reasoning about our software's runtime behavior. Unfortunately, I'm a bit less intelligent than them. I have a much harder time understanding the code's design and behavior due to that dynamism. I would really benefit from the crutch of strong static typing, and the more obvious relationship between static source code and runtime behavior.

ReflectedImage 4y ago
Why "strong static typing" in particular? Surely there are many other things that could help.
- CoastalCoder 4y ago
  I find that in software with a strong static typing, I can generally understand each function or class on its own, without much consideration of the context(s) in which it's used. If that same software were written in e.g. idiomatic Python without the use of typing hints, I often need to read a lot more comments, and look at the particular contexts in which that function or class is used, in order to understand its intended purpose and supported use-cases. Things like monkey-patching make it even harder for me. So for someone accustomed to understanding a piece of software by reading the source code (i.e., human, static analysis), a big software system written in highly dynamic Python has a really long learning curve.
  - ReflectedImage 4y ago
    But generally speaking the code is only 1/3rd of the size. So you have a lot less to read. The only place monkey patching is typically used is in places it has no effect on code meaning such as GEvent.
    - kaashif 4y ago

lazide 4y ago

As someone who does Perl, python, Java, C#, and various flavors of JavaScript on the regular - it’s different tools for different situations. I’ve worked on million+ line Perl codebases, and even bigger FAANG codebases in each of those languages, and untyped large code bases turn into impenetrable balls of mud much quicker than typed ones. And myself and others were doing runtime meta programming in Perl long before it was cool or anyone we knew was calling it that. But never underestimate the ability for a software engineer to create code in any language that will perplex and mystify them a year later. And I’ve not met a codebase in any language yet that couldn’t be turned into a ball of mud pretty quickly.

zelphirkalt 4y ago
Becoming an impenetrable balls of mud also depends a bit on the language design. For example in Python one can implement how objects respond to operators (double underscore stuff), but that hides the characters of the object. In other languages one has separate functions for doing things with different types like string-length, vector-length, and so on. When you see that in the code, you immediately know the type of that argument of the function, because it is explicitly in the name of standard library functions. It is a language design choice.