3 ms·

No true Scotsman. >Because it's easy There are lots of cases when forcing yourself to stick to OOP styles or programming is much less easy. You could look at

No true Scotsman. >Because it's easy There are lots of cases when forcing yourself to stick to OOP styles or programming is much less easy. You could look at various comparisons of code line counts of equivalent programs between C# and F# code as some basic examples. I don't mind having classes that can inherit available in a language, but languages like Java and C# that force you to use only those things leads to a lot of unecessary boilerplate. You can work around this with static classes full of static functions that you can treat as 'modules' full of free functions. Which, is what I do a lot :D But I wish I didn't have to bother with that workaround.

mpweiher 8y ago
> You could look at various comparisons of code line counts of equivalent programs between C# and F# code as some basic examples. People have done this methodically, and the results may surprise you: http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm That's the one from 1996, there was a newer one that pretty much confirmed the results.
scarface74 8y ago
I agree. Even in Domain Driven Design, sometimes you just have transaction scripts. Call a spade a spade and write your code accordingly.
zippy5 8y ago
I would suggest that boilerplate is small price to pay for having a compiler enforce design discipline and conventions. Remember that code should be written for both the run time environment and next coder who will have to understand it. Constraints enforced in java often make it easier for the next dev. I suspect part of this is that in unconstrained languages, there are so many ways of doing the same thing that pattern recognition become more difficult for all but the most experienced programmers.
- naasking 8y ago
  > pattern recognition become more difficult for all but the most experienced programmers. In fact the opposite is the case. The boilerplate obscures underlying patterns because it forces you to read twice as much to infer the same amount of information. Roughly the same design patterns are used in more expressive languages, just without all the boilerplate. This makes the pattern being employed completely obvious since it's only a few lines of code.
  - scarface74 8y ago
    Once you use a language for awhile you develop boilerplate blindness just like people have developed ad banner blindness.
    - naasking 8y ago
      I'm sure, and yet it remains true that you spend a lot more time scanning and scrolling your wheel mouse than is necessary. You can also fit far less context on screen, making debugging and "learnability" harder.
      - scarface74 8y ago
        There is overhead but with that overhead becomes maintainability, type safety, etc. For me, on one side is Python. No compiler overhead, very little boilerplate, no complicated IDE etc but no type safety and harder to maintain for larger projects and C# with all of the overhead of a heavyweight compiler but the type safety and great IDE makes it perfect for larger projects where multiple people will be working on it simultaneously. For simple scripting, where can I mentally keep everything in my head and think through how one change will affect everything else, Python is my go to language. For larger projects C#. I’ve hated all scripting languages I’ve encountered over 20 years, but for some reason I love Python. It’s also a great teaching language.
        naasking 8y ago
        I agree Python is good for teaching, but the maintainability and type safety aren't features of the boilerplate. This is clear when considering languages like OCaml, Haskell and other languages featuring type inference.
- Paradigma11 8y ago
  To go with the above example of c# vs f#. I find f# far easier to understand because the compiler enforces a strict top down compilation order. Combined with the encouraged basic type system (records and DU) this enforces a very rigid design structure that is easy to understand. Compared to that c# is a ball of wool where not only have you to follow all strands but also understand when something will happen.

mpweiher 8y ago

> You could look at various comparisons of code line counts of equivalent programs between C# and F# code as some basic examples. People have done this methodically, and the results may surprise you: http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm That's the one from 1996, there was a newer one that pretty much confirmed the results.

scarface74 8y ago

I agree. Even in Domain Driven Design, sometimes you just have transaction scripts. Call a spade a spade and write your code accordingly.

zippy5 8y ago

I would suggest that boilerplate is small price to pay for having a compiler enforce design discipline and conventions. Remember that code should be written for both the run time environment and next coder who will have to understand it. Constraints enforced in java often make it easier for the next dev. I suspect part of this is that in unconstrained languages, there are so many ways of doing the same thing that pattern recognition become more difficult for all but the most experienced programmers.

naasking 8y ago
> pattern recognition become more difficult for all but the most experienced programmers. In fact the opposite is the case. The boilerplate obscures underlying patterns because it forces you to read twice as much to infer the same amount of information. Roughly the same design patterns are used in more expressive languages, just without all the boilerplate. This makes the pattern being employed completely obvious since it's only a few lines of code.
- scarface74 8y ago
  Once you use a language for awhile you develop boilerplate blindness just like people have developed ad banner blindness.
  - naasking 8y ago
    I'm sure, and yet it remains true that you spend a lot more time scanning and scrolling your wheel mouse than is necessary. You can also fit far less context on screen, making debugging and "learnability" harder.
    - scarface74 8y ago
      There is overhead but with that overhead becomes maintainability, type safety, etc. For me, on one side is Python. No compiler overhead, very little boilerplate, no complicated IDE etc but no type safety and harder to maintain for larger projects and C# with all of the overhead of a heavyweight compiler but the type safety and great IDE makes it perfect for larger projects where multiple people will be working on it simultaneously. For simple scripting, where can I mentally keep everything in my head and think through how one change will affect everything else, Python is my go to language. For larger projects C#. I’ve hated all scripting languages I’ve encountered over 20 years, but for some reason I love Python. It’s also a great teaching language.
      - naasking 8y ago
        I agree Python is good for teaching, but the maintainability and type safety aren't features of the boilerplate. This is clear when considering languages like OCaml, Haskell and other languages featuring type inference.
Paradigma11 8y ago
To go with the above example of c# vs f#. I find f# far easier to understand because the compiler enforces a strict top down compilation order. Combined with the encouraged basic type system (records and DU) this enforces a very rigid design structure that is easy to understand. Compared to that c# is a ball of wool where not only have you to follow all strands but also understand when something will happen.