6 ms·

One person's clever is another person's clear and vice versa. These conversations are pointless as there is no objective truth on code clarity

by jghn 10y ago

deleted 10y ago
[deleted]
edblarney 10y ago
I'm not sure if this is true. Scala provides a whole new level of ability for people to write code that can be meaningless to others. It really is quite different.
- jghn 10y ago
  And that sort of scala code is extremely meaningful to other folks, which captures my point. I see scala code all the time that would give me an instant headache but there are people who would find that more readable. To each their own, the is to work with people who are at least somewhat aligned to your sensibilities.
  - edblarney 10y ago
    Fair enough - but I'll offer this: + Any decent developer can read decent code in Java or whatever normal language and get along just fine. + Only a few people can deal with Scala - and even fewer if there's a log of specific project Scala weirdness used in a particular program. So sure - among a narrower set of 'Scala friendly' developers, and possibly within that even narrower set of people familiar with the 'Scala weirdness' of a particular project - those people can 'get along fine'. The problem is that this can be a pretty narrow set of people. Scala would have to represent a pretty big advantage to propose it's general weirdness as something to bother with. I don't think it does - hence the 'de-adoption' of various entities. My gut tells me it's past the threshold - the 'extra power' offered Scala just isn't quite worth it's weirdness for most things, and so most devs won't learn it ... and so then it becomes less valuable from a business perspective. It's possible we may have it peak Scala. We'll see I guess.
    - jghn 10y ago
      That's not what you said. You said others, not most people. The most important aspect is who you surround yourself with. For instance the scala folks at Verizon basically live in the zone you're talking about and it is fine for them even though half the time it makes no sense to me
Daishiman 10y ago
This is not really as subjective as you think. Research in software engineering shows that certain structures are more prone to errors than others. We know that higher cyclomatic complexity leads to more bugs, more statements lead to more bugs, and certain usage patterns lead to more bugs. Smart people can disagree, undoubtedly, but there's a reason why GOTO is considered to be brain cancer and pattern matching is generally considered to be great.
- jghn 10y ago
  Sure but I'm talking about things like "break things down into lots of small functions to make things more readable!" vs "keeping code together makes it easier to read!" or "make things verbose so it is easier to read!" vs "conciseness makes code easier to read!" On a lot of those I know what makes code easier for me to read. It's not the same as some of my coworkers. Based on some of your phrasing I suspect we'd agree on a lot of them, fwiw When the metric used is "easier to read" it becomes far too subjective IMO, things you mentioned are similar but not quite the same
  - true_religion 10y ago
    It's a judgment call where small functiosn are more readable than cohesive code. If the 'idea' of the code isn't easily broken down into abstractions, even mentally speaking, then small functions will just obscure what's actually going on by pointing out all the implementation details that are wound together.
    - Daishiman 10y ago
      I think the point is that there's a wide range of styles that are readable, but the condition for readability is also related to the skills of the coder to clarify. And that range is ample but also finite.
  - Daishiman 10y ago
    In my experience, very experienced programmers end up converging towards very similar idioms: terse expressions for common patterns, clarity when the domain is complex through verboseness if necessary, and just keeping things as simple as possible unless there's evidence that complexity will reduce technical debt in the future. I don't really see highly competent devs doing the whole J2EE architecture astronautics anymore, nor using single-char variable names. There's a tendency to write things concisely when simple, and then moving the complexity away to some other place, stashed in its own function, when it reaches a certain mental threshold of complexity. There's a tendency to use the best features languages have to offer, maximizing simplicity through orthogonal features and repeated idioms, while discarding unnecessary cruft; one of the marks of junior devs is their desire to try to fit problems into new idioms just to test out language features or strange design patterns. Given that human intelligence is fluid but the variance just isn't that high (after all, we all have a similar amount of working memory), common design practices emerge out of this understanding for our limits for reasoning about problems. Exceptions abound in extremely technical and complicated problems (just check out non-trivial linear algebra code or bit-flipping, low-level device drivers), but the most part it just sticks out how things are made to look simple within a finite range of tradeoffs. This has been my experience in my domain of expertise; look at most current web development frameworks and they respect common patterns even in radically different languages that are really about the essence of the request-response cycle, not made-up constructs of additional complexity or a restating of the problem.
lacampbell 10y ago
That's why I'm a proponent of code ownership. We should be coding to each others interfaces instead of constantly poking around in the same shared codebase. It just leads to pointless re-writes and low quality - a tragedy of the commons. https://www.visualstudio.com/en-us/articles/devopsmsft/code-ownership-quality https://www.visualstudio.com/en-us/articles/devopsmsft/code-...
- jiaweihli 10y ago
  Unfortunately sole code ownership increases the bus factor.
  - lacampbell 10y ago
    Why? The code is still there even when a person leaves.
    - enqk 10y ago
      Code is really hard to work with without the theory that surrounds it, and is alive in the people who worked on it. Peter Naur - Programming As Theory Building http://pages.cs.wisc.edu/~remzi/Naur.pdf http://pages.cs.wisc.edu/~remzi/Naur.pdf
      - lacampbell 10y ago
        Legacy shitcode is legacy shitcode. If it's owned by someone at least we can push for a sane interface, which is better than the abandoned communal messes I encounter in the real world.
        enqk 10y ago
        ?

One person's clever is another person's clear and vice versa. These conversations are pointless as there is no objective truth on code clarity

by jghn 10y ago

One person's clever is another person's clear and vice versa. These conversations are pointless as there is no objective truth on code clarity

deleted 10y ago

[deleted]

edblarney 10y ago

I'm not sure if this is true. Scala provides a whole new level of ability for people to write code that can be meaningless to others. It really is quite different.

jghn 10y ago
And that sort of scala code is extremely meaningful to other folks, which captures my point. I see scala code all the time that would give me an instant headache but there are people who would find that more readable. To each their own, the is to work with people who are at least somewhat aligned to your sensibilities.
- edblarney 10y ago
  Fair enough - but I'll offer this: + Any decent developer can read decent code in Java or whatever normal language and get along just fine. + Only a few people can deal with Scala - and even fewer if there's a log of specific project Scala weirdness used in a particular program. So sure - among a narrower set of 'Scala friendly' developers, and possibly within that even narrower set of people familiar with the 'Scala weirdness' of a particular project - those people can 'get along fine'. The problem is that this can be a pretty narrow set of people. Scala would have to represent a pretty big advantage to propose it's general weirdness as something to bother with. I don't think it does - hence the 'de-adoption' of various entities. My gut tells me it's past the threshold - the 'extra power' offered Scala just isn't quite worth it's weirdness for most things, and so most devs won't learn it ... and so then it becomes less valuable from a business perspective. It's possible we may have it peak Scala. We'll see I guess.
  - jghn 10y ago
    That's not what you said. You said others, not most people. The most important aspect is who you surround yourself with. For instance the scala folks at Verizon basically live in the zone you're talking about and it is fine for them even though half the time it makes no sense to me

Daishiman 10y ago

This is not really as subjective as you think. Research in software engineering shows that certain structures are more prone to errors than others. We know that higher cyclomatic complexity leads to more bugs, more statements lead to more bugs, and certain usage patterns lead to more bugs. Smart people can disagree, undoubtedly, but there's a reason why GOTO is considered to be brain cancer and pattern matching is generally considered to be great.

jghn 10y ago
Sure but I'm talking about things like "break things down into lots of small functions to make things more readable!" vs "keeping code together makes it easier to read!" or "make things verbose so it is easier to read!" vs "conciseness makes code easier to read!" On a lot of those I know what makes code easier for me to read. It's not the same as some of my coworkers. Based on some of your phrasing I suspect we'd agree on a lot of them, fwiw When the metric used is "easier to read" it becomes far too subjective IMO, things you mentioned are similar but not quite the same
- true_religion 10y ago
  It's a judgment call where small functiosn are more readable than cohesive code. If the 'idea' of the code isn't easily broken down into abstractions, even mentally speaking, then small functions will just obscure what's actually going on by pointing out all the implementation details that are wound together.
  - Daishiman 10y ago
    I think the point is that there's a wide range of styles that are readable, but the condition for readability is also related to the skills of the coder to clarify. And that range is ample but also finite.
- Daishiman 10y ago
  In my experience, very experienced programmers end up converging towards very similar idioms: terse expressions for common patterns, clarity when the domain is complex through verboseness if necessary, and just keeping things as simple as possible unless there's evidence that complexity will reduce technical debt in the future. I don't really see highly competent devs doing the whole J2EE architecture astronautics anymore, nor using single-char variable names. There's a tendency to write things concisely when simple, and then moving the complexity away to some other place, stashed in its own function, when it reaches a certain mental threshold of complexity. There's a tendency to use the best features languages have to offer, maximizing simplicity through orthogonal features and repeated idioms, while discarding unnecessary cruft; one of the marks of junior devs is their desire to try to fit problems into new idioms just to test out language features or strange design patterns. Given that human intelligence is fluid but the variance just isn't that high (after all, we all have a similar amount of working memory), common design practices emerge out of this understanding for our limits for reasoning about problems. Exceptions abound in extremely technical and complicated problems (just check out non-trivial linear algebra code or bit-flipping, low-level device drivers), but the most part it just sticks out how things are made to look simple within a finite range of tradeoffs. This has been my experience in my domain of expertise; look at most current web development frameworks and they respect common patterns even in radically different languages that are really about the essence of the request-response cycle, not made-up constructs of additional complexity or a restating of the problem.

lacampbell 10y ago

That's why I'm a proponent of code ownership. We should be coding to each others interfaces instead of constantly poking around in the same shared codebase. It just leads to pointless re-writes and low quality - a tragedy of the commons. https://www.visualstudio.com/en-us/articles/devopsmsft/code-ownership-quality https://www.visualstudio.com/en-us/articles/devopsmsft/code-...

jiaweihli 10y ago
Unfortunately sole code ownership increases the bus factor.
- lacampbell 10y ago
  Why? The code is still there even when a person leaves.
  - enqk 10y ago
    Code is really hard to work with without the theory that surrounds it, and is alive in the people who worked on it. Peter Naur - Programming As Theory Building http://pages.cs.wisc.edu/~remzi/Naur.pdf http://pages.cs.wisc.edu/~remzi/Naur.pdf
    - lacampbell 10y ago
      Legacy shitcode is legacy shitcode. If it's owned by someone at least we can push for a sane interface, which is better than the abandoned communal messes I encounter in the real world.
      - enqk 10y ago
        ?