This article is merely musing, I can't really advise that it will be worth your while to read it.
Sometimes I think that the major unsolved (untackled?) problem in programming is the matter of separating the abstracted concept of a program from the specifics of how to do it in the given language of the initial implementation.
Example
Take my program Foldatry for example. I wrote it because I had a particular kind of file and folder operation in mind and no program had seemed to tackle it.
But, in order to realise my concept - literally meaning to make it real - I needed to try creating it in some programming language. As I had been long intending to learn Python and because it seemed to provide the features I would need, I chose Python.
To be clear, at the point of setting out to write it, I was quite confidant that what I had in mind could be done. My concept seemed inherently logical and so should be programmable. But, I knew I was going to have to "work out" the actual logic as I progressed through the coding. Hence, while I had a hunch, I did not know how much code it was going to require.
For Foldatry. the core feature I'm referring to here, is the part that became named as "matchsubtry" (match sub tree). I've described the concept in more detail at:
After writing it, thus proving both that the concept was sound and having an actual example implementation, I got on with writing other parts of the general tool that is Foldatry.
Whither Abstraction
But while I began with an abstract concept, now that I've made that concept real, writing out a just-sufficiently-detailed description of it feels like an exercise of documentation rather than of programming. This seems to beg a question of why I wasn't able to create the basis of the program in some abstract form.
This process of abstraction and re-implementation is not a great mystery to programmers, it has been done many times when "porting" a program from one language to another.
Note that I'm considering this kind of re-implementation to only be where the methods used in the program are understood. There are contrasting examples where people have looked at the running behaviour of a program and then independently written something to emulate that behaviour. Of course, sometimes that behaviour implies so obvious an implementation method that the line between these tropes is blurred.
But, as I've noted elsewhere, I didn't (and still don't) think Python is a suitable environment in which to write a reliable and performant program. Thus I consider Foldatry to merely be a working prototype for other people to take its ideas and implement them in a better language (e.g. Rust).
Ah, but is there a catch? That perhaps I have inadvertently buried the port-able concepts in among the idiosyncrasies of Python?
What if there was a way of writing some meta-form of Foldatry that expresses the cross-language concepts of the program? At a first level, such a meta-program could be used by other people to guide them in implementing an adaptation of Foldatry into some other language and/or environment. At a second level, could such a meta-language be usable to generate quite a lot of the other language program?
Now, of course, I'm not naive enough to imagine I'm the first to think along these lines. Indeed I'm sure I sketched thoughts like this back in the 1990s or even the 1980s. I have deliberately chosen to write this article before I go looking online to see what ever has been worked out along the arc.
I am aware that there are many web sites and/or service companies that offer to automate some parts of the language conversion process. I do not have the impression that any of those work so well as to cause programmers in general to see them as obvious paths to take.
Another example - Tk
Part of the prompt to write this piece was a morning's coffee musing about my use of the Tk GUI library (via the Python Tkinter module) in Foldatry and the extent to which that also traps the program into Python. There seems to be a static subset of languages that have well established usage of Tk - and that still leaves out most compiler based languages.
Indeed, the way that all the supported uses of Tk seem to exist is by linking to the dynamic Tcl and Tk libraries as written in C. This helps explain why there is no such thing as Tk support for JavaScript or Go (as in golang).
The reason I bring up Tk in this context is that my impression of it, is precisely that its use sits inside a Python program as a form of minimal concept expression. Tk uses its own abstractions such as Frames and allows the coder to only specify the things that are crucial to how the GUI will operate (well, operation and layout, really).
As I was writing the GUI section of Foldatry I found that there was a nice fit between me trying to find the logic of how various parts of my program's interface should relate, and how Tkinter required me to specify things. As a consequence I'm hoping that were I to re-implement it - in another language and another GUI toolkit, that I would be tasked only with how to reinstate the concepts in the new environment - and not be unpicking parts of how Tkinter works, (But that, of course it merely a guess.)
Abstraction and Re-implementation
While my title for this article is - Abstraction vs Specifics - it is perhaps better given as "Abstraction and Re-implementation" because that is the task that often confronts us in development. While I've given the example of translation from one programming language to another, it might just as well have been about keeping it in the same language and trying for a fresh implementation. Especially as that perhaps happens just as often. Yes, this is where we insert a certain megacorp's numerous claims to have "rewritten from scratch" their products - a claim that has proven to be false for every instance I've ever inspected.
We've been at this programming thing for quite a while, and yet we still don't have any "standard" (meaning: in common use) pseudo-code language. We programmers merely take that as read, but perhaps we should occasionally ask ourselves why that is.
I have seen people inadvertently suggest that Python might itself be such a language. Sadly that suggestion is farcical but I can see the good thought that prompts it.
- To avoid getting too catty about Python, let's recognise that Python was intended as a multi-paradigm scripting language, which is enough to validate the suggestion. Perhaps if it had stayed simple then it might have served as one, but the numerous infiltrations from the C-Python implementation into the definition of the language surely stopped Python being a simple and clear language many, many years ago now. Much of what is written in contemporary Python now is essentially cryptic puzzles to 90% of programmers (yes, including those who code only in Python).
I'm not trying to suggest that the needed panacea is any particular pseudo-code definition, rather I'm pondering what the good-enough set of programming concepts would be, so as to support one or several pseudo-code regimes.
This might involve some heavy thinking about which paradigms are vital and which merely convenient. There are plenty of web pages out there stating the important paradigms so I won't try to list them comprehensively here. But I also don't want to play hard to get, so obviously we are talking here about such things as: expressions, iteration, recursion, procedural, object-oriented, functional etc. The wars about which of those are ideal for workaday, practical, commercial, scalable (the adjective list here is probably endless) programming can continue unaffected. I am only interested in what would make for something good enough to act as a broad way to write out the vital concepts of a given program idea.
Or perhaps, we haven't achieved such a thing because it isn't possible. As in fundamentally, inherently impossible.
Or perhaps we haven't achieved it because it is our behaviour to not come together well enough to make one work.
Top comments (0)