8 ms·

>Also, some of us are as anti-typing as you are pro-typing. Assuming ample experience with both, how does one reach this conclusion? I have yet to see a proje

>Also, some of us are as anti-typing as you are pro-typing. Assuming ample experience with both, how does one reach this conclusion? I have yet to see a project of any size that needs to be worked on by multiple teams and is written in an untyped language not descend into dumpster fire.

throwawaymaths 3y ago
>I have yet to see a project of any size that needs to be worked on by multiple teams and is written in an untyped language not descend into dumpster fire. Github? Dropbox? I mean they both eventually went to type hints in their respective languages or migrated to a typed language but for a long time I'm certain it wasn't.
- ollien 3y ago
  It's worth noting of course that ~Github~ Dropbox was the driving force behind mypy
  - throwawaymaths 3y ago
    yes, that is exactly what I meant by "they both eventually went to type hints", but doesn't github use ruby? I think you mean sorbet? Dropbox was the driving force behind mypy (IIRC).
    - ollien 3y ago
      bleh, I meant to say Dropbox.
- RhodesianHunter 3y ago
  And I can pretty much guarantee you that some form of dumpster, fire or other was the driving factor behind those moves.
dllthomas 3y ago
While I'm pretty solidly in the "pro-typing" camp, it seems worth acknowledging that such projects often turn into dumpster fires in typed languages as well, even expressively typed languages.
- jjnoakes 3y ago
  Maybe, maybe not - but in my experience, a dumpster fire with static types is easier to read and understand and also easier to refactor.
  - dllthomas 3y ago
    That matches my experience as well. I just think we need to be resistant to reading too much into "I've seen bad code that X", because that can easily be true of almost any X.
  - jibe 3y ago
    You think that statically typed languages don’t often turn into dumpster fires? Not my experience! Even though there are real advantages.
- 3836293648 3y ago
  Sure, but they don't turn into dumpster fires because of the types, as untyped projects tend to do
  - dllthomas 3y ago
    I don't know that that's true. When the types in a program are designed in a way that's sufficiently out of sync with what a program needs to do, you can get a lot of mess working around them. Can we say that's misuse of the tools? Sure. Is it less likely than things becoming a mess without types? Probably? Even more so as the tools improve and as the people involved know better how to use them.
toast0 3y ago
I work on a lot of 'glue' issues, often with languages like Perl, PHP, and Erlang (and a bit of Javascript here and there). Specifying types all over the place in languages like C, C++, Java, and Rust feels like it gets in the way and limits more than it helps. (feelings more than data here, of course) Sure, at boundaries between teams, you need to specify the data in some way. That could be a type, but for me, often the other team is using a different language than me, so it needs to be a language agnostic type, and it can't include unsigned numbers because Java can't cope, and it can't include large integers because Javascript can't cope, etc. Protobufs are popular, json is too. I have a lot of unpopular opinions though, and that's fine. It's just tiresome that everyone wants to come in and add types to things that don't need them. Also, I agree with dllthomas, most developers and teams are capable of creating dumpster fires in all sorts of environments, with all sorts of tooling. :)
- RhodesianHunter 3y ago
  You can absolutely create a dumpster fire in any language. Putting the fire out in an untyped language is a Herculean effort.
  - di4na 3y ago
    In my experience it is even harder in a typed one because now you have to deal with the type system nightmare they built. So the compiler fight your refactoring.
    - bombela 3y ago
      Nobody code without a type system. The distinction is build time vs runtime type checking. At build time you catch bugs that would appear later at runtime. Which is more costly to fix later.
      - toast0 3y ago
        > Which is more costly to fix later. This assumption is changed, IMHO, by Erlang. Hot loading makes the cost to make small changes very low. So the question becomes, do you pay the definite cost of build time type checking (usually includes coding time type annotation), or do you accept the possible future cost to making small fixes. Of course, if you work in an organization where even a small fix requires months to release, then do all the things you can to prevent making small mistakes.
fiddlerwoaroof 3y ago
I tried Haskell for a while and switched to Common Lisp (although I still follow Haskell from a distance). My experience just doesn't match up with the claim that a project of any size written in an untyped inevitably descends into a dumpster fire. I've worked on largish systems in several dynamically-typed languages and several statically-typed and I personally haven't noticed any major difference in overall productivity suggesting that static types are better: they just have different friction points and different ways of working work better in each paradigm.
- RhodesianHunter 3y ago
  The issue isn't productivity. As far as just slamming out code untyped languages are undeniably faster. The issue is working on projects once they've reached a certain size where you have no idea what the intent of the original author was and you maybe need to refactor, add-in major pieces, or change anything with the expectation that it continues to work.
  - fiddlerwoaroof 3y ago
    I’m including maintenance costs in “productivity”. I’ve worked on large dynamically typed codebases and never experienced what you’re talking about. I think it’s a question of understanding how to work and think without explicit types rather than something that makes statically typed codebases easier to maintain.
  - ReflectedImage 3y ago
    Untyped code bases with microservices are the best code bases out there by far. They are exceptionally easy to refactor, add-in new parts, etc. The keyword is microservices, you need to know how to do proper microservices if you are using untyped code.
    - bcrosby95 3y ago
      I dunno. Something like spec, dialyzer, or "assertive" typing (in the case of Elixir) on the boundary works just fine for me.
ReflectedImage 3y ago
Untyped languages work fine if you use them with microservices. The only thing you can't do is have both untyped and monolithic at the same time.
- medo-bear 3y ago
  for some reason people are able to use huge undocumented common lisp monolithic projects from the 90s without much effort and without setting their computer on fire. why do you think that is? i mean, given your world view, why would people even think about doing this for a codebase that doesnt have static types?
  - lispm 3y ago
    Maybe because the language is not untyped? It has both dynamic typing and optional static typing.
    - medo-bear 3y ago
      sure but not in a sense that rust is. my point is that it is entirely possible to build good software with substantial code bases in dynamically typed languges and i used common lisp as an example. in fact i dont know of one common lisp code base that turned to a dumpster fire because of typing problems. instead i find the opposite true: old forgotten code can often be resurrected because the language promotes clear coding and interactive introspection
      - shrimp_emoji 3y ago
        Lisp is not Python or JS. People use Python and JS, not Lisp. Dynamic typing in Python and JS + medium-sized project = dumpster fire.
        medo-bear 3y ago
        there are plenty of disaster code bases in both dynamic and static typed languages. my cause for mentioning common lisp was use of an example i personally know of where a dynamic language (albeit one with strong and static typing support available) produces some really high quality code that can stand the test of time
freedomben 3y ago
I have yet to see a project of any size that needs to be worked on by multiple teams not descend into dumpster fire. Typing can definitely help, but it's just a small tool. Java is a pretty typed language and I'm seen some real doozy code bases in Java.
- kaba0 3y ago
  Though that might just as well mean that typed language projects, like those in Java have actually survived long enough to have turned into that. It is easy to be maintainable at iteration 1 when the requirements haven’t changed 20 times yet.

throwawaymaths 3y ago

>I have yet to see a project of any size that needs to be worked on by multiple teams and is written in an untyped language not descend into dumpster fire. Github? Dropbox? I mean they both eventually went to type hints in their respective languages or migrated to a typed language but for a long time I'm certain it wasn't.

ollien 3y ago
It's worth noting of course that ~Github~ Dropbox was the driving force behind mypy
- throwawaymaths 3y ago
  yes, that is exactly what I meant by "they both eventually went to type hints", but doesn't github use ruby? I think you mean sorbet? Dropbox was the driving force behind mypy (IIRC).
  - ollien 3y ago
    bleh, I meant to say Dropbox.
RhodesianHunter 3y ago
And I can pretty much guarantee you that some form of dumpster, fire or other was the driving factor behind those moves.

dllthomas 3y ago

While I'm pretty solidly in the "pro-typing" camp, it seems worth acknowledging that such projects often turn into dumpster fires in typed languages as well, even expressively typed languages.

jjnoakes 3y ago
Maybe, maybe not - but in my experience, a dumpster fire with static types is easier to read and understand and also easier to refactor.
- dllthomas 3y ago
  That matches my experience as well. I just think we need to be resistant to reading too much into "I've seen bad code that X", because that can easily be true of almost any X.
- jibe 3y ago
  You think that statically typed languages don’t often turn into dumpster fires? Not my experience! Even though there are real advantages.
3836293648 3y ago
Sure, but they don't turn into dumpster fires because of the types, as untyped projects tend to do
- dllthomas 3y ago
  I don't know that that's true. When the types in a program are designed in a way that's sufficiently out of sync with what a program needs to do, you can get a lot of mess working around them. Can we say that's misuse of the tools? Sure. Is it less likely than things becoming a mess without types? Probably? Even more so as the tools improve and as the people involved know better how to use them.

toast0 3y ago

I work on a lot of 'glue' issues, often with languages like Perl, PHP, and Erlang (and a bit of Javascript here and there). Specifying types all over the place in languages like C, C++, Java, and Rust feels like it gets in the way and limits more than it helps. (feelings more than data here, of course) Sure, at boundaries between teams, you need to specify the data in some way. That could be a type, but for me, often the other team is using a different language than me, so it needs to be a language agnostic type, and it can't include unsigned numbers because Java can't cope, and it can't include large integers because Javascript can't cope, etc. Protobufs are popular, json is too. I have a lot of unpopular opinions though, and that's fine. It's just tiresome that everyone wants to come in and add types to things that don't need them. Also, I agree with dllthomas, most developers and teams are capable of creating dumpster fires in all sorts of environments, with all sorts of tooling. :)

RhodesianHunter 3y ago
You can absolutely create a dumpster fire in any language. Putting the fire out in an untyped language is a Herculean effort.
- di4na 3y ago
  In my experience it is even harder in a typed one because now you have to deal with the type system nightmare they built. So the compiler fight your refactoring.
  - bombela 3y ago
    Nobody code without a type system. The distinction is build time vs runtime type checking. At build time you catch bugs that would appear later at runtime. Which is more costly to fix later.
    - toast0 3y ago
      > Which is more costly to fix later. This assumption is changed, IMHO, by Erlang. Hot loading makes the cost to make small changes very low. So the question becomes, do you pay the definite cost of build time type checking (usually includes coding time type annotation), or do you accept the possible future cost to making small fixes. Of course, if you work in an organization where even a small fix requires months to release, then do all the things you can to prevent making small mistakes.

fiddlerwoaroof 3y ago

I tried Haskell for a while and switched to Common Lisp (although I still follow Haskell from a distance). My experience just doesn't match up with the claim that a project of any size written in an untyped inevitably descends into a dumpster fire. I've worked on largish systems in several dynamically-typed languages and several statically-typed and I personally haven't noticed any major difference in overall productivity suggesting that static types are better: they just have different friction points and different ways of working work better in each paradigm.

RhodesianHunter 3y ago
The issue isn't productivity. As far as just slamming out code untyped languages are undeniably faster. The issue is working on projects once they've reached a certain size where you have no idea what the intent of the original author was and you maybe need to refactor, add-in major pieces, or change anything with the expectation that it continues to work.
- fiddlerwoaroof 3y ago
  I’m including maintenance costs in “productivity”. I’ve worked on large dynamically typed codebases and never experienced what you’re talking about. I think it’s a question of understanding how to work and think without explicit types rather than something that makes statically typed codebases easier to maintain.
- ReflectedImage 3y ago
  Untyped code bases with microservices are the best code bases out there by far. They are exceptionally easy to refactor, add-in new parts, etc. The keyword is microservices, you need to know how to do proper microservices if you are using untyped code.
  - bcrosby95 3y ago
    I dunno. Something like spec, dialyzer, or "assertive" typing (in the case of Elixir) on the boundary works just fine for me.

ReflectedImage 3y ago

Untyped languages work fine if you use them with microservices. The only thing you can't do is have both untyped and monolithic at the same time.

medo-bear 3y ago
for some reason people are able to use huge undocumented common lisp monolithic projects from the 90s without much effort and without setting their computer on fire. why do you think that is? i mean, given your world view, why would people even think about doing this for a codebase that doesnt have static types?
- lispm 3y ago
  Maybe because the language is not untyped? It has both dynamic typing and optional static typing.
  - medo-bear 3y ago
    sure but not in a sense that rust is. my point is that it is entirely possible to build good software with substantial code bases in dynamically typed languges and i used common lisp as an example. in fact i dont know of one common lisp code base that turned to a dumpster fire because of typing problems. instead i find the opposite true: old forgotten code can often be resurrected because the language promotes clear coding and interactive introspection
    - shrimp_emoji 3y ago
      Lisp is not Python or JS. People use Python and JS, not Lisp. Dynamic typing in Python and JS + medium-sized project = dumpster fire.
      - medo-bear 3y ago
        there are plenty of disaster code bases in both dynamic and static typed languages. my cause for mentioning common lisp was use of an example i personally know of where a dynamic language (albeit one with strong and static typing support available) produces some really high quality code that can stand the test of time

freedomben 3y ago

I have yet to see a project of any size that needs to be worked on by multiple teams not descend into dumpster fire. Typing can definitely help, but it's just a small tool. Java is a pretty typed language and I'm seen some real doozy code bases in Java.

kaba0 3y ago
Though that might just as well mean that typed language projects, like those in Java have actually survived long enough to have turned into that. It is easy to be maintainable at iteration 1 when the requirements haven’t changed 20 times yet.