3 ms·

This will sound simplistic but just avoid using C++. You'd have to pay me twice my current salary to go back to that language (or C).

nnq 7y ago
What are you coding it right now? Haskell? F#? OCaml/ReasonML? ...maybe Go? Or Rust? ...because in almost all other languages the issues mentioned by OP are valid! You can use "exceptions for business logic" and have invisible goto-s in your Python or C# or Java or Scala code just fine. I don't think the advice is language dependent at all, it applies to any language! Sure, with a "sufficiently advanced type system" you can have the compiler catch these kinds of errors and have wrong state unrepresentable. But in practice you either don't have that "sufficiently advanced type system", or you know that using it to prevent these errors will take a ton of extra work, or end up with something so complicated that you'd spend 80% of you brainpower wrangling abstract types algebra in your brain instead of spending that brain power son solving the actual domain problem, and have every new developer spend weeks before being productive in your overengineered system... variants of stuff like "Apps Hungarian" are often a lightweight and practical solution in any language. Also, if operators overloading is what freaks you out, try writing code heavy on matrix/vector/tensor algorithms without it... it will end up looking so ugly that you'll drown in logic bugs hidden in plain sight simply because the code looks so different from the nice math it came from that your brain is not powerful enough to diff it correctly anymore... the zero cost operator overloading abstraction in C++ can also be very powerful at preventing algorithm bugs if used in the right domain - for "solid abstraction" with sane origins in mathematics it works fine!
- dragonwriter 7y ago
  > variants of stuff like "Apps Hungarian" are often a lightweight and practical solution in any language. Except in an untyped language, the type system usually presents a better solution with no more effort than “Apps Hungarian”, and for many cases even without static typing you can enforce rules rather than do advisory annotations with similar effort (e.g., for the specific unsafe-data case addresses in the article, a Ruby's taint system.) > Also, if operators overloading is what freaks you out, try writing code heavy on matrix/vector/tensor algorithms without it... While overloading may be ideal for some subset of that, and tolerable for a larger subset, I think what that really calls for is more custom operator definition as supported I Haskell, Scala, Raku and some others more than overloading.
- ryanwinchester 7y ago
  https://hexdocs.pm/phoenix_html/Phoenix.HTML.html#module-html-safe https://hexdocs.pm/phoenix_html/Phoenix.HTML.html#module-htm...

nnq 7y ago

What are you coding it right now? Haskell? F#? OCaml/ReasonML? ...maybe Go? Or Rust? ...because in almost all other languages the issues mentioned by OP are valid! You can use "exceptions for business logic" and have invisible goto-s in your Python or C# or Java or Scala code just fine. I don't think the advice is language dependent at all, it applies to any language! Sure, with a "sufficiently advanced type system" you can have the compiler catch these kinds of errors and have wrong state unrepresentable. But in practice you either don't have that "sufficiently advanced type system", or you know that using it to prevent these errors will take a ton of extra work, or end up with something so complicated that you'd spend 80% of you brainpower wrangling abstract types algebra in your brain instead of spending that brain power son solving the actual domain problem, and have every new developer spend weeks before being productive in your overengineered system... variants of stuff like "Apps Hungarian" are often a lightweight and practical solution in any language. Also, if operators overloading is what freaks you out, try writing code heavy on matrix/vector/tensor algorithms without it... it will end up looking so ugly that you'll drown in logic bugs hidden in plain sight simply because the code looks so different from the nice math it came from that your brain is not powerful enough to diff it correctly anymore... the zero cost operator overloading abstraction in C++ can also be very powerful at preventing algorithm bugs if used in the right domain - for "solid abstraction" with sane origins in mathematics it works fine!

dragonwriter 7y ago
> variants of stuff like "Apps Hungarian" are often a lightweight and practical solution in any language. Except in an untyped language, the type system usually presents a better solution with no more effort than “Apps Hungarian”, and for many cases even without static typing you can enforce rules rather than do advisory annotations with similar effort (e.g., for the specific unsafe-data case addresses in the article, a Ruby's taint system.) > Also, if operators overloading is what freaks you out, try writing code heavy on matrix/vector/tensor algorithms without it... While overloading may be ideal for some subset of that, and tolerable for a larger subset, I think what that really calls for is more custom operator definition as supported I Haskell, Scala, Raku and some others more than overloading.
ryanwinchester 7y ago
https://hexdocs.pm/phoenix_html/Phoenix.HTML.html#module-html-safe https://hexdocs.pm/phoenix_html/Phoenix.HTML.html#module-htm...