The software industry has focused a great deal on CodeReuse, to …
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.
“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:
For myself, I’ve found two solutions to this problem. The first I call “the lesser,” and the second I call “the greater.”
"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:
As I thought about Code-Adaptation as a paradigm, however, I realized that, potentially, there’s an even higher level of genuine CodeReuse.
How do you write a WikiSyntax?
How do you write a regular expression, or a system of code, that supports:
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.
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.
I reverted the edit, because the text doesn’t make sense when edited in place like that.
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:
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.
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:
This has a few major benefits:
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.)
At present, I would imagine these edits as possible actions at the conclusion of discussion.
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.