4 ms·

i'm not drinking this kool-aid. you're in a strange place if you think it's loops that are the cause of software complexity.

smabie 6y ago
Loops are 100% the worst offenders of software complexity. Loops and tail recursion are the most powerful constructs we have, and are too powerful for the vast majority of problems. When using the principle of least power you find that a loop or tail recursive function is exceptionally rare.
- lultimouomo 6y ago
  They might be a great source of algorithmic complexity, but I would argue that by far the most part of software complexity is architectural, not algorithmic.
  - smabie 6y ago
    When you can reduce the amount of code you have to write by 100x, architecture no longer becomes important. When all programs are so short, they become very cheap. And when they become cheap, they are easy to replace and rewrite. At this point, architecture becomes irrelevant because you've removed all abstractions in the first place. If the components of your company's system never are longer than a page or two of code, rewrites become trivial, making planning for the future unnecessary. This is the real promise and value of array languages. Or put more simply, the size of a code base is the dominant factor in its complexity. Less code is less complex code, is better code. Also, loops imply mutation, which is the second biggest indicator of complexity. Mutation kills code bases and kills projects. When you decide to never use a loop and to never mutate, you're on the right path. Now the next step is to try and remove as many lines of code as humanly possible. A good way to measure how you're doing is by comparing the size of your gzipped (or zipped or whatever) codebase to its uncompressed form. If they are close in size, you know you are on the right track. Or in other words, you want the size of your code base to be close to its Kolmogorov complexity.
jodrellblank 6y ago
Less code to write, less code to read, less code to maintain, executes faster[1]. What's not to like? What about someone who thinks "if" is a big source of software complexity? https://www.youtube.com/watch?v=z43bmaMwagI https://www.youtube.com/watch?v=z43bmaMwagI - talk is "If considered harmful: How to eradicate 95% of all your bugs in one simple step - Jules May". [1] in interpreted languages, anything you can push down for the runtime to do instead of writing that same code in the interpreted language, tends to execute faster. e.g. my_string.count('c') in Python compared to a `for` loop over the characters written in Python.

smabie 6y ago

Loops are 100% the worst offenders of software complexity. Loops and tail recursion are the most powerful constructs we have, and are too powerful for the vast majority of problems. When using the principle of least power you find that a loop or tail recursive function is exceptionally rare.

lultimouomo 6y ago
They might be a great source of algorithmic complexity, but I would argue that by far the most part of software complexity is architectural, not algorithmic.
- smabie 6y ago
  When you can reduce the amount of code you have to write by 100x, architecture no longer becomes important. When all programs are so short, they become very cheap. And when they become cheap, they are easy to replace and rewrite. At this point, architecture becomes irrelevant because you've removed all abstractions in the first place. If the components of your company's system never are longer than a page or two of code, rewrites become trivial, making planning for the future unnecessary. This is the real promise and value of array languages. Or put more simply, the size of a code base is the dominant factor in its complexity. Less code is less complex code, is better code. Also, loops imply mutation, which is the second biggest indicator of complexity. Mutation kills code bases and kills projects. When you decide to never use a loop and to never mutate, you're on the right path. Now the next step is to try and remove as many lines of code as humanly possible. A good way to measure how you're doing is by comparing the size of your gzipped (or zipped or whatever) codebase to its uncompressed form. If they are close in size, you know you are on the right track. Or in other words, you want the size of your code base to be close to its Kolmogorov complexity.

jodrellblank 6y ago

Less code to write, less code to read, less code to maintain, executes faster[1]. What's not to like? What about someone who thinks "if" is a big source of software complexity? https://www.youtube.com/watch?v=z43bmaMwagI https://www.youtube.com/watch?v=z43bmaMwagI - talk is "If considered harmful: How to eradicate 95% of all your bugs in one simple step - Jules May". [1] in interpreted languages, anything you can push down for the runtime to do instead of writing that same code in the interpreted language, tends to execute faster. e.g. my_string.count('c') in Python compared to a `for` loop over the characters written in Python.