3

In a video about software architecture that I'm watching, it's stated that the main program/subroutine architectural style

promotes modularity and function reuse

Code reuse is one of the main benefits I've always heard object oriented programming offers. This answer to a related question says the same:

Code re-use is achieved in OOP but it is also achieved in functional programming

I understand that both programming paradigms, OO and functional (main/subroutine) promote code reuse. What I can't picture, is an example of the opposite.

What architectural style or programming paradigm makes code reuse hard, and why?

antonro
  • 249
  • 1
  • 9
  • functional programming usually implies https://en.wikipedia.org/wiki/Lambda_calculus i.e. https://en.wikipedia.org/wiki/Functional_programming main/subroutine is https://en.wikipedia.org/wiki/Procedural_programming which is a type of https://en.wikipedia.org/wiki/Imperative_programming – esoterik Jun 04 '18 at 20:59
  • 11
    In short: unstructured spaghetti code programming, especially when utilizing lots of side effects. Try to reuse a function > 500 lines out of its context. Good luck. – Doc Brown Jun 04 '18 at 21:00
  • 2
    Code reuse is difficult in any programming language. The trick is having good design within the constraints of your chosen language. – Robert Harvey Jun 04 '18 at 21:59
  • @DocBrown structured ravioli object oriented code is also unreadable and unusable, except occasionally by the original author, who will always refer to it as "clean code." – Frank Hileman Jun 05 '18 at 23:58
  • 1
    My own experience is that functional programming languages make code easier to reuse, by having higher level concepts available. Object oriented code is not any more reusable than well written structured programming code, but encapsulation tends to be easier in object oriented programming, whereas you have to work at it in structured programming. – Frank Hileman Jun 06 '18 at 00:05
  • 1
    Code has to be **designed for** reusability by other people. Code that is not **well designed for** *X*, is tautologically **poorly designed for** *X*, whatever *X* is. – rwong Jun 06 '18 at 07:52

2 Answers2

8

For my own sanity, I've shortened "paradigms that promote code reuse" to "paradigms". In scope of this answer, all mentioned paradigms are paradigms that promote code reuse.


What I can't picture, is an example of the opposite.

A few examples of similar questions in less abstract contexts. Maybe this helps understanding why the opposite of something isn't always clear cut.

  • Cleaning your house is a chore (paradigm) that enables having a clean house. What is a chore that forces you to make the house dirty?

  • What's the opposite of a house? It is a flat plot of land or a hole in the ground in the (flipped) shape of a house?

  • What did people put on their heads before they had hats?

Opposites aren't absolute; they can be specific to a particular context (added in parentheses here). What is the opposite of a man?

  • A boy? (age)
  • A woman (gender)
  • An animal? (civility)
  • A machine? (organic/artificial)
  • A mouse? (courage)

This question is very hard to answer. You're asking about the absence of a paradigm.

The issue here is that an absence isn't always explicitly named. It's a matter of what's likely to happen when there is nothing explict in place (a paradigm) to avoid code duplication.

  • Without a paradigm in place, anything goes.
  • When anything goes, then people (especially employees) tend to pick the path of least resistance.
    • For code reuse specifically, copy/pasting code and slightly tweaking it is the most common way for code reuse to fall by the wayside.
  • The path of least resistance commonly chooses short term benefits (ease of implementation) over long term benefits (future maintenance).
  • Repeatedly making decisions based on short term benefits over a long time period renders a codebase near unfixable.

To prevent this from happening, paradigms are put in place (ideally) from the start of the project. They effectively disallow the easy option, holding programmers to a minimum standard which avoids (or at least minimizes) the eventual future maintenance issues.


Interesting to note here is that not every path of least resistance is bad. You simply never hear about the good ones, because they never end up creating problems in the future (since they were good decisions to begin with).

When you focus on the things that cause problems, you inherently ignore the things that did not cause any problems.
This is like a doctor who complains that "everyone" is sick. They are not accurately assessing the world's population's health, they're just forgetting that the people who are not sick generally don't go to the doctor to begin with. Plenty of people in the world are healthy, but the doctor simply doesn't see them.


The only real answer to your question is projects that do not have the code reuse paradigms in place.
There is no paradigm that specifically avoids code reuse. There are, however, codebases that are devoid of paradigms and therefore are liable to eventually devolve into a codebase with little to no code reuse.


Part of me suspects that you're making inferences that are not actually implied. If I were to read a statement like:

The Flater Hospital's doctors all work to improve patients' health.

That doesn't imply that other doctors don't work to improve their patients' health, nor does it imply that at other hospitals, not all of the doctors work to improve patients' health.

Similarly, just because you know of two paradigms that promote code reuse, that does not imply that there must also be paradigms that promote code duplication (or explicitly avoid implementing code reuse).

Flater
  • 44,596
  • 8
  • 88
  • 122
  • Brilliant answer, really an eye-opener! – Doc Brown Jun 05 '18 at 21:05
  • Thanks for taking the time to write such a detailed answer, but you're overcomplicating it. I wasn't thinking about paradigms that "explicitly avoid implementing code reuse", or "promote code duplication". Obviously. The two paradigms I mentioned are claimed to promote code reuse. That must mean _more than other paradigms_. What are these other paradigms? Just that. – antonro Jun 05 '18 at 21:08
  • 2
    @antonro: What makes you think there are other paradigms that don't promote code reuse as much? What even makes you think that code reuse has anything to do with paradigms? Have you checked out Peter van Roy's [poster of the 34 principal programming paradigms and the concepts they are composed of](http://www.info.ucl.ac.be/~pvr/paradigms)? – Jörg W Mittag Jun 05 '18 at 21:18
  • @JörgWMittag In the video I linked, it's emphasized that the main/subroutine paradigm promotes code reuse. When I learned about OO, they used to emphasize that it promotes code reuse. If all paradigms equally promote code reuse, why emphasize it, why even mention it? It'd would be just a property of using a paradigm, as opposed to none, like stated in the comments to my answer. "If everybody is special, nobody is" (The Incredibles). – antonro Jun 05 '18 at 21:24
  • @antonro "More" code reuse is not defined by the paradigm itself, but rather by how strongly the paradigm is implemented in the codebase. This is why there is no definitive answer, because the code reuse cannot be measured by the paradigm alone. You'd have to take sample data and calculate the average lines saved by the paradigm, which is obviously hard (which line can you attribute to which paradigm?) and still not conclusive (it tells you the current average level of implementation, which is subject to change without changing the paradigm itself). – Flater Jun 06 '18 at 03:26
  • 1
    @antonro `Some politicians claim to love their country. Which politicians love their country less?` is sort of what you're asking here. We can analyze their speeches (= the implementation of the paradigms), but we can't answer your question exactly (because speeches are not necessarily accurately representative). – Flater Jun 06 '18 at 03:30
  • @antonro: *"but you're overcomplicating it"* - I don't think so - it appears to me you have an oversimplified expectation of how an answer could look like. But some things are not that simple in reality as people wish they could be. – Doc Brown Jun 06 '18 at 06:00
  • @antonro: "Main/Subroutine" is not a programming paradigm. It sounds to me like you are asking "Why did person X say Y" and such questions are off-topic here, because only person X can answer that question, and you need to ask person X not us. – Jörg W Mittag Jun 06 '18 at 06:29
2

That would be "spaghetti code".

Think back before the days of OO or functional programming. Before even structured programming, where the data is all in structures and everything is done by neat self-contained functions.

In a World where all variables are global, and "goto" is a regular command for flow control, taking modules of code and porting them to other systems becomes extremely difficult. Mainly because there weren't any modules. It was all one monolithic lump of code.

Simon B
  • 9,167
  • 4
  • 26
  • 33
  • Well, this refers to the bad examples of unstructured programming (assembly perhaps). However, the principles of encapsulation were and local effects were understood by many, and I have seen examples that use encapsulation/information hiding/local effects in very old code, which is fundamentally reusable, for that time period. – Frank Hileman Jun 06 '18 at 00:01