5 ms·

> Static typing everywhere. I think the industry has generally recognised that static typing makes more reliable software. I started with PHP and have seen it

> Static typing everywhere. I think the industry has generally recognised that static typing makes more reliable software. I started with PHP and have seen its type system evolve. Similarly Typescript. I since moved to other staticly typed languages. I wouldn't want to go back.

jaredcwhite 4y ago
Depends on the context. When you're programming a transactional banking system? Heck yeah I want static types. When you're programming a form on a web page? It's way-ay-ay more effort for dubious gains, with new downsides added into the mix.
- simplify 4y ago
  I would LOVE static typing when programming a form on a web page. However, it's the fault of HTML that this is bad, not static typing itself. Although, in theory, one could write a parser to inject what form elements are available into the type system... :)
  - deleted 4y ago
    [deleted]
- heurisko 4y ago
  > When you're programming a form on a web page? It's way-ay-ay more effort for dubious gains, with new downsides added into the mix. If you don't mean just HTML but some server side processing, yes, I would. This is still PHP's bread and butter and being able to bind a form to static types is really convenient.
- choeger 4y ago
  > It's way-ay-ay more effort Just because you tend to ignore the many complexities that are actually involved in a form on a web page. It's exactly this bias that stems from untyped languages and that needs to die. Http is a complex beast and we should either replace it with something more simple and robust or at least acknowledge the complexity in our programming. Generally speaking, if doing something with a proof of type-safety feels complex, you probably ignored many corner cases before.
  - deleted 4y ago
    [deleted]
  - bcrosby95 4y ago
    It's not complexity. It's pointless bookkeeping. If you don't cut corners on your static typing, you're looking at 2-4 single use classes per API endpoint: 1-2 for the web layer, and 1-2 when going into the domain logic layer. Many people skimp and just re-use the core domain class for everything, which is the worst of both worlds. I'll take a map, spec, and select-keys over this all day long.
    - rictic 4y ago
      That's if you write it in Java. With a type system like TypeScript's you can write largely the same code as before, with a few annotations to clarify what you mean, and you get the exact same runtime only you also will get compile errors if a change elsewhere in your program violates the assumptions of that code.
      - samatman 4y ago
        I don't view Typescripts as a good argument against dynamic languages. I view it as a good case for a well-designed gradual type system for dynamic languages. All valid Javascript is Typescript, in a profound rather than trivial way.
    - xigoi 4y ago
      Statically typed ≠ class-oriented
    - wizofaus 4y ago
      2-4 single use type definitions per endpoint sounds pretty atypical to me, but I agree choice of language helps here, e.g. TypeScript has pretty powerful typing facilities (Pick/Partial etc) that make type reuse far more practical. It's bookkeeping yes, but definitely not pointless.
      - deleted 4y ago
- duped 4y ago
  It's actually less effort since you save time writing unit tests. Show me an untyped program and I'll show you a program missing tests and containing bugs. Static typing saves time and money.
- wvenable 4y ago
  > It's way-ay-ay more effort No, it's not. Initially it's not any more effort and in the long term it's significantly less effort. Having spent equal amounts of decades in static and dynamic typing (and strong/weak) I would absolutely take the former any day for both ease of development and correctness.
  - preordained 4y ago
    > Having spent equal amounts of decades in static and dynamic typing I hear this, as well as "eliminates whole classes of run time errors" (as if Ruby and other such codebases are just ablaze everywhere on account of this...), but I wonder if people dabbled in this and think they have it all figured out, or if they've used a modern dynamic language like Clojure that has default immutability or been in a modern Ruby codebase that wasn't cowboy-coded.
    - wvenable 4y ago
      Some of this is just personal taste -- programmers are not all cookie-cutter intellectuals that approach all problems the same way. We're also not all working on the same problems. For me, the idea of dynamically modifying code at runtime is like the first circle of hell. But I've programmed in enough languages to understand the appeal even if it doesn't fit with the way I like to work. But I will take issue with blanket statements that static typing is more effort than dynamic typing with all things being equal. In my own personal experience, that is just not the case. But I wonder if many people have been so damaged by Java that anything seems better by comparison.
    - preseinger 4y ago
      > as if Ruby and other such codebases are just ablaze everywhere on account of this.. They literally are, I think? Ruby is a notoriously unreliable language, in large part due to its dynamic type system... (also all of the unsafe idioms it promotes, a separate discussion)
- tasuki 4y ago
  > way-ay-ay more effort for dubious gains How is it way more effort? In any of the nicer languages, there's type inference. Dubious gains? Strong static typing makes entire classes of runtime bugs impossible (null pointer exceptions, for example).
- wizofaus 4y ago
  New downsides such as? And if having to add a few type definitions to your codebase is "way-ay-ay" more effort, I can only assume you really hate typing, as the mental effort is typically very low (compared to figuring out how to efficiently translate business logic into code, and how to organize code to make it easy for a team to work with over many years as requirements change etc.). There even tools that will generate type definitions for you based on sample data.
- mst 4y ago
  This is a wild-ass guess but ... I don't use IDEs. In fact I use original Bill Joy vi. I suspect for most of the people we're talking to 'I<tab>' will say Int and 'S<tab>' will sat String and that's going to make our experiences very different.
jrockway 4y ago
Yeah, I think this is what a lot of people miss. When I only used dynamic languages, I told everyone that they were the greatest thing ever and they were idiots for using static languages. Then I started using static languages and would never go back to dynamic languages. (OK, I still write Emacs Lisp.) All the things I thought were great about dynamic languages were actually a huge waste of my time, but I didn't know because I never really explored the other side of the world. I have looked at modern Ruby projects, and my assessment is that I absolutely would never want to be responsible for code like that. It's all way too magical, if you see code that says something like "foo.bar", you really have no way of figuring out where the code for "bar" is. "bar" may not even appear as a literal sequence of characters in the application's codebase, or even in the libraries it includes. If you like that, that's fine, but I wouldn't touch it with a ten foot pole. I don't find it that enjoyable, even if it does save me time today when I'm typing in the code.
- vlunkr 4y ago
  > even if it does save me time today when I'm typing in the code IMO this is the strength of Ruby/Rails. You can have something up and running incredibly quickly, but for complex applications it can easily become a mess. It's not easy to know where something is defined, what type it is, if it can be nil, if you're unknowingly calling the database one or one hundred times with your fancy one-liner, etc. Of course you CAN structure it all nicely beforehand, and even use type systems, but that's hard to get right, and at that point, you might as well use something else.
- jaredcwhite 4y ago
  In Ruby, `foo.method(:bar).source_location` works like 98% of the time. There are also LSPs like Solargraph now that work pretty well in VSCode, etc. I will admit there are certain gems which metaprogram the heck out of everything and that can get annoying, but the flipside is usually those are the gems which are hugely flexible because they're so popular and widely used (I'm looking at you Devise)—and if so there's plenty of documentation and community support out there. I'm also glad `binding.irb` is a thing now for immediately jumping into a console in the midst of your running app, and the new debug.rb gem shipping with Ruby 3.1+ is awesome as well (also with a VSCode integration).
treis 4y ago
I don't think that the industry has generally accepted that. It seems pretty hotly debated AFAICT. What is not debated much, AFAICT, is that it's much much easier to work on large/old codebases when you have types. That's really where Rails runs into issues. But it's not like legacy rails monoliths start throwing NPE or other type errors everywhere. It's just that developer productivity grinds to a halt. Mostly for two reasons: (1) You have little idea where the code your modifying is used. Metaprogramming and indirection through send and constants make it hard to find every place it's called. (2) If you're the 5th function in the chain you have no idea where your parameters are coming from. So you have no idea what type they are and method autocompletion doesn't work. Especially annoying when things get complex and you end up with multiple similar but slightly different representations of things.
zelphirkalt 4y ago
Actually typing in PHP is not really static. Errors are thrown at runtime, afaik. There might be separate tools, which check the types before running the program, but they are not PHP itself. That aside, I think part the reason, why static typing brings so much to the table in languages like PHP and JS (in form of TypeScript) is, that they are rather weakly typed and not strongly typed. Weak typing and dynamic typing can make for a terrible DX, when bad designs are present like they are a lot in PHP and JS. I like static typing personally, but for example have no issue with using a strongly typed language, which does not allow me to treat a number as a string or string as a number or similar. Often such a language provides means of making things safer at runtime at least. For example one can define structs and functions, which only work, when they get an instance of that struct. Any other type of value would result in an error. Then of course there are unit tests, which can cover a lot of ground, even if not all a type system can do in theory.

jaredcwhite 4y ago

Depends on the context. When you're programming a transactional banking system? Heck yeah I want static types. When you're programming a form on a web page? It's way-ay-ay more effort for dubious gains, with new downsides added into the mix.

simplify 4y ago
I would LOVE static typing when programming a form on a web page. However, it's the fault of HTML that this is bad, not static typing itself. Although, in theory, one could write a parser to inject what form elements are available into the type system... :)
- deleted 4y ago
  [deleted]
heurisko 4y ago
> When you're programming a form on a web page? It's way-ay-ay more effort for dubious gains, with new downsides added into the mix. If you don't mean just HTML but some server side processing, yes, I would. This is still PHP's bread and butter and being able to bind a form to static types is really convenient.
choeger 4y ago
> It's way-ay-ay more effort Just because you tend to ignore the many complexities that are actually involved in a form on a web page. It's exactly this bias that stems from untyped languages and that needs to die. Http is a complex beast and we should either replace it with something more simple and robust or at least acknowledge the complexity in our programming. Generally speaking, if doing something with a proof of type-safety feels complex, you probably ignored many corner cases before.
- deleted 4y ago
  [deleted]
- bcrosby95 4y ago
  It's not complexity. It's pointless bookkeeping. If you don't cut corners on your static typing, you're looking at 2-4 single use classes per API endpoint: 1-2 for the web layer, and 1-2 when going into the domain logic layer. Many people skimp and just re-use the core domain class for everything, which is the worst of both worlds. I'll take a map, spec, and select-keys over this all day long.
  - rictic 4y ago
    That's if you write it in Java. With a type system like TypeScript's you can write largely the same code as before, with a few annotations to clarify what you mean, and you get the exact same runtime only you also will get compile errors if a change elsewhere in your program violates the assumptions of that code.
    - samatman 4y ago
      I don't view Typescripts as a good argument against dynamic languages. I view it as a good case for a well-designed gradual type system for dynamic languages. All valid Javascript is Typescript, in a profound rather than trivial way.
  - xigoi 4y ago
    Statically typed ≠ class-oriented
  - wizofaus 4y ago
    2-4 single use type definitions per endpoint sounds pretty atypical to me, but I agree choice of language helps here, e.g. TypeScript has pretty powerful typing facilities (Pick/Partial etc) that make type reuse far more practical. It's bookkeeping yes, but definitely not pointless.
    - deleted 4y ago
duped 4y ago
It's actually less effort since you save time writing unit tests. Show me an untyped program and I'll show you a program missing tests and containing bugs. Static typing saves time and money.
wvenable 4y ago
> It's way-ay-ay more effort No, it's not. Initially it's not any more effort and in the long term it's significantly less effort. Having spent equal amounts of decades in static and dynamic typing (and strong/weak) I would absolutely take the former any day for both ease of development and correctness.
- preordained 4y ago
  > Having spent equal amounts of decades in static and dynamic typing I hear this, as well as "eliminates whole classes of run time errors" (as if Ruby and other such codebases are just ablaze everywhere on account of this...), but I wonder if people dabbled in this and think they have it all figured out, or if they've used a modern dynamic language like Clojure that has default immutability or been in a modern Ruby codebase that wasn't cowboy-coded.
  - wvenable 4y ago
    Some of this is just personal taste -- programmers are not all cookie-cutter intellectuals that approach all problems the same way. We're also not all working on the same problems. For me, the idea of dynamically modifying code at runtime is like the first circle of hell. But I've programmed in enough languages to understand the appeal even if it doesn't fit with the way I like to work. But I will take issue with blanket statements that static typing is more effort than dynamic typing with all things being equal. In my own personal experience, that is just not the case. But I wonder if many people have been so damaged by Java that anything seems better by comparison.
  - preseinger 4y ago
    > as if Ruby and other such codebases are just ablaze everywhere on account of this.. They literally are, I think? Ruby is a notoriously unreliable language, in large part due to its dynamic type system... (also all of the unsafe idioms it promotes, a separate discussion)
tasuki 4y ago
> way-ay-ay more effort for dubious gains How is it way more effort? In any of the nicer languages, there's type inference. Dubious gains? Strong static typing makes entire classes of runtime bugs impossible (null pointer exceptions, for example).
wizofaus 4y ago
New downsides such as? And if having to add a few type definitions to your codebase is "way-ay-ay" more effort, I can only assume you really hate typing, as the mental effort is typically very low (compared to figuring out how to efficiently translate business logic into code, and how to organize code to make it easy for a team to work with over many years as requirements change etc.). There even tools that will generate type definitions for you based on sample data.
mst 4y ago
This is a wild-ass guess but ... I don't use IDEs. In fact I use original Bill Joy vi. I suspect for most of the people we're talking to 'I<tab>' will say Int and 'S<tab>' will sat String and that's going to make our experiences very different.

jrockway 4y ago

Yeah, I think this is what a lot of people miss. When I only used dynamic languages, I told everyone that they were the greatest thing ever and they were idiots for using static languages. Then I started using static languages and would never go back to dynamic languages. (OK, I still write Emacs Lisp.) All the things I thought were great about dynamic languages were actually a huge waste of my time, but I didn't know because I never really explored the other side of the world. I have looked at modern Ruby projects, and my assessment is that I absolutely would never want to be responsible for code like that. It's all way too magical, if you see code that says something like "foo.bar", you really have no way of figuring out where the code for "bar" is. "bar" may not even appear as a literal sequence of characters in the application's codebase, or even in the libraries it includes. If you like that, that's fine, but I wouldn't touch it with a ten foot pole. I don't find it that enjoyable, even if it does save me time today when I'm typing in the code.

vlunkr 4y ago
> even if it does save me time today when I'm typing in the code IMO this is the strength of Ruby/Rails. You can have something up and running incredibly quickly, but for complex applications it can easily become a mess. It's not easy to know where something is defined, what type it is, if it can be nil, if you're unknowingly calling the database one or one hundred times with your fancy one-liner, etc. Of course you CAN structure it all nicely beforehand, and even use type systems, but that's hard to get right, and at that point, you might as well use something else.
jaredcwhite 4y ago
In Ruby, `foo.method(:bar).source_location` works like 98% of the time. There are also LSPs like Solargraph now that work pretty well in VSCode, etc. I will admit there are certain gems which metaprogram the heck out of everything and that can get annoying, but the flipside is usually those are the gems which are hugely flexible because they're so popular and widely used (I'm looking at you Devise)—and if so there's plenty of documentation and community support out there. I'm also glad `binding.irb` is a thing now for immediately jumping into a console in the midst of your running app, and the new debug.rb gem shipping with Ruby 3.1+ is awesome as well (also with a VSCode integration).

treis 4y ago

I don't think that the industry has generally accepted that. It seems pretty hotly debated AFAICT. What is not debated much, AFAICT, is that it's much much easier to work on large/old codebases when you have types. That's really where Rails runs into issues. But it's not like legacy rails monoliths start throwing NPE or other type errors everywhere. It's just that developer productivity grinds to a halt. Mostly for two reasons: (1) You have little idea where the code your modifying is used. Metaprogramming and indirection through send and constants make it hard to find every place it's called. (2) If you're the 5th function in the chain you have no idea where your parameters are coming from. So you have no idea what type they are and method autocompletion doesn't work. Especially annoying when things get complex and you end up with multiple similar but slightly different representations of things.

zelphirkalt 4y ago

Actually typing in PHP is not really static. Errors are thrown at runtime, afaik. There might be separate tools, which check the types before running the program, but they are not PHP itself. That aside, I think part the reason, why static typing brings so much to the table in languages like PHP and JS (in form of TypeScript) is, that they are rather weakly typed and not strongly typed. Weak typing and dynamic typing can make for a terrible DX, when bad designs are present like they are a lot in PHP and JS. I like static typing personally, but for example have no issue with using a strongly typed language, which does not allow me to treat a number as a string or string as a number or similar. Often such a language provides means of making things safer at runtime at least. For example one can define structs and functions, which only work, when they get an instance of that struct. Any other type of value would result in an error. Then of course there are unit tests, which can cover a lot of ground, even if not all a type system can do in theory.