6 ms·

Reading the comments in this thread is very interesting to me, because each programmer seems certain of the superiority of his own programming style. We have s

Reading the comments in this thread is very interesting to me, because each programmer seems certain of the superiority of his own programming style. We have some comments that disparage the change, saying that it obfuscates the code and makes it more difficult to understand. We have others saying that this change is a basic technique and it's "shocking" that the author wrote a book without this simple knowledge. What I take from this is yet another situation of people arguing about something highly subjective that is closely tied to their identity. Good programming is not an objective concept. People respond differently to different programming techniques and what works better for one person may greatly confuse another.

AlexeyBrin 14y ago
+1 for Good programming is not an objective concept.
- dakimov 14y ago
  == Programming sucks nowadays. There is not even a consensus on what is good in programming! Take a look at other professional cultures: people work extremely hard to develop the skills that everybody else in their profession have. What does a software developer do? Whatever they like on their own, there is no professional culture whatsoever: "Don't give a crap about the humankind's experience, I'll invent everything on my own the way I like". This is actually unbelievable how different programming is in this aspect from other disciplines. I don't even mentor Junior Developers because of that, as I can't refer to anything authoritative and say "Do it like this" because there is always a bunch of folks that do it the opposite way. There is almost nothing to rely on.
  - bthomas 14y ago
    The nature of programming is that any consensus solution can be automated. That's a good thing.
    - moultano 14y ago
      I'm always amazed though the extent to which that isn't followed through on. Consider the code for logging in and storing user credentials. The level of collaboration on this is at the level of a list of best practices. Why are we still letting anyone (re)write this code?
      - spc476 14y ago
        Okay, how do you use /bin/login over HTTP? Situations change. So do languages. I hope you can find an Algol compiler, but not Algol-68---that's too new for this code.
  - alttab 14y ago
    If you can't draw upon your past mistakes, or techniques that have failed for you before, you shouldn't be mentoring. Put more positively, use your experience to guide others.
  - dasil003 14y ago
    It's not that there's no professional culture in programming, it's that programming has a problem/solution space orders of magnitude larger than any other profession that has ever existed. If we could agree on some constraints of what software does and what the priorities are then we could develop more concrete professional standards, but that's not how it works. Software is the stuff of pure thought; it is layer upon layer of abstraction that towers up to henceforth unknown data processing tasks. As messy as it is, we can only strive to further the state of the art as it applies to the task at hand. There's no way to definitively pit NASA's process against Facebook's against a random perl data cruncher. None of this means programming doesn't have a professional culture, just that it will take a while longer to distill the strongest knowledge and it will necessarily be a broader than the other professional standards.
    - yxhuvud 14y ago
      Another thing we can expect is further specialization with different standards.
  - redshirtrob 14y ago
    > There is almost nothing to rely on. You could rely on your experience.
  - atsaloli 14y ago
    I would have thought www.swebok.org (Software Engineering Body of Knowledge) represents some consensus on what is good in programming?
  - AYBABTME 14y ago
    There's stuff to rely on, it's just that mostly nobody wants to spend the time reading it.
- nikster 14y ago
  I dont agree with that. There is a confusion about programming though, an idea that it is a purely technical discipline, like laying bricks when in reality its a design discipline, like designing a building. If you wanted to build a house you wouldnt just hire a couple of bricklayers and tell them "do it". Yet thats what happens in programming...
pjungwir 14y ago
Early in my career, a project manager said to me, "I've never heard one programmer praise another programmer's code. They always criticize!" I think that reinforced for me both that someone's approach might be good even if it isn't my own, and also that it's important to say when something is done well. Of course, there's also just a lot of bad code out there.... :-)
- ams6110 14y ago
  A lot of programmers are insecure. They were the nerds in school, not popular, not good at sports, etc. Programming is the one thing they can do where they feel in control, and confident. So they naturally tend to be defensive about it.
  - mylittlepony 14y ago
    > A lot of programmers are insecure. You mean a lot of persons? If you don't, I wonder where you got this from. Personal experience maybe? Anecdotic: I have always been good at sports, popular, and confident, and I criticized this article because he used a kind of link-bait title (should have been "Today I learned about inheritance and it's awesome", something like that), and he also turned out to be selling programming books like he was an expert, which is scammy, and reinforces the fact that you can only find good books through recommendations from your peers.
    - tjr 14y ago
      So he didn't know some aspect of polymorphism. Is that pertinent to his book? It's not as if using if/else constructs is bad or wrong. In some fields of development it would be preferred, for blatant clarity. Does it follow that his book is bad or wrong because it was not written with understanding of this aspect of polymorphism?
      - mylittlepony 14y ago
        "You can reuse code with inheritance. Absolutely crazy. Brilliant. All of this blew me away."
bgruber 14y ago
both arguments are right, but not because of a subjective goodness. because they're talking about 2 different parts of the patch: - the "bad" part is RowType.for(), where a type is dynamically called forth based on manipulations on some string. I agree that a more concrete mapping from string-to-type would be preferable (I'm assuming the use of a string is required for some reason). - the "good" part of the patch is that he replaced a conditional with type dispatch. I agree that this is a basic technique of object-oriented programming.
cbsmith 14y ago
A technique can be both basic/obvious and not a course of action that everyone would agree upon. The surprise isn't that he didn't make the choice to do it that way. The surprise is that the choice didn't occur to him. The feedback would be very different if he simply had made a different choice.
B-Con 14y ago
I think that programming is very close to how we actually think. Programmers tend to be objective people who like distinguishing good from bad and better from worse. They're generally analyzers to the core. But we all have some personal aspect of how we see the world. How we organize logic, view priorities, and such, is all personal and unique, no matter how much we may feel that it's objective. Programming is an expression of that inner thought life. It's how you organize, categorize, and optimize, all laid out in bare raw form. It's an expression not just of our identity, but to an extent of how we exist. Being who we are, we usually tend to think highly of ourselves and our way of doing things, so it's only natural that we think highly our code style.
greghinch 14y ago
Something that I've come to realize only in the last couple of years: most programming arguments revolve around personal preference. There are of course optimizations that can be made to actually improve machine performance; these can be found reasonably simply through profiling. At the end of the day, most arguments revolve around "style". It's actually a very tricky subject. If you're working on SMe apps, including startups, most often a given project'style will flow from the lead (or the person/people who initiated the project). They may be good, they may be bad. Invariably, less experienced developers are hired and learn Ro code following this style. Eventually, those less experienced developers become experienced, and leave to persue other projects. And they take that style with them. Depending on the role they have, there is likely still a lead above them. And this is where the arguments begin. The lead had his/her style. The new dev has experience with another style, and it may or may not mesh with the new lead's style. And so the problem perpetuates. It can be very difficult to work with those devs in the early-middle stage of their career. If they are good people, they learn to be flexible, adopt the best parts of all the styles they are exposed to, and eventually become great leads. But many will not, are confrontational, and ultimately poisonous to the teams they are on. If I can quote my favorite philosopher, Ted "Theodore" Logan: "if the only true wisdom lies in knowing, then you know nothing"
- stiff 14y ago
  A programming argument that can be convincingly shown to be only a matter of personal preference is irrelevant, but I strongly disagree those are that common. Various programming language constructs have various properties and if you had the opportunity to maintain a single project for some 5-10 years, to experiment with different implementations of same functionalities etc. you learn that certain techniques prevent problems and certain others provoke them. Look at the writing of Joshua Bloch based on his experience with designing the Java standard libraries, you will find plenty of arguments that you could think are about "style", but in fact he always includes a very detailed and concrete discussion about why one way is superior to the other. Similarly with some of the articles of John Carmack from idSoftware. For me the revelation was that there is indeed no such thing as "style" so that some techniques are just "prettier" than the others, it is all a matter of consequences a given implementation has for other developers using the code and for its maintainers.
instakill 14y ago
I knew the comments were going to be exactly as you described before I clicked the comments link (and had this in mind http://xkcd.com/1053/ http://xkcd.com/1053/) and I'm really glad your comment is on top and visible for everyone to digest before they start handing out their own judgements.
gdy 14y ago
These two statements are not mutually exclusive - the technique is basic and sometimes its drawbacks may outweight its benefits. While applicability of the technique in a particular situation may be a matter of discussion, ignorance of its existence is shocking considering that the author has reportedly written a book on programming.
Confusion 14y ago
When people disagree that doesn't imply that the situation is highly subjective and all opinions are equally valid. In this case I believe they most certainly are not and I think you are drawing stronger conclusions than is warranted. There are objective ways in which to judge programming, by considering whether simple rules like the SOLID principles, low coupling, DRY, using composition over inheritance, keeping code complexity measurements low, favoring immutability, statelessness and referential transparency, etc. have been followed. If any programmer is certain of the superiority of 'his programming style' (singular), then that programmer is insufficiently humble and lacks knowledge of multiple programming styles. Tragically, if you don't know what you don't know, you can think you know everything and can thus speak with confidence on a subject. One can wonder what comments would be left if you removed all those from programmers with less than 5 years of programming experience, programmers under 30 and programmers with experience in only a single language. My suspicion is that a pretty consistent picture would emerge, with a number of caveats and YMMV's, with an eye for the actual, intended and possible future use cases, the language, the maturity of the project, etc.
- Xcelerate 14y ago
  I can agree with some of your points; however, I believe you make too many simplifying assumptions. > There are objective ways in which to judge programming, by considering whether simple rules like the SOLID principles, low coupling, DRY, using composition over inheritance, keeping code complexity measurements low, favoring immutability, statelessness and referential transparency, etc. have been followed. Hardly anyone on here would disagree that these are good programming practices (or so I think...), but the question becomes: what is the best way to favor immutability? FP solves that problem but many people don't like the all-or-nothing approach. Same with referential transparency. > One can wonder what comments would be left if you removed all those from programmers with less than 5 years of programming experience, programmers under 30 and programmers with experience in only a single language. Programmers under 30? Think how many languages exist that aren't even 30 years old! This is one area where I highly disagree. I have found that age matters very little with regard to someone's ability to write code. I have seen code written by "veteran programmers" that is worse than some teenager's weekend project. I'm not denying there is a correlation, but I would say it is a very weak correlation that probably isn't worth mentioning. I do agree with programming experience, although I'll add the caveat that programming seems to be interesting compared to other subjects in that the rate at which different individuals become better at it seems to vary very dramatically.

AlexeyBrin 14y ago

+1 for Good programming is not an objective concept.

dakimov 14y ago
== Programming sucks nowadays. There is not even a consensus on what is good in programming! Take a look at other professional cultures: people work extremely hard to develop the skills that everybody else in their profession have. What does a software developer do? Whatever they like on their own, there is no professional culture whatsoever: "Don't give a crap about the humankind's experience, I'll invent everything on my own the way I like". This is actually unbelievable how different programming is in this aspect from other disciplines. I don't even mentor Junior Developers because of that, as I can't refer to anything authoritative and say "Do it like this" because there is always a bunch of folks that do it the opposite way. There is almost nothing to rely on.
- bthomas 14y ago
  The nature of programming is that any consensus solution can be automated. That's a good thing.
  - moultano 14y ago
    I'm always amazed though the extent to which that isn't followed through on. Consider the code for logging in and storing user credentials. The level of collaboration on this is at the level of a list of best practices. Why are we still letting anyone (re)write this code?
    - spc476 14y ago
      Okay, how do you use /bin/login over HTTP? Situations change. So do languages. I hope you can find an Algol compiler, but not Algol-68---that's too new for this code.
- alttab 14y ago
  If you can't draw upon your past mistakes, or techniques that have failed for you before, you shouldn't be mentoring. Put more positively, use your experience to guide others.
- dasil003 14y ago
  It's not that there's no professional culture in programming, it's that programming has a problem/solution space orders of magnitude larger than any other profession that has ever existed. If we could agree on some constraints of what software does and what the priorities are then we could develop more concrete professional standards, but that's not how it works. Software is the stuff of pure thought; it is layer upon layer of abstraction that towers up to henceforth unknown data processing tasks. As messy as it is, we can only strive to further the state of the art as it applies to the task at hand. There's no way to definitively pit NASA's process against Facebook's against a random perl data cruncher. None of this means programming doesn't have a professional culture, just that it will take a while longer to distill the strongest knowledge and it will necessarily be a broader than the other professional standards.
  - yxhuvud 14y ago
    Another thing we can expect is further specialization with different standards.
- redshirtrob 14y ago
  > There is almost nothing to rely on. You could rely on your experience.
- atsaloli 14y ago
  I would have thought www.swebok.org (Software Engineering Body of Knowledge) represents some consensus on what is good in programming?
- AYBABTME 14y ago
  There's stuff to rely on, it's just that mostly nobody wants to spend the time reading it.
nikster 14y ago
I dont agree with that. There is a confusion about programming though, an idea that it is a purely technical discipline, like laying bricks when in reality its a design discipline, like designing a building. If you wanted to build a house you wouldnt just hire a couple of bricklayers and tell them "do it". Yet thats what happens in programming...

pjungwir 14y ago

Early in my career, a project manager said to me, "I've never heard one programmer praise another programmer's code. They always criticize!" I think that reinforced for me both that someone's approach might be good even if it isn't my own, and also that it's important to say when something is done well. Of course, there's also just a lot of bad code out there.... :-)

ams6110 14y ago
A lot of programmers are insecure. They were the nerds in school, not popular, not good at sports, etc. Programming is the one thing they can do where they feel in control, and confident. So they naturally tend to be defensive about it.
- mylittlepony 14y ago
  > A lot of programmers are insecure. You mean a lot of persons? If you don't, I wonder where you got this from. Personal experience maybe? Anecdotic: I have always been good at sports, popular, and confident, and I criticized this article because he used a kind of link-bait title (should have been "Today I learned about inheritance and it's awesome", something like that), and he also turned out to be selling programming books like he was an expert, which is scammy, and reinforces the fact that you can only find good books through recommendations from your peers.
  - tjr 14y ago
    So he didn't know some aspect of polymorphism. Is that pertinent to his book? It's not as if using if/else constructs is bad or wrong. In some fields of development it would be preferred, for blatant clarity. Does it follow that his book is bad or wrong because it was not written with understanding of this aspect of polymorphism?
    - mylittlepony 14y ago
      "You can reuse code with inheritance. Absolutely crazy. Brilliant. All of this blew me away."

bgruber 14y ago

both arguments are right, but not because of a subjective goodness. because they're talking about 2 different parts of the patch: - the "bad" part is RowType.for(), where a type is dynamically called forth based on manipulations on some string. I agree that a more concrete mapping from string-to-type would be preferable (I'm assuming the use of a string is required for some reason). - the "good" part of the patch is that he replaced a conditional with type dispatch. I agree that this is a basic technique of object-oriented programming.

cbsmith 14y ago

A technique can be both basic/obvious and not a course of action that everyone would agree upon. The surprise isn't that he didn't make the choice to do it that way. The surprise is that the choice didn't occur to him. The feedback would be very different if he simply had made a different choice.

B-Con 14y ago

I think that programming is very close to how we actually think. Programmers tend to be objective people who like distinguishing good from bad and better from worse. They're generally analyzers to the core. But we all have some personal aspect of how we see the world. How we organize logic, view priorities, and such, is all personal and unique, no matter how much we may feel that it's objective. Programming is an expression of that inner thought life. It's how you organize, categorize, and optimize, all laid out in bare raw form. It's an expression not just of our identity, but to an extent of how we exist. Being who we are, we usually tend to think highly of ourselves and our way of doing things, so it's only natural that we think highly our code style.

greghinch 14y ago

Something that I've come to realize only in the last couple of years: most programming arguments revolve around personal preference. There are of course optimizations that can be made to actually improve machine performance; these can be found reasonably simply through profiling. At the end of the day, most arguments revolve around "style". It's actually a very tricky subject. If you're working on SMe apps, including startups, most often a given project'style will flow from the lead (or the person/people who initiated the project). They may be good, they may be bad. Invariably, less experienced developers are hired and learn Ro code following this style. Eventually, those less experienced developers become experienced, and leave to persue other projects. And they take that style with them. Depending on the role they have, there is likely still a lead above them. And this is where the arguments begin. The lead had his/her style. The new dev has experience with another style, and it may or may not mesh with the new lead's style. And so the problem perpetuates. It can be very difficult to work with those devs in the early-middle stage of their career. If they are good people, they learn to be flexible, adopt the best parts of all the styles they are exposed to, and eventually become great leads. But many will not, are confrontational, and ultimately poisonous to the teams they are on. If I can quote my favorite philosopher, Ted "Theodore" Logan: "if the only true wisdom lies in knowing, then you know nothing"

stiff 14y ago
A programming argument that can be convincingly shown to be only a matter of personal preference is irrelevant, but I strongly disagree those are that common. Various programming language constructs have various properties and if you had the opportunity to maintain a single project for some 5-10 years, to experiment with different implementations of same functionalities etc. you learn that certain techniques prevent problems and certain others provoke them. Look at the writing of Joshua Bloch based on his experience with designing the Java standard libraries, you will find plenty of arguments that you could think are about "style", but in fact he always includes a very detailed and concrete discussion about why one way is superior to the other. Similarly with some of the articles of John Carmack from idSoftware. For me the revelation was that there is indeed no such thing as "style" so that some techniques are just "prettier" than the others, it is all a matter of consequences a given implementation has for other developers using the code and for its maintainers.

instakill 14y ago

I knew the comments were going to be exactly as you described before I clicked the comments link (and had this in mind http://xkcd.com/1053/ http://xkcd.com/1053/) and I'm really glad your comment is on top and visible for everyone to digest before they start handing out their own judgements.

gdy 14y ago

These two statements are not mutually exclusive - the technique is basic and sometimes its drawbacks may outweight its benefits. While applicability of the technique in a particular situation may be a matter of discussion, ignorance of its existence is shocking considering that the author has reportedly written a book on programming.

Confusion 14y ago

When people disagree that doesn't imply that the situation is highly subjective and all opinions are equally valid. In this case I believe they most certainly are not and I think you are drawing stronger conclusions than is warranted. There are objective ways in which to judge programming, by considering whether simple rules like the SOLID principles, low coupling, DRY, using composition over inheritance, keeping code complexity measurements low, favoring immutability, statelessness and referential transparency, etc. have been followed. If any programmer is certain of the superiority of 'his programming style' (singular), then that programmer is insufficiently humble and lacks knowledge of multiple programming styles. Tragically, if you don't know what you don't know, you can think you know everything and can thus speak with confidence on a subject. One can wonder what comments would be left if you removed all those from programmers with less than 5 years of programming experience, programmers under 30 and programmers with experience in only a single language. My suspicion is that a pretty consistent picture would emerge, with a number of caveats and YMMV's, with an eye for the actual, intended and possible future use cases, the language, the maturity of the project, etc.

Xcelerate 14y ago
I can agree with some of your points; however, I believe you make too many simplifying assumptions. > There are objective ways in which to judge programming, by considering whether simple rules like the SOLID principles, low coupling, DRY, using composition over inheritance, keeping code complexity measurements low, favoring immutability, statelessness and referential transparency, etc. have been followed. Hardly anyone on here would disagree that these are good programming practices (or so I think...), but the question becomes: what is the best way to favor immutability? FP solves that problem but many people don't like the all-or-nothing approach. Same with referential transparency. > One can wonder what comments would be left if you removed all those from programmers with less than 5 years of programming experience, programmers under 30 and programmers with experience in only a single language. Programmers under 30? Think how many languages exist that aren't even 30 years old! This is one area where I highly disagree. I have found that age matters very little with regard to someone's ability to write code. I have seen code written by "veteran programmers" that is worse than some teenager's weekend project. I'm not denying there is a correlation, but I would say it is a very weak correlation that probably isn't worth mentioning. I do agree with programming experience, although I'll add the caveat that programming seems to be interesting compared to other subjects in that the rate at which different individuals become better at it seems to vary very dramatically.