4 ms·

That works well for simple programs, but if you write at scale, that style of programming is very error prone and tedious. It introduces a lot of noise into th

That works well for simple programs, but if you write at scale, that style of programming is very error prone and tedious. It introduces a lot of noise into the program and makes it harder to follow the logic. If you don't lift yourself into higher levels of abstraction, it's much harder to focus on more difficult problems. For example, long division with Roman Numerals is more difficult than Arabic because there are simply more low level details to worry about.

vikingcaffiene 7y ago
Ah yes long division of Roman numerals. Can’t count the number of times that’s come up...
turdnagel 7y ago
This appears to me to be a matter of personal preference rather than fact; could you explain what you mean by "error prone and tedious"?
- bcheung 7y ago
  Sure. The more things the programmer needs to worry about and explicitly state, then there more pathways there are for error. Using assembly language vs a higher level language illustrates this. There are certain classes of errors that are eliminated by the language / compiler / runtime. Examples could be garbage collection preventing you from have page segmentation faults, or accidentally modifying the stack pointer and destroying the return address. Rich types like Maybe / Either offload the exception handling and allow you to write your code for just the happy path while still having the program fully support the unhappy path. Compilers with pattern matching can give you errors when you have not handled all possible inputs to a function (total function). If you just have the "if err != nil" or null-check style code then it's easy to miss them. By tedious, if you constantly have to type the same thing over and over ("if err != nil") then it takes away time and mental energy from focusing on the core problem domain. Being able to express guard conditions to a function allow your functions to be simpler and easier to understand. It basically allow comes down to abstraction and letting the compiler / language do things that it is good at and freeing the programmer from having to worry about every single permutation. It's just not feasible for the human mind to see every possible branch of a program.

vikingcaffiene 7y ago

Ah yes long division of Roman numerals. Can’t count the number of times that’s come up...

turdnagel 7y ago

This appears to me to be a matter of personal preference rather than fact; could you explain what you mean by "error prone and tedious"?

bcheung 7y ago
Sure. The more things the programmer needs to worry about and explicitly state, then there more pathways there are for error. Using assembly language vs a higher level language illustrates this. There are certain classes of errors that are eliminated by the language / compiler / runtime. Examples could be garbage collection preventing you from have page segmentation faults, or accidentally modifying the stack pointer and destroying the return address. Rich types like Maybe / Either offload the exception handling and allow you to write your code for just the happy path while still having the program fully support the unhappy path. Compilers with pattern matching can give you errors when you have not handled all possible inputs to a function (total function). If you just have the "if err != nil" or null-check style code then it's easy to miss them. By tedious, if you constantly have to type the same thing over and over ("if err != nil") then it takes away time and mental energy from focusing on the core problem domain. Being able to express guard conditions to a function allow your functions to be simpler and easier to understand. It basically allow comes down to abstraction and letting the compiler / language do things that it is good at and freeing the programmer from having to worry about every single permutation. It's just not feasible for the human mind to see every possible branch of a program.