4 ms·

> But that's a pretty out-of-date take Gradual/optional static typing are not new ideias. It’s just that they are fashionable now. It used to be that not havi

> But that's a pretty out-of-date take Gradual/optional static typing are not new ideias. It’s just that they are fashionable now. It used to be that not having to deal with types at all was the cool place to be in. Our computers were getting so much faster every year, why would performance be a concern? Programmers are more productive in dynamic languages and computer time is cheap, etc, etc. The “correctness” pitch, the required for larger projects, compiletime vs runtime errors are all discussable, even though they are often thrown in the conversation as irrefutable advantages of static typing. The performance angle, not so much. Static will almost always be faster then dynamic typing, even with all the crazy tricks we’ve developed over the decades.

fastball 5y ago
When it comes to code, I'm fairly certain "correctness" is in fact an irrefutable advantage. The argument has always been whether or not the price of that correctness is too high. But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do. At least with TypeScript in VSCode.
- DeathArrow 5y ago
  With Visual Studio also. Intellisense works wonders.
- deleted 5y ago
  [deleted]
- dragonwriter 5y ago
  > The argument has always been whether or not the price of that correctness is too high. No. I mean, that's been part of the argument, but so has whether static typing actually gave you useful correctness. Many static languages have had type systems that are more designed around convenience of compilation (and performance of compiled code) than correctness; the type systems of the optional typecheckers of modern dynamic languages are leaps and bounds better than static type systems of most popular static languages a couple decades ago, and have been for some time. > But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do. If you have good inference, statically typed and dynamically typed code is virtually indistinguishable TypeProf-IDE for Ruby, discussed in TFA, generates type signatures by inference from plain Ruby code.
  - eropple 5y ago
    Strong disagree with the idea that dynamic inference steps to static declarations, particularly for Ruby and especially if you're using anything that expects you to write code inside of its DSL. The inference tends to fall off and because it isn't expected of you, nobody's doing anything to help there. Maybe Rails is special-cased enough to get away with it, but I still maintain a project in Grape and none of the autocomplete solutions I have found for Ruby help significantly at all. Meanwhile over in TypeScript, I literally can't remember the last time I used `any` or `unknown` except at a module's edge during validation of untrusted input, and autocomplete is awesome.
- Mikeb85 5y ago
  > it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do. Ruby has a pretty nice language server, nice linter, REPL (Pry), many other tools. The best development experience IMO is still stuff like SLIME or Smalltalk environments. "Intellisence" just makes using statically typed languages bearable. It's not a unique feature.
  - kaba0 5y ago
    Intellisense will allow you to do explorative programming, finding what method is callable on a given object. It’s much easier to look up n methods than to try to guess what is the whole state of the program where it may accept this and that, where even in the best case you might get a fraction of what a statically typed language’s autocompletion allows for. Like just seriously try intellij with java and pycharm for a php code.
    - Mikeb85 5y ago
      Ruby has (always had) a REPL and .methods gives you all possible methods you can call on an object. Editors with completion have been around forever too. "Intellisence" is just what MS calls it. It's not unique to statically typed languages. Completion has existed for dynamic languages probably longer than I've been alive. In fact, the reason tooling for Java/C# is so good is because the VM can feed it info as it's running, since even though the language is static the runtime is dynamic.
      - kaba0 5y ago
        Please try one out, the difference in quality is staggering. Also, .methods is a runtime thing, that’s hardly useful. Of course at runtime you must know the available methods.
        Mikeb85 5y ago
        I do write code in statically typed languages (C++, Haskell, have done Java before, etc...). > Also, .methods is a runtime thing, that’s hardly useful I think you missed the whole point of a REPL and dynamic languages... Developing while program is running = runtime things are definitely useful, they provide instant feedback (including completions, linting, that sort of thing).
- tambourine_man 5y ago
  That’s why I used correctness in quotes, because it’s no guarantee.
  - fastball 5y ago
    It's not a guarantee, but an environment/language that yells at you when you try to pass a boolean to a function that should only ever accept a string is going to result in a more correct program than one that just... doesn't say anything and lets you happily do things that make zero sense.
HeyImAlex 5y ago
It’s not that they’re fashionable, it’s that their ergonomics have improved significantly over the past decade. I saw dynamic types as a response to cumbersome static type systems, but increasingly type systems are becoming more expressive and less cumbersome.
- eldavido 5y ago
  Yeah, this is how I see it, too. Sort of a gradual convergence. On the static side, Java and especially C# are simply _better_ than they used to be. Type inference is great - I can just write var x = new List<Thing>() rather than having to stupidly repeat the type e.g. List<Thing> x = new List<Thing>(). Add in generics, and lambdas, and about a dozen other things that have now become widespread, and it's really a different game than 10 years ago. Coming the other way, I never expected to see Intellisense-like autocompletion for languages like Ruby or Python. It honestly feels magical. Refactoring has gotten much better to where I can pull methods up and down inheritance chains using PyCharm or other mainstream IDEs. I actually think it's mobile that's pushed people back toward static. Swift, ObjC, Java, and Kotlin are all static and there's less emphasis on this "one language" idea that drove a lot of people toward trying to use the same language (JS/TS) for their React front-ends and node backends.
  - bcrosby95 5y ago
    But C# has had everything you've listed for over 10 years. Along with a great IDE that has provided very useful intellisense since pretty much the beginning.
    - eropple 5y ago
      You couldn't (easily) use C# to write the frontend for a web application that you wanted to use as either a developer or a user, though (which is to say sit down, ASP.NET Web Pages, nobody ever liked you). That's the lock that TypeScript turns, IMO.
      - bcrosby95 5y ago
DeathArrow 5y ago
You might not care about types but the computer you are running your code on, cares very much.
- islon 5y ago
  Are they releasing processors with typed registers now? AFAIK registers and assembly is untyped.
- phendrenad2 5y ago
  That's true, however I think you're misunderstanding how languages work. The Ruby interpreter knows the "type" of everything. How could it not? It was there when you defined a variable, and it was there when you added data to it. It's there when you define interfaces and other things that might affect the type of something. It's perfectly capable of holding all of that information. And there's no meaningful difference between parsing "int x = 3;" and "var x = 3;" in a program.
hajile 5y ago
> Gradual/optional static typing are not new ideias. It’s just that they are fashionable now. I'd add that Common Lisp has had optional type hints (as both documentation and performance improvement) for getting close to 40 years now.

fastball 5y ago

When it comes to code, I'm fairly certain "correctness" is in fact an irrefutable advantage. The argument has always been whether or not the price of that correctness is too high. But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do. At least with TypeScript in VSCode.

DeathArrow 5y ago
With Visual Studio also. Intellisense works wonders.
deleted 5y ago
[deleted]
dragonwriter 5y ago
> The argument has always been whether or not the price of that correctness is too high. No. I mean, that's been part of the argument, but so has whether static typing actually gave you useful correctness. Many static languages have had type systems that are more designed around convenience of compilation (and performance of compiled code) than correctness; the type systems of the optional typecheckers of modern dynamic languages are leaps and bounds better than static type systems of most popular static languages a couple decades ago, and have been for some time. > But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do. If you have good inference, statically typed and dynamically typed code is virtually indistinguishable TypeProf-IDE for Ruby, discussed in TFA, generates type signatures by inference from plain Ruby code.
- eropple 5y ago
  Strong disagree with the idea that dynamic inference steps to static declarations, particularly for Ruby and especially if you're using anything that expects you to write code inside of its DSL. The inference tends to fall off and because it isn't expected of you, nobody's doing anything to help there. Maybe Rails is special-cased enough to get away with it, but I still maintain a project in Grape and none of the autocomplete solutions I have found for Ruby help significantly at all. Meanwhile over in TypeScript, I literally can't remember the last time I used `any` or `unknown` except at a module's edge during validation of untrusted input, and autocomplete is awesome.
Mikeb85 5y ago
> it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do. Ruby has a pretty nice language server, nice linter, REPL (Pry), many other tools. The best development experience IMO is still stuff like SLIME or Smalltalk environments. "Intellisence" just makes using statically typed languages bearable. It's not a unique feature.
- kaba0 5y ago
  Intellisense will allow you to do explorative programming, finding what method is callable on a given object. It’s much easier to look up n methods than to try to guess what is the whole state of the program where it may accept this and that, where even in the best case you might get a fraction of what a statically typed language’s autocompletion allows for. Like just seriously try intellij with java and pycharm for a php code.
  - Mikeb85 5y ago
    Ruby has (always had) a REPL and .methods gives you all possible methods you can call on an object. Editors with completion have been around forever too. "Intellisence" is just what MS calls it. It's not unique to statically typed languages. Completion has existed for dynamic languages probably longer than I've been alive. In fact, the reason tooling for Java/C# is so good is because the VM can feed it info as it's running, since even though the language is static the runtime is dynamic.
    - kaba0 5y ago
      Please try one out, the difference in quality is staggering. Also, .methods is a runtime thing, that’s hardly useful. Of course at runtime you must know the available methods.
      - Mikeb85 5y ago
        I do write code in statically typed languages (C++, Haskell, have done Java before, etc...). > Also, .methods is a runtime thing, that’s hardly useful I think you missed the whole point of a REPL and dynamic languages... Developing while program is running = runtime things are definitely useful, they provide instant feedback (including completions, linting, that sort of thing).
tambourine_man 5y ago
That’s why I used correctness in quotes, because it’s no guarantee.
- fastball 5y ago
  It's not a guarantee, but an environment/language that yells at you when you try to pass a boolean to a function that should only ever accept a string is going to result in a more correct program than one that just... doesn't say anything and lets you happily do things that make zero sense.

HeyImAlex 5y ago

It’s not that they’re fashionable, it’s that their ergonomics have improved significantly over the past decade. I saw dynamic types as a response to cumbersome static type systems, but increasingly type systems are becoming more expressive and less cumbersome.

eldavido 5y ago
Yeah, this is how I see it, too. Sort of a gradual convergence. On the static side, Java and especially C# are simply _better_ than they used to be. Type inference is great - I can just write var x = new List<Thing>() rather than having to stupidly repeat the type e.g. List<Thing> x = new List<Thing>(). Add in generics, and lambdas, and about a dozen other things that have now become widespread, and it's really a different game than 10 years ago. Coming the other way, I never expected to see Intellisense-like autocompletion for languages like Ruby or Python. It honestly feels magical. Refactoring has gotten much better to where I can pull methods up and down inheritance chains using PyCharm or other mainstream IDEs. I actually think it's mobile that's pushed people back toward static. Swift, ObjC, Java, and Kotlin are all static and there's less emphasis on this "one language" idea that drove a lot of people toward trying to use the same language (JS/TS) for their React front-ends and node backends.
- bcrosby95 5y ago
  But C# has had everything you've listed for over 10 years. Along with a great IDE that has provided very useful intellisense since pretty much the beginning.
  - eropple 5y ago
    You couldn't (easily) use C# to write the frontend for a web application that you wanted to use as either a developer or a user, though (which is to say sit down, ASP.NET Web Pages, nobody ever liked you). That's the lock that TypeScript turns, IMO.
    - bcrosby95 5y ago

DeathArrow 5y ago

You might not care about types but the computer you are running your code on, cares very much.

islon 5y ago
Are they releasing processors with typed registers now? AFAIK registers and assembly is untyped.
phendrenad2 5y ago
That's true, however I think you're misunderstanding how languages work. The Ruby interpreter knows the "type" of everything. How could it not? It was there when you defined a variable, and it was there when you added data to it. It's there when you define interfaces and other things that might affect the type of something. It's perfectly capable of holding all of that information. And there's no meaningful difference between parsing "int x = 3;" and "var x = 3;" in a program.

hajile 5y ago

> Gradual/optional static typing are not new ideias. It’s just that they are fashionable now. I'd add that Common Lisp has had optional type hints (as both documentation and performance improvement) for getting close to 40 years now.