3 ms·

Interesting read. I do take issue with the simultaneous statements that spaghetti code is unavoidable, and programs written in the language are easy to read.

by dusted 4y ago

Interesting read. I do take issue with the simultaneous statements that spaghetti code is unavoidable, and programs written in the language are easy to read. It's either one, or the other, they're mutually exclusive.

valenterry 4y ago
I'll explain. Cobol is a simple language in the same way that Go is also a simple language. Even though they are very different of course, in both languages a single statement or even a small piece of code (like a single line) is easy to read and understand. This is nice for beginners who are still struggling with basic concepts. It allows to understand code incrementally. But that does not mean that whole programs are also (comparibly!) easy to read. No, it is the opposite. If two languages are equally well made, but one focusses on small parts being easy to understand while the other one focusses on being very expressive, then a well-versed developer will have a much easier time with the more complex language. But an inexperienced one will struggle and have a much higher learning curve. It is really a tradeoff. Similar to archiving files. You can choose to compress them very small, but this will cost more CPU and time (requires complex algorithms in many cases, see video-compression and potentially multiple passes) but decrease filesize. You can also choose low compression but a simple and fast one-pass algorithm can be used here. Neither is inherental good or bad and it explains why people call languages simple or easy and others disagree. Because they are really talking about two different aspects.
- dusted 4y ago
  Thank you for clarifying, I don't think I'm entirely convinced though, a language can be both easy to read and provide a way to avoid that larger code-bases turn into spaghetti. I don't think there needs to be any tradeoff in the language itself for this. There will be tradeoffs in the complexity of programs to avoid it, but that seems to be true no matter the language. Of course, the languages that are both easy to get started with, and at the same time, powerful enough for large systems to be written, result in a lot of very terrible programs, not because they are _bad_languages_(tm) but because they're a perfect balance between ease-of-use, flexibility and power to expand.
  - valenterry 4y ago
    > a language can be both easy to read and provide a way to avoid that larger code-bases turn into spaghetti. "easy" is always relative, so compared to what? Compared to a language that isn't well crafted? Sure. And in practice, most languages could be optimized a lot. But that is not what I was talking about and thinking like that only distracts you from the bigger picture.

by dusted 4y ago

valenterry 4y ago

I'll explain. Cobol is a simple language in the same way that Go is also a simple language. Even though they are very different of course, in both languages a single statement or even a small piece of code (like a single line) is easy to read and understand. This is nice for beginners who are still struggling with basic concepts. It allows to understand code incrementally. But that does not mean that whole programs are also (comparibly!) easy to read. No, it is the opposite. If two languages are equally well made, but one focusses on small parts being easy to understand while the other one focusses on being very expressive, then a well-versed developer will have a much easier time with the more complex language. But an inexperienced one will struggle and have a much higher learning curve. It is really a tradeoff. Similar to archiving files. You can choose to compress them very small, but this will cost more CPU and time (requires complex algorithms in many cases, see video-compression and potentially multiple passes) but decrease filesize. You can also choose low compression but a simple and fast one-pass algorithm can be used here. Neither is inherental good or bad and it explains why people call languages simple or easy and others disagree. Because they are really talking about two different aspects.

dusted 4y ago
Thank you for clarifying, I don't think I'm entirely convinced though, a language can be both easy to read and provide a way to avoid that larger code-bases turn into spaghetti. I don't think there needs to be any tradeoff in the language itself for this. There will be tradeoffs in the complexity of programs to avoid it, but that seems to be true no matter the language. Of course, the languages that are both easy to get started with, and at the same time, powerful enough for large systems to be written, result in a lot of very terrible programs, not because they are _bad_languages_(tm) but because they're a perfect balance between ease-of-use, flexibility and power to expand.
- valenterry 4y ago
  > a language can be both easy to read and provide a way to avoid that larger code-bases turn into spaghetti. "easy" is always relative, so compared to what? Compared to a language that isn't well crafted? Sure. And in practice, most languages could be optimized a lot. But that is not what I was talking about and thinking like that only distracts you from the bigger picture.