4 ms·

> they should be capable of leveraging powerful programming language features to massively increase developer productivity, right? Here you are claiming that l

> they should be capable of leveraging powerful programming language features to massively increase developer productivity, right? Here you are claiming that leveraging powerful language features can massively increase developer productivity, but you offer no evidence to back up that claim.

nnq 7y ago
- powerful features -> less code to do something -> less bugs because less code - powerful features -> more general abstractions -> more code reuse -> less new code written -> less bugs It's not that simple, but it's good to start with the core assumption that less code -> less bugs and what more powerful languages offer you is ability to solve problems with less code while at the same time keeping that more compact code readable. Or maybe big software-focused companies like G don't see "# of LOC" as a liability and don't try to reduce it while at the same time as trying to do more? Is this the core difference between a large corporation and a small startup that tries to do more with less?
- codegladiator 7y ago
  > core assumption that less code -> less bugs This assumption is false. Either the flows are written in code, are you have to have them in your brain every time you are reading some code which can handle 10 flows. > solve problems with less code while at the same time keeping that more compact code readable Less code means less readable.
  - nitely 7y ago
    > This assumption is false. Either the flows are written in code, are you have to have them in your brain every time you are reading some code which can handle 10 flows. No, it's not. Your interpretation of it is wrong, though. No code means no bugs, this is true. Now, write a new feature, unless the code is flawless, the code-base will certainly have more bugs than before, this is true. Now, write a linked-list, unless the code is flawless, the code-base will have more bugs than if using the one in the language std-lib. About language features, writing 5 implementations of a linked-list for each type instead of a generic one that it's type checked will certainly contain more bugs as it's more error prone to write the same things 5 times and keep it updated. > Less code means less readable. This is ridiculous. Otherwise, we'd all be using assembly. About Go, the lack of generics and simple error propagation is detrimental to being readable. Every function can fail, you don't say!. You're manually propagating the error instead of handling it here, you don't say!. That's what I think every time I go through some Go code-base.
- seanhunter 7y ago
  The obvious counter-example to the claim that less code means fewer bugs is kdb/q. It is an extremely powerful and terse language but you can write an astonishing density of bugs per line of code.
  - nnq 7y ago
    really? I thought ppl use APL-family languages bc they allow to express things in very little code so there's more chance of getting it right?...
    - karmakaze 7y ago
      I don't know about if it works by chance, but I've heard of someone working for two years to get two short lines of APL 'right'.
sullyj3 7y ago
I think this is true in the case of the individual developer who has some level of understanding of and ownership over their entire codebase. This is no longer true when you're working in medium to large teams, like google is.

nnq 7y ago

- powerful features -> less code to do something -> less bugs because less code - powerful features -> more general abstractions -> more code reuse -> less new code written -> less bugs It's not that simple, but it's good to start with the core assumption that less code -> less bugs and what more powerful languages offer you is ability to solve problems with less code while at the same time keeping that more compact code readable. Or maybe big software-focused companies like G don't see "# of LOC" as a liability and don't try to reduce it while at the same time as trying to do more? Is this the core difference between a large corporation and a small startup that tries to do more with less?

codegladiator 7y ago
> core assumption that less code -> less bugs This assumption is false. Either the flows are written in code, are you have to have them in your brain every time you are reading some code which can handle 10 flows. > solve problems with less code while at the same time keeping that more compact code readable Less code means less readable.
- nitely 7y ago
  > This assumption is false. Either the flows are written in code, are you have to have them in your brain every time you are reading some code which can handle 10 flows. No, it's not. Your interpretation of it is wrong, though. No code means no bugs, this is true. Now, write a new feature, unless the code is flawless, the code-base will certainly have more bugs than before, this is true. Now, write a linked-list, unless the code is flawless, the code-base will have more bugs than if using the one in the language std-lib. About language features, writing 5 implementations of a linked-list for each type instead of a generic one that it's type checked will certainly contain more bugs as it's more error prone to write the same things 5 times and keep it updated. > Less code means less readable. This is ridiculous. Otherwise, we'd all be using assembly. About Go, the lack of generics and simple error propagation is detrimental to being readable. Every function can fail, you don't say!. You're manually propagating the error instead of handling it here, you don't say!. That's what I think every time I go through some Go code-base.
seanhunter 7y ago
The obvious counter-example to the claim that less code means fewer bugs is kdb/q. It is an extremely powerful and terse language but you can write an astonishing density of bugs per line of code.
- nnq 7y ago
  really? I thought ppl use APL-family languages bc they allow to express things in very little code so there's more chance of getting it right?...
  - karmakaze 7y ago
    I don't know about if it works by chance, but I've heard of someone working for two years to get two short lines of APL 'right'.

sullyj3 7y ago

I think this is true in the case of the individual developer who has some level of understanding of and ownership over their entire codebase. This is no longer true when you're working in medium to large teams, like google is.