4 ms·

After reading enough of these articles, one comes to a disturbing conclusion: a lot of software engineering practices and a lot of "common sense" knowledge are

by blub 11y ago

After reading enough of these articles, one comes to a disturbing conclusion: a lot of software engineering practices and a lot of "common sense" knowledge are based on anecdotes, blog posts, famous engineers' declarations or arguments on the internet. It shouldn't be very difficult to prove that a particular programming paradigm is better along some axis than another. I think it's great that Brian is happy and more productive, but that has no meaning to me if I want to make an informed decision about FP.

alkonaut 11y ago
> It shouldn't be very difficult to prove that a particular programming paradigm is better along some axis than another I think it would be one of the hardest things to ever prove scientifically actually. Basically the only valid method I'd accept is having a large group of people who are non-developers, then train half of them in one paradigm and the other in another. Then have both groups solve the same set of problems. The problem with this experiment is that in order to get useful results is that you need a good group of people that are representative of programmers (i.e. people that don't know programming, but can and are willing/able to learn). Say you can find 1000 mechanical engineering students for example. Great. Next they need to be trained. How long does that take? A year or two? Finally they need to solve the problems, which should be large problems. Next the solutions to the problems should be carefully evaluated. I'd say the experiment if done in academia would be ridiculoulsy expensive and time-consuiming. Numerous studies such as on static vs dynamic typing have used tiny programming experiments done by a small groups of students doing trivial exercises over the course of a day. I'd say they give little or no insight in how experienced developers handle large problems. It's very hard to do it as a natural experiment too. A large company could try giving the same task to a team of OO developers, as it does to a team of FP developers. This has happened and the result is usually that the FP developers do it in half the time with half the bugs and twice the enthusiasm. However -- can we know that the people who ended up being FP developers weren't just better developers than the OO devs? I'd wager that "enthusiasts" are more commonly drawn to FP today, so the base of FP developers is a group that is on average "better" than the OO devs. So while I don't doubt that FP is "better" in most scenarios, I also belive the FP group would have done a better job with the OO language as well.
- pron 11y ago
  > Basically the only valid method I'd accept is having a large group of people who are non-developers, then train half of them in one paradigm and the other in another. Then have both groups solve the same set of problems. I'd settle for two competitors working in the same domain producing similar products using different paradigms, reporting significantly different costs throughout the project's lifetime (including maintenance). Or even a single company reporting a vast decline in costs after switching paradigms, provided that the project is big enough and lasts long enough (five years at a minimum, a decade is preferable). Of course, the more domains and more cases per domain the better. This isn't theoretical. We had numerous case studies of this sort in the late '90s-early '00s showing a very big cost reduction when moving from C/C++ to Java, in projects ranging from enterprise software to defense.
  - andybak 11y ago
    > I'd settle for two competitors working in the same domain producing similar products using different paradigms <snip> I think you'll easily find the example you seek. In fact I think you'll probably find several. Unfortunately they are all likely to support different conclusions.
    - pron 11y ago
      > Unfortunately they are all likely to support different conclusions. ... which means that the case is not so clear cut, which may suggest that the increased effectiveness of some methods is not universal but restricted to specific domains or even specific team compositions.
  - alkonaut 11y ago
    The problem with two competitors is that you still can't be sure that the firm that used FP either had "better" developers who would have done the project better at the other firm too. I have met almost no bad developers who do and enjoy FP, and I have met tons of bad OO developers. Actually, even OO developers that just know of the concept of FP are way in my experience way better OO devs than those who don't. A company switching paradigms is a better test, since the same developers are involved, and presumably they would be less experienced in the new paradigm than the old. If they still produce better software that is a good indication that it was a good switch. Still, there may be a number of companies that did this and failed because they couldn't reach profitability with a new code base, or couldn't fill vacancies and so on. Like I said, it's very hard.
bartread 11y ago
Agreed. I'm actually getting really bored of this "X programming paradigm is bad" trope. I've written code that works in imperative, OO and functional styles, but the really important point in all cases is that the code worked: it solved some problem, it added value to the user. For me it's about using the right tool for the job in hand. Plus there's the observation that learning to program in a different style may well make you a better programmer in the other styles too.
- mironathetin 11y ago
  As long as you are alone and in control, I agree. But in a project with a large java inheritance hierarchy, polymorphism maxed out by some remote developers, it is easy to really get lost.
  - bartread 11y ago
    In a team you obviously need to agree on a set of languages and tools but, again, I still find people using different styles, often depending upon the functionality they're working on. To some extent it depends on what you think is important, and the environment you're working in: I always want to get working software shipped and I'm happy to change the way I work (and the tools I use) to get this done more efficiently. If you believe there's ONE TRUE WAY - or perhaps you have team members who insist that's the case* - that's bound to be more of a challenge. *I've never found this mentality leads to the best outcomes, especially not on large, complex projects, and certainly it can cause a lot of friction within the team.
  - peterashford 11y ago
    I would argue the exact opposite. I find Java projects easier to read than many other languages given that there's often one "right way" to do things.
teambob 11y ago
Programming languages are the interface between the computer and fallible humans. Thus it is in fact very difficult to prove that a particular paradigm is better or worse. Civil engineering has been around for centuries. Yet the Tacoma Narrows Bridge failed in a completely unexpected way. This passed down engineering "memory" or "lore" is invaluable. Every engineer should endeavour to learn from their mistakes and successes

by blub 11y ago

alkonaut 11y ago

> It shouldn't be very difficult to prove that a particular programming paradigm is better along some axis than another I think it would be one of the hardest things to ever prove scientifically actually. Basically the only valid method I'd accept is having a large group of people who are non-developers, then train half of them in one paradigm and the other in another. Then have both groups solve the same set of problems. The problem with this experiment is that in order to get useful results is that you need a good group of people that are representative of programmers (i.e. people that don't know programming, but can and are willing/able to learn). Say you can find 1000 mechanical engineering students for example. Great. Next they need to be trained. How long does that take? A year or two? Finally they need to solve the problems, which should be large problems. Next the solutions to the problems should be carefully evaluated. I'd say the experiment if done in academia would be ridiculoulsy expensive and time-consuiming. Numerous studies such as on static vs dynamic typing have used tiny programming experiments done by a small groups of students doing trivial exercises over the course of a day. I'd say they give little or no insight in how experienced developers handle large problems. It's very hard to do it as a natural experiment too. A large company could try giving the same task to a team of OO developers, as it does to a team of FP developers. This has happened and the result is usually that the FP developers do it in half the time with half the bugs and twice the enthusiasm. However -- can we know that the people who ended up being FP developers weren't just better developers than the OO devs? I'd wager that "enthusiasts" are more commonly drawn to FP today, so the base of FP developers is a group that is on average "better" than the OO devs. So while I don't doubt that FP is "better" in most scenarios, I also belive the FP group would have done a better job with the OO language as well.

pron 11y ago
> Basically the only valid method I'd accept is having a large group of people who are non-developers, then train half of them in one paradigm and the other in another. Then have both groups solve the same set of problems. I'd settle for two competitors working in the same domain producing similar products using different paradigms, reporting significantly different costs throughout the project's lifetime (including maintenance). Or even a single company reporting a vast decline in costs after switching paradigms, provided that the project is big enough and lasts long enough (five years at a minimum, a decade is preferable). Of course, the more domains and more cases per domain the better. This isn't theoretical. We had numerous case studies of this sort in the late '90s-early '00s showing a very big cost reduction when moving from C/C++ to Java, in projects ranging from enterprise software to defense.
- andybak 11y ago
  > I'd settle for two competitors working in the same domain producing similar products using different paradigms <snip> I think you'll easily find the example you seek. In fact I think you'll probably find several. Unfortunately they are all likely to support different conclusions.
  - pron 11y ago
    > Unfortunately they are all likely to support different conclusions. ... which means that the case is not so clear cut, which may suggest that the increased effectiveness of some methods is not universal but restricted to specific domains or even specific team compositions.
- alkonaut 11y ago
  The problem with two competitors is that you still can't be sure that the firm that used FP either had "better" developers who would have done the project better at the other firm too. I have met almost no bad developers who do and enjoy FP, and I have met tons of bad OO developers. Actually, even OO developers that just know of the concept of FP are way in my experience way better OO devs than those who don't. A company switching paradigms is a better test, since the same developers are involved, and presumably they would be less experienced in the new paradigm than the old. If they still produce better software that is a good indication that it was a good switch. Still, there may be a number of companies that did this and failed because they couldn't reach profitability with a new code base, or couldn't fill vacancies and so on. Like I said, it's very hard.

bartread 11y ago

Agreed. I'm actually getting really bored of this "X programming paradigm is bad" trope. I've written code that works in imperative, OO and functional styles, but the really important point in all cases is that the code worked: it solved some problem, it added value to the user. For me it's about using the right tool for the job in hand. Plus there's the observation that learning to program in a different style may well make you a better programmer in the other styles too.

mironathetin 11y ago
As long as you are alone and in control, I agree. But in a project with a large java inheritance hierarchy, polymorphism maxed out by some remote developers, it is easy to really get lost.
- bartread 11y ago
  In a team you obviously need to agree on a set of languages and tools but, again, I still find people using different styles, often depending upon the functionality they're working on. To some extent it depends on what you think is important, and the environment you're working in: I always want to get working software shipped and I'm happy to change the way I work (and the tools I use) to get this done more efficiently. If you believe there's ONE TRUE WAY - or perhaps you have team members who insist that's the case* - that's bound to be more of a challenge. *I've never found this mentality leads to the best outcomes, especially not on large, complex projects, and certainly it can cause a lot of friction within the team.
- peterashford 11y ago
  I would argue the exact opposite. I find Java projects easier to read than many other languages given that there's often one "right way" to do things.

teambob 11y ago

Programming languages are the interface between the computer and fallible humans. Thus it is in fact very difficult to prove that a particular paradigm is better or worse. Civil engineering has been around for centuries. Yet the Tacoma Narrows Bridge failed in a completely unexpected way. This passed down engineering "memory" or "lore" is invaluable. Every engineer should endeavour to learn from their mistakes and successes