CodeReuse

new: 2021-01-29 10:07 UTCLionKimbro:

The software industry has focused a great deal on CodeReuse, to …

…mixed results.

Some things work great: Strings, linked lists, dictionaries/hashes, – there are certain structures that get used, and reused, over and over. Often, these highly reusable structures are even worked into the ProgrammingLanguage itself.

And of course, there are popular libraries and frameworks, or even entire computing platforms.

More mixed to my thinking, the sometimes brittle pyramids and towers of packages delivered by package managers.

But there’s a place where CodeReuse has not really lived up to the dream. I’m now recalling a quote from somewhere; Someone lamenting the broken promises of ObjectOrientedProgramming --

“Yes, you want to use a banana, so you pull it into your code. But oh, that banana is connected to a gorilla. So you have to pull that gorilla into your code base as well. But that gorilla is connected to a palm tree, so you get that too. And an island. And an ocean. And neighboring contents. And even an entire planet.”

It seems like there’s so often something that makes something difficult to reuse:

  • It’s in the wrong language.
  • It’s not performant in some critical operation.
  • It depends on software that you can’t, or don’t want to, include for some reason.
  • There’s a feature you need it to do, and it’s not there, and the system is so complex, that it needs to keep promises that you don’t even understand, so you wouldn’t dare try and change it, even if you could figure out how to change it.
  • It does 100x more than you want, and it’s increasing the attack vector from a security angle, on your system. It gets updated all the time, for pieces of systems that you never even wanted.

new: 2021-01-29 10:07 UTCLionKimbro:

For myself, I’ve found two solutions to this problem. The first I call “the lesser,” and the second I call “the greater.”

CodeAdaptation

"Most people's software systems do everything. But MY software systems let you do anything."ChuckMoore (NOTE: he probably didn’t literally say this, but I recall him saying something very much like it.)

If you make a sufficiently simple system, and focus on “How can I absolutely maximize the ratio of functionality/complexity”, then you can make a very small system that does the essentials of what a system should do, and then leave it to the programmer to adapt the code to do the specific things for the problem at hand.

Some elements of a Code-Adaptation approach include:

  • No hooks. You are supposed to actually understand how the code works, and change the actual code. It’s not a black box. Understanding how the thing works, is how you know how to adapt it.
  • Minimal complexity. You are supposed to actually understand how the code works, so it has to actually be understand-able. So it can’t be complex beyond basic needs. The programmer will add his or her own complexity to the space, when adapting the code.
  • Multiple sources. There may be different “prototypes” of the basic code configuration, so that the user can start from a place that makes the most sense.
  • Explanation. You are supposed to actually understand how the code works, so there should be some explanatory material to help you understand it.

As I thought about Code-Adaptation as a paradigm, however, I realized that, potentially, there’s an even higher level of genuine CodeReuse.

IdeaReuse

How do you write a WikiSyntax?

How do you write a regular expression, or a system of code, that supports:

  • bold text
  • italic text
  • hyperlinked text
  • wiki words

I still don’t know how to do it. I know how to do a lot of things, but this thing, I don’t know how to do it. I’ve experimented before, and done it wrong. I can’t remember what the problems were – but I remember wrestling with problems of overlaps, of making sure that the left and right sides aligned, various issues.

Is there a book I can find, on how to write wiki page renderers? And that explores the problem space?

I have a beautiful programming book that I bought: Dataflow and Reactive Programming Systems: A Practical Guide. It is very slim, small, and short. It covers data flow programming at the level of – I’ll call it: “Practical Theory.” And there is zero code in it. Not one line.

What it does do, is show the different ways of modeling dataflow systems, and describes the advantages and disadvantages of the different ways of programming them.

Another example is DesignPatterns, which are a great example of Idea Reuse.

Wouldn’t it be great if there were a website that collected fundamental techniques of writing different kinds of constructions of code?

Wouldn’t it be great if there were practical and accessible studies of how to model things?

Some people knit sweaters. They get yarn, they get a book that shows “these are the steps you do, here’s a pattern you can use, go to.” Wouldn’t it be great if we could just do similar with programming things?

Then you could just read it, and start knitting, in your language of choice, respecting your constraints, taking advantage of your platform where you can, and compensating where you must, but always with the steady guide of the fundamental idea blueprint.

It seems to me that the highest form of “reuse” that can be done in the world of software, is the reuse of ideas.

I am still astonished that there is so much literature dedicated to libraries and frameworks, but that there are so few books that focus on ideas, and “how to do it on your own, from a conceptual basis.”

There are books on how to do basic computer algorithms – linked lists, graph traversal, binary trees, and thankfully, some computer graphics, say, … but after that – “poof,” there’s very little out there.

See Also

Discussion

new: 2021-01-29 10:07 UTCLionKimbro:

Timur had suggested, via edit:

The most popular approach is to write a RegularExpression. It works fine for regular single-line stuff but is not the best choice for multi-line stuff or blocks that can vary from time to time. In general, the universal approach is LexThenParse?. Note that HTML in browsers, all industry-level programming (and not only) languages are done with this approach. The point is to break down the source text (WikiMarkup, in our case) into a stream of tokens or lexemes which you then can turn into target language (HTML, in our case). There is no formal book that focuses on the topic of wiki markups, to our knowledge. But there is a big choice of books on parsing. TODO: link some books maybe? 🍄A friend of mine recommended me «Языки программирования» by Свердлов С.З., but I doubt it’s a good recommendation for an English wiki like this one.

new: 2021-01-29 10:07 UTCLionKimbro:

I reverted the edit, because the text doesn’t make sense when edited in place like that.

That is:

The point of asking “How do you write a WikiSyntax?”, is in service to the point of saying something about IdeaReuse – not to get an answer. Answering the question in-place, defeats the purpose of the question.

Here’s kind of the logical structure, in an outline form:

  • IdeaReuse – opening the composition
    • The example of WikiSyntax: a need that is not met by literature
      • “How do you write a WikiSyntax?” – pointing out a motivating question, that readers can potentially relate to
      • “Is there a book I can find, on how to write wiki page renderers? And that explores the problem space?” – pointing out that there is a gap in the space of literature, again a material (vs. abstract) need
    • An example of where the literature gap is met: DataFlow? & Reactive Systems
    • Another example of where the literature gap is met: Design Patterns
    • An example of where the literature gap is met in another field: Needlework, and Dress Patterns
    • The abstract point, to be formed in the reader’s mind: This can be done with software, even though we don’t, beyond basic computer algorithms.

When the question of “How do you write a WikiSyntax?” is replaced with its answer, it no longer makes sense within the narrative structure of the statement.

“If I want to answer Lion’s question, where do I do so?” In the discussion section, down below.

new: 2021-01-29 10:07 UTCLionKimbro:

The question arose elsewhere, (in discussion at the bottom of TheWysiwygContractProblem,) “Is the text before the Discussion heading ThreadMode or DocumentMode.”

The short answer here is: This is a very, very long ThreadMode message, presented as a document.

The question then is something like: “What is the RefineryProcess? for the page, then?”

I think my own answer to that, would be:

  • If the page is unimportant, it doesn’t need one.
  • If the page is important, and therefore worthy of community time (considering the ReworkingEconomy,) than the process looks like so:
    • The page is discussed in the ThreadMode, in threaded discussion.
    • If the page needs rework during the discussion, the author of the page, or a volunteer if the author is unavailable or yields, is the PageMaintainer during the discussion, reworking the page as the people discuss.
    • As the people develop consensus, whether by PageMaintainer or not, the DocumentMode portion of the page (above the Discussion line) is rewritten with attention to the document as a whole making sense.
    • When the conversation is complete, if everything essential has been worked into the DocumentMode, (and possibly into other pages on the wiki as well,) the ThreadMode is then deleted.
    • However if the conversation is not complete, or essential discussion has not been worked into the DocumentMode, then the ThreadMode can be simplified into a summary, and here we can work in the SummaryWanted concept.

This has a few major benefits:

  • It preserves the integrity of the structure of a document. (The problem of which, is visible in my last comment – where a rework “breaks” the communication that it operates within.)
  • It respects the ReworkingEconomy. Where reworking is done, it is performed economically, and with guidelines about authority so that people do not feel that their toes are stepped on, or wonder who carries responsibility (the SocialReworkingDilemma).
  • It avoids the problem of ForestFires, by keeping the conversation isolated to ThreadMode, until consensus develops. A “forest fire” is when page after page are created, within a single epoch of argument, or when the management (or mis-management, …) of an argument otherwise gets out of hand.

new: 2021-01-29 10:07 UTCLionKimbro:

So applying this philosophy to this very discussion, – Should we reach an agreement about these concepts, then we would relocate this text to a page called “RefineryProcess?,” (or some other new name that we come up with, perhaps in the coarse of ThreadMode discussion,) and now we have the pages organized and reflective of our discussions. But until that point is reached, we continue to discuss here. That is, our thinking may go in a very different direction, and thus what we would do when the time comes, is restructure the wiki (by adding pages, making edits, etc.,) in a very different way. (This is the piece about “economizing” edits. Make relatively expensive edits, especially expensive edits like the creation of new pages, especially new sets of pages, when it becomes clearer about what the desired shape is going to be.)

new: 2021-01-29 10:07 UTCLionKimbro:

At present, I would imagine these edits as possible actions at the conclusion of discussion.

  • A page on WikiSyntaxProgramming?, on the pragmatics of programming a WikiSyntax.
    • This could be a ShortPage? or a VeryShortPage, but I personally think it’s worth putting some notes into. We may want to visit, and it’s within scope for CommunityWiki, I think.
  • A page on the CommunityWikiRefineryProcess?, representing our own consensus – or lack of consensus!
  • A page on RefineryProcess? developments for wiki in general, and how a wiki comes to understand and develop its own process.
  • Reworks to this page itself, reflecting the state of the conversation on CodeReuse, CodeAdaptation, and IdeaReuse.

It is also possible that we would decide that, “This just isn’t a very important discussion,” and the pieces could linger here, and that’s fine too. The ReworkingEconomy is called an “economy,” specifically because the labor to rework is on an economy, and only things that are sufficiently important warrant the work of reworking.

(CommunityWikiFooter)

Define external redirect: ShortPage RefineryProcess LexThenParse CommunityWikiRefineryProcess WikiSyntaxProgramming DataFlow

EditNearLinks: ProgrammingLanguage ForestFires VeryShortPage WikiMarkup RegularExpression DocumentMode ChuckMoore DesignPatterns ObjectOrientedProgramming

Languages:

The same page elsewhere:
Wiki:CodeReuse