Live data from Hacker News

Three Tribes of Programming (2017)

josephg.com

101–110 of 123 posts

Re: Three Tribes of Programming (2017)

#101
post #83

Earlier quoted context omitted.

Ada code is not very beautiful nor mathematically elegant. I think _despise_ is probably too strong but all the things people like about Haskell and Lisp are not in Ada. I think the author probably thinks Ada's type system is more powerful than it actually is (or is just thinking of SPARK). Ada is basically just verbose C with a slightly nicer type system and better aliasing rules.

I think that in imperative programming, like in Ada, the mathematical elegance comes from ensuring the post-conditions from pre-conditions and maintaining invariants and so on. I'm seeing a new generation of kids coming out of school who are just pissing on those techniques: only functional is mathematical, and the rest is outdated, intractable garbage that causes software crises and meltdowns.

That's reasonable (and I actually do like Ada somewhat) but the satisfaction of figuring out a nice algorithm in APL and writing an equivalent in Ada are just… not the same.

Though I'm not really sure I'd call maintaining invariants and pre/postconditions mathematical elegance per se, it feels like good engineering. Like you've built something that's solid.

Re: Three Tribes of Programming (2017)

#102
post #2

This is fantastic and surprisingly close to how I tended to explain computer science to students and graduates: In Computer Science, there are 3 kinds of problems: 1. The problems that Math gives you: algorithms, data structures. These are the problems you think you're going to solve and sometimes you do, but often we just need a few really smart programmers to solve this and the rest of us can just use those solutio…

Computer science and math is useful beyond just algorithms and data structures. Understanding the mathematics behind program construction would allow more programmers to write composable code and more general, re-usable, less ad-hoc APIs; and do a better job of gluing existing components together.

Re: Three Tribes of Programming (2017)

#103
post #84

This post is nice, but... Rich Hickey and Bret Victor here are squashed into overly simple (and/or wrong) categories whose descriptions go like "the best programs [...] formally prove correctness" and "beautiful code is more important than beautiful UI". Both have been very vocal against these points. Jon Blow is definitely not (just) in category 2. "But one of the reasons his last game (The Witness) took so long to…

Thanks. Author here. I mean, generally I agree - but, any generalization will always be a bit overly general and reductive. The point of this article wasn't to try and make a formal taxonomy; just express an intuition. If I were to revise this article now I think your point is what I'd change about it - I mean, all of us can embody all of these core motivations. (Although I'm not sure we can hold all of them at the s…

Thanks for the article, I agree that these groups are useful to think with, while I also object to the association of specific people with a particular category. Maybe because I align myself with these people too much, but don't consider myself aligned to one category at the expense of the others?

Re: Three Tribes of Programming (2017)

#104

I believe this is true in all fields, not just programming. - Tribe 1: the art component wins. - Tribe 2: the science component wins. - Tribe 3: the business component wins. Your life is easier when you belong to tribe 3. I also believe that you can't choose your tribe.

I don't think that you can't choose them, to me which tribe you consider yourself in reflects your ideals in software, and that may change over years.

Re: Three Tribes of Programming (2017)

#105
post #104

I believe this is true in all fields, not just programming. - Tribe 1: the art component wins. - Tribe 2: the science component wins. - Tribe 3: the business component wins. Your life is easier when you belong to tribe 3. I also believe that you can't choose your tribe.

I don't think that you can't choose them, to me which tribe you consider yourself in reflects your ideals in software, and that may change over years.

Your tribe represents your personality. While I believe that belonging to tribe 3 could make my life way easier, unconsciously, I'm always leaning to tribe 1. I could resume my life with this sentence.

Re: Three Tribes of Programming (2017)

#106

I believe this is true in all fields, not just programming. - Tribe 1: the art component wins. - Tribe 2: the science component wins. - Tribe 3: the business component wins. Your life is easier when you belong to tribe 3. I also believe that you can't choose your tribe.

Robert Kegan developed a theory of adult development. He identifies five stages. Stage 3 can be described as communal, stage 4 as systematic and stage 5 as metasystematic. These are modes of thinking and describe how you relate to others, how you make sense of the world, etc. He says that most adult people belong to stage 3, some to stage 4 and very few to stage 5. He also holds that higher stages include the capacity to think in lower stages and are really better, in the sense that they increase your capacity to make sense of the world.

I believe that the three groups mentioned in the article map pretty nicely onto this framework and that, while you may not be able to choose your (maximum) stage, you can over time progress into higher stages.

Re: Three Tribes of Programming (2017)

#107
post #16
post #2

This is fantastic and surprisingly close to how I tended to explain computer science to students and graduates: In Computer Science, there are 3 kinds of problems: 1. The problems that Math gives you: algorithms, data structures. These are the problems you think you're going to solve and sometimes you do, but often we just need a few really smart programmers to solve this and the rest of us can just use those solutio…

I'm continually surprised at how quickly non-technical problems come to dominate my time on a software project. E.g. my code doesn't work because two business stakeholders have slightly different, irreconcilable notions of what a "customer" is and it has to satisfy both.

Or things as mundane as discover that a third of your coworkers (even seniors) are so much emotion driven that may as well go back to high school in order to learn how to socialize and be professional avoiding jealousy, envy, unnecessary competence or just plainly learn how to work in team and how to follow some sort of structure in an organization.

Re: Three Tribes of Programming (2017)

#109

This post is nice, but... Rich Hickey and Bret Victor here are squashed into overly simple (and/or wrong) categories whose descriptions go like "the best programs [...] formally prove correctness" and "beautiful code is more important than beautiful UI". Both have been very vocal against these points. Jon Blow is definitely not (just) in category 2. "But one of the reasons his last game (The Witness) took so long to…

Yes, I really like this article too but the inclusion of Bret Victor in the first group seemed a little off - from what I've read he seems deeply concerned with human-computer interaction.

Re: Three Tribes of Programming (2017)

#110
post #16

Earlier quoted context omitted.

I'm continually surprised at how quickly non-technical problems come to dominate my time on a software project. E.g. my code doesn't work because two business stakeholders have slightly different, irreconcilable notions of what a "customer" is and it has to satisfy both.

Or things as mundane as discover that a third of your coworkers (even seniors) are so much emotion driven that may as well go back to high school in order to learn how to socialize and be professional avoiding jealousy, envy, unnecessary competence or just plainly learn how to work in team and how to follow some sort of structure in an organization.

unnecessary competence

What on earth do you mean by this? It sounds rather like advocating just doing the minimum you can, for the sake of harmony.

Post reply on HN