5 ms·

The simpler the language the better it is for complex code. Heavy abstractions won't help another reader of your code understand what's going on. In most cases

by tensor 6y ago

The simpler the language the better it is for complex code. Heavy abstractions won't help another reader of your code understand what's going on. In most cases it means it will take them much longer to understand. Concise code with heavy abstraction can help eliminate errors, but it definitely doesn't make reading it easier. It also doesn't make solving problems any easier. Solving problems is all about algorithms and data structures, not the language you are using.

nine_k 6y ago
I suggest you try and implement some complex but well-defined algorithm, e.g. sha256, in some very, very simple language, say, brainfuck (which is very close to the original Turing machine language). Or, more realistically, in PDP11 assembly, which is beautifully transparent and uniform. You might then notice that there is some kind of sweet spot in complexity: fewer features and footguns than, say, C++, but more features and abstractions than machine code.
- nullc 6y ago
  SHA256 is a fixed circuit. It's a particularly weird thing to implement. Other than it being a bit long, it's not complex to implement, even on a calculator. If you want an example of something moderately complex but well defined, go implement a min-heap or some other basic algorithm.
valenterry 6y ago
Cool - let's write everthing in Assembly or Brainfuck! It is great for "complex code", right?
wirrbel 6y ago
Rich Hickey[] has a nice talk "Simple made easy", where he differentiates between exes, the simple-complex axis and the easy-hard axis. By his definitions, you can kind of strive for easiness but get complexity, and if you aim for simplicity it may be hard. His point is, that you'd much prefer simple-hard over something 'easy' that leads to incidental complexity. I feel like Go isn't so much aiming for simlicity but actually for easiness in that line of thought, and thus its only a matter of time until complexity is encoded within the Go code. Now, aiming for simplicity is not easy, at times definitely hard but it can lead to actual simplicity. [] obligatory note that while I like this talk I don't agree with all of his utterances.
novok 6y ago
Code that requires codegen or some verbose structure to express some constraint or idea that could be expressed in a sentence or two or a simple oneliner with the right abstraction can actually be harder to read because of the miles of boilerplate you have dive through. Ex doing string processing in python vs golang. In golang or java even it's far more lines of code and far harder to understand.

by tensor 6y ago

nine_k 6y ago

I suggest you try and implement some complex but well-defined algorithm, e.g. sha256, in some very, very simple language, say, brainfuck (which is very close to the original Turing machine language). Or, more realistically, in PDP11 assembly, which is beautifully transparent and uniform. You might then notice that there is some kind of sweet spot in complexity: fewer features and footguns than, say, C++, but more features and abstractions than machine code.

nullc 6y ago
SHA256 is a fixed circuit. It's a particularly weird thing to implement. Other than it being a bit long, it's not complex to implement, even on a calculator. If you want an example of something moderately complex but well defined, go implement a min-heap or some other basic algorithm.

valenterry 6y ago

Cool - let's write everthing in Assembly or Brainfuck! It is great for "complex code", right?

wirrbel 6y ago

Rich Hickey[] has a nice talk "Simple made easy", where he differentiates between exes, the simple-complex axis and the easy-hard axis. By his definitions, you can kind of strive for easiness but get complexity, and if you aim for simplicity it may be hard. His point is, that you'd much prefer simple-hard over something 'easy' that leads to incidental complexity. I feel like Go isn't so much aiming for simlicity but actually for easiness in that line of thought, and thus its only a matter of time until complexity is encoded within the Go code. Now, aiming for simplicity is not easy, at times definitely hard but it can lead to actual simplicity. [] obligatory note that while I like this talk I don't agree with all of his utterances.

novok 6y ago

Code that requires codegen or some verbose structure to express some constraint or idea that could be expressed in a sentence or two or a simple oneliner with the right abstraction can actually be harder to read because of the miles of boilerplate you have dive through. Ex doing string processing in python vs golang. In golang or java even it's far more lines of code and far harder to understand.