4 ms·

Maybe 100K LOC in a dynamic language is more difficult to maintain than 100K LOC in a statically typed language, but what if the same functionality requires 500

Maybe 100K LOC in a dynamic language is more difficult to maintain than 100K LOC in a statically typed language, but what if the same functionality requires 500K LOC in the statically typed language? It is easier to maintain a small code base, other things being equal.

ori_b 13y ago
Why would a dynamic language be five times shorter, given a modern statically typed language such as Haskell, Ocaml, Scala, or even Go? Even C++11 has powerful abstractions that can cut down the size of a codebase significantly.
- fleitz 13y ago
  Well for Haskell and ocaml, it's more the type inference and functional nature than the static typing that saves code. As for scala, it's not quite as functional or well typed inferred as the others... interested in what the LOC savings would be. Realistically though what's being compared is Ruby/Python vs. Java. It's much more than just the language it's the culture, java is just plain bureaucratic, a lot of routine paperwork for not a lot of functionality.
- Cthulhu_ 13y ago
  Because often 'static language' is used in place of 'Java'; pretty sure those languages are much more succinct and readable than Java is, thus they're not as likely to become 'large' codebases. I'm probably wrong though. Whenever I recall programming in Java though, I remember highly verbose, boilerplate-ridden codebases, and bits of code that are little more than abstractions for bits of code underneath them (with unit tests alongside them that test bit of code A calls functions B and C, which of course has no value whatsoever). Nowadays I do Javascript, much better. Today I frowned upon a colleague who is used to Objective-C who proposed writing documentation. Pfff.
  - kasey_junk 13y ago
    But this is a very big problem. It seems to me that the popularity of dynamic languages recently is almost entirely driven by Java backlash. So developers with limited experience encounter some big "enterprise" Java code base and recoil in horror. Instead of making the deduction that enterprise Java is terrible, they jump all the way to compile time types being horrible.
- fit2rule 13y ago
  I'd say its because its easier to get on with human-friendly abstractions in a dynamic language. For example you spend less time packing structs into something that can be used by a customer with a dynamic language. Things happen faster, if all you've got is a number, string, and table type. So, you end up with abstractions that do more.
- pnathan 13y ago
  Honestly, "statically typed language" often means C#/C++/Java. All languages which trend verbose. While Scala/Haskell/F#/etc are great at concision, they aren't that common in traditional SW industrial applications.
  - GyrosOfWar 13y ago
    Modern C# and C++ both have facilities that make the languages much more concise (lambdas in combination with std::algorithm resp. LINQ, type inference and the like). Java 8 will also have some of that and I can see it becoming a much nicer language to work with because of those changes.
    - pnathan 13y ago
      Quite correct. But historically - and worse, codebases with a Standard Style that is perhaps older - these languages trend verbose. IME, I've tried to make super concise modern C#, and it simply isn't concise compared to Haskell or even Python. YMMV, of course.
  - _random_ 13y ago
    1. C# is not as verbose as Java and C++. Latest versions especially. 2. C# supports dynamic typing as well as static. 3. C# and F# are the easiest to mix and match within one solution.
    - marcosdumay 13y ago
      > C# supports dynamic typing as well as static. Are you talking about automatic types? Because that's the only thing that resembles dynamic typing I ever found in C#. And it misses about all the reflection available in most dynamic types languages, thus, even if it's somehow possible to not define types, it's useless.
      - danbruc 13y ago
        C# fully supports dynamic types [1] and has very good reflection support [2] since version one. [1] http://msdn.microsoft.com/en-us/library/dd264736.aspx http://msdn.microsoft.com/en-us/library/dd264736.aspx [2] http://msdn.microsoft.com/en-us/library/system.type.aspx http://msdn.microsoft.com/en-us/library/system.type.aspx
dnd 13y ago
LoC is already a poor measure, but if a good effort at solving a problem meant you ended up with 500K LoC in a static language, and you could somehow know that solving the same problem in a dynamic language would have produced just 100K, the take away there is that in that instance you probably chose the wrong tool. I don't think it says too much about static vs dynamic languages and maintaining a given size program over time.
asdasf 13y ago
Maybe 100K LOC in a static language is more difficult to maintain than 100K LOC in a dynamically typed language, but what if the same functionality requires 500K LOC in the dynamically typed language?

ori_b 13y ago

Why would a dynamic language be five times shorter, given a modern statically typed language such as Haskell, Ocaml, Scala, or even Go? Even C++11 has powerful abstractions that can cut down the size of a codebase significantly.

fleitz 13y ago
Well for Haskell and ocaml, it's more the type inference and functional nature than the static typing that saves code. As for scala, it's not quite as functional or well typed inferred as the others... interested in what the LOC savings would be. Realistically though what's being compared is Ruby/Python vs. Java. It's much more than just the language it's the culture, java is just plain bureaucratic, a lot of routine paperwork for not a lot of functionality.
Cthulhu_ 13y ago
Because often 'static language' is used in place of 'Java'; pretty sure those languages are much more succinct and readable than Java is, thus they're not as likely to become 'large' codebases. I'm probably wrong though. Whenever I recall programming in Java though, I remember highly verbose, boilerplate-ridden codebases, and bits of code that are little more than abstractions for bits of code underneath them (with unit tests alongside them that test bit of code A calls functions B and C, which of course has no value whatsoever). Nowadays I do Javascript, much better. Today I frowned upon a colleague who is used to Objective-C who proposed writing documentation. Pfff.
- kasey_junk 13y ago
  But this is a very big problem. It seems to me that the popularity of dynamic languages recently is almost entirely driven by Java backlash. So developers with limited experience encounter some big "enterprise" Java code base and recoil in horror. Instead of making the deduction that enterprise Java is terrible, they jump all the way to compile time types being horrible.
fit2rule 13y ago
I'd say its because its easier to get on with human-friendly abstractions in a dynamic language. For example you spend less time packing structs into something that can be used by a customer with a dynamic language. Things happen faster, if all you've got is a number, string, and table type. So, you end up with abstractions that do more.
pnathan 13y ago
Honestly, "statically typed language" often means C#/C++/Java. All languages which trend verbose. While Scala/Haskell/F#/etc are great at concision, they aren't that common in traditional SW industrial applications.
- GyrosOfWar 13y ago
  Modern C# and C++ both have facilities that make the languages much more concise (lambdas in combination with std::algorithm resp. LINQ, type inference and the like). Java 8 will also have some of that and I can see it becoming a much nicer language to work with because of those changes.
  - pnathan 13y ago
    Quite correct. But historically - and worse, codebases with a Standard Style that is perhaps older - these languages trend verbose. IME, I've tried to make super concise modern C#, and it simply isn't concise compared to Haskell or even Python. YMMV, of course.
- _random_ 13y ago
  1. C# is not as verbose as Java and C++. Latest versions especially. 2. C# supports dynamic typing as well as static. 3. C# and F# are the easiest to mix and match within one solution.
  - marcosdumay 13y ago
    > C# supports dynamic typing as well as static. Are you talking about automatic types? Because that's the only thing that resembles dynamic typing I ever found in C#. And it misses about all the reflection available in most dynamic types languages, thus, even if it's somehow possible to not define types, it's useless.
    - danbruc 13y ago
      C# fully supports dynamic types [1] and has very good reflection support [2] since version one. [1] http://msdn.microsoft.com/en-us/library/dd264736.aspx http://msdn.microsoft.com/en-us/library/dd264736.aspx [2] http://msdn.microsoft.com/en-us/library/system.type.aspx http://msdn.microsoft.com/en-us/library/system.type.aspx

dnd 13y ago

LoC is already a poor measure, but if a good effort at solving a problem meant you ended up with 500K LoC in a static language, and you could somehow know that solving the same problem in a dynamic language would have produced just 100K, the take away there is that in that instance you probably chose the wrong tool. I don't think it says too much about static vs dynamic languages and maintaining a given size program over time.

asdasf 13y ago

Maybe 100K LOC in a static language is more difficult to maintain than 100K LOC in a dynamically typed language, but what if the same functionality requires 500K LOC in the dynamically typed language?