18 ms·

Sure, that's the common argument, but static languages often require a bunch of gymnastics to get the compiler to accept valid code. They have a lot of abstract

by woah 11y ago

Sure, that's the common argument, but static languages often require a bunch of gymnastics to get the compiler to accept valid code. They have a lot of abstractions that are not even necessary in dynamic languages.

rhaps0dy 11y ago
The gymnastics part is correct. You have to convince the compiler the code you are producing is correct, even if it may be correct already. However, this makes your code way more unlikely to crash or be incorrect. The "lot of abstractions" is the distinction between type and class the article addresses, I guess?
loup-vaillant 11y ago
> static languages often require a bunch of gymnastics to get the compiler to accept valid code I'd rather do the gymnastic and have the compiler tell me where I screw up right away. That's a tighter, more accurate feedback loop than a REPL. (Source: trying to implement a simple depth first search in both Lua and Ocaml.)
- dllthomas 11y ago
  And of course, you can still have the repl :D
dragonwriter 11y ago
> Sure, that's the common argument, but static languages often require a bunch of gymnastics to get the compiler to accept valid code. There's really two problems hidden in that that deserve to be considered: (1) Static languages with insufficiently-expressive type systems may require more complex code (in terms of actual operations, not just type declarations) for the code to be valid when compared to dynamic languages (or static languages with sufficiently-expressive type systems.), and (2) static languages may, depending on the situation and the completeness of their type inference system, require arcane incantations to the type system before it accepts that correct code is, in fact, correctly typed. Some statically-typed languages are good on one or both of these measures, and so make less of one or both types of problems (Haskell, IMO, is pretty good on both, as static languages go, but lots of more popular static languages are really bad at one or both.)

by woah 11y ago

rhaps0dy 11y ago

The gymnastics part is correct. You have to convince the compiler the code you are producing is correct, even if it may be correct already. However, this makes your code way more unlikely to crash or be incorrect. The "lot of abstractions" is the distinction between type and class the article addresses, I guess?

loup-vaillant 11y ago

> static languages often require a bunch of gymnastics to get the compiler to accept valid code I'd rather do the gymnastic and have the compiler tell me where I screw up right away. That's a tighter, more accurate feedback loop than a REPL. (Source: trying to implement a simple depth first search in both Lua and Ocaml.)

dllthomas 11y ago
And of course, you can still have the repl :D

dragonwriter 11y ago

> Sure, that's the common argument, but static languages often require a bunch of gymnastics to get the compiler to accept valid code. There's really two problems hidden in that that deserve to be considered: (1) Static languages with insufficiently-expressive type systems may require more complex code (in terms of actual operations, not just type declarations) for the code to be valid when compared to dynamic languages (or static languages with sufficiently-expressive type systems.), and (2) static languages may, depending on the situation and the completeness of their type inference system, require arcane incantations to the type system before it accepts that correct code is, in fact, correctly typed. Some statically-typed languages are good on one or both of these measures, and so make less of one or both types of problems (Haskell, IMO, is pretty good on both, as static languages go, but lots of more popular static languages are really bad at one or both.)