“If you can’t explain it to a six year old, you don’t understand it yourself.” — Albert Einstein
@David_Tschumperle provided this assessment in Image processing made easier with a powerful math expression evaluator.
Alas! David’s personal blog, opensource.graphics, dropped off the Internet sometime between 01-December-2021 and 23-February-2022, when it was first spied in the claws of some shiny-pants domain-name flippers. Thanks be to Brewster Kahle and friends for being on the planet, because the Internet Archive’s Wayback Machine grabbed David’s pages before opensource.graphics slid forever beneath the (digital) ocean waves.
Since a Wayback recall can be dreadfully slow, I’ve excerpted the quotes that, I think, conveys David’s original G’MIC motivations (but don’t trust my interpretations — read the entire post if you can suffer through the download):
To be more precise, an important part of my work is even to design (and hopefully publish) my own image processing methods. Most of the time of course, my trials end up with clunky, ineffective and slow operators which give nothing interesting else than knowing the approach is not good enough to be followed. Someone who says everything he tries works right the first time is a liar. Step by step, I try to refine/optimize my prototypes or sometimes even take a completely different direction. Quickly, you realize that it is crucial in this job not to waste time when doing algorithm prototyping because the rate of success is in fact very low.
That’s actually one of the reason[s] why I’ve started the G’MIC project. It was primarily designed as a helper to create and run custom image processing pipelines quickly (from the shell, basically). It saves me time, everyday.
So whilst you’re in the discovery playpen, a tool that gets you quickly past the junk-thinking is very important indeed.
David further writes that this motivation not to waste time with tool mechanics extends down to the pixel processing scale, the math expression evaluator’s operational level, and that if he wished to have a playpen of ready-to-use pixel processors on par with the utility of macro-level G’MIC commands, then he needed to teach the math expression evaluator how to do looping constructs, thus transporting the math expression evaluator from the realm of elementary expression parsing (a calculator) to something resembling a programming language. But the necessary modifications to CImg.h, where the math expression evaluator lives, seemed technically in reach and the goal was a good one:
Until now, when I was trying to implement this kind of algorithms, I was resigned to go back coding them in C++: It is one language I feel comfortable with, and I’m sure it will run fast enough most of the time. Indeed, computation time is often a bottleneck in image processing. Some of my colleagues are using scripting languages as Matlab or Python for algorithm prototyping. But they often need some tricks to avoid writing explicit code loops, or need to write at least some fast C/C++ modules that will be compiled and run from those higher-level interfaces, to ensure they get something fast enough (even for prototyping, I’m definitely not talking about optimized production code here!)
But, I’m not really satisfied with my C++ solution: Generally, I end up with several small pieces of C++ sources I need to compile and maintain. I can hardly re-use them in a bigger pipeline, or redistribute them as clean packages without a lot of extra work. Because they are just intended to be prototypes: They often have only basic command-line interfaces and thus cannot be directly integrated into bigger and user-friendly image processing frameworks. Making a prototype algorithm really usable by others requires at least to wrap it as a plug-in/module for [ …copy the name of your favorite image processing tool or language here… ]. This generally represents a lot of boring coding work, that may even require more time and efforts than writing the algorithm itself!… I’d definitely prefer a simpler solution that let me spend more time on writing the algorithm itself than packaging it or making it usable. After all, the primary purpose of my work is to create cool algorithms, not really coding user interfaces for them.… [So], how to make those prototyped algorithms finally usable without spending too much time on making them usable?
So, methinks, “to have a playpen where one can concentrate on the game at hand, with a minimum distraction from the language’s execution requirements” is not a far-off assessment of @David_Tschumperle’s gmic motivations. And if you allow me to voice an impression or two on your own oeuvre, I think I can make the case that your choice of the word ‘disagree’ is not entirely apt, considering the words that follow: your game runs orthogonally to that of the ‘G’MIC-as-playpen’ model I advanced. Not at loggerheads, but at right angles, thereby increasing the span of the discussion space. In ways far beyond my game, you canvass where image-processing and -generator artists water and assess the closed-source or undocumented tools they’re (trying) to use, and reverse-engineer these as filters for the gmic_qt plug-in, making functional work-alikes available wherever gmic_qt lives. That is good work, but offers up its frustrations in the realm of how well interpretive languages like gmic map to the computational resources of hardware: so your words following divulge — not disagreement! — but a keen interest in the operational innards of gmic and the math expression evaluator, this with the aim of finding optimal coding technique. That is not entirely athwart with @David_Tschumperle’s ‘G’MIC-as-playpen’ aims, nor is it entirely aligned. David, methinks, is willing to forego some performance in gmic so long as the environmental housekeeping chores remain slight. On the other hand, your appetite for performance remains whetted.
Fortunately, before he fell into the research scientist rabbit-hole, he plied the software engineering trade, and like most worthies of that profession, takes a particular pride in his work, and is not disinclined to better that effort — so long as it does not distract too much from the siren song of research. Be gentle with him, for whatever else there might be in his lot, there is that militant, radical, bomb-throwing-whilst-Einstein-quoting Technical Writer, who has herded onto the Discourse server with all the rest of the maverick cats, and wants people to just be able to read the stuff. Or so he claims. But, should there be a frisson of apprehension coursing through the place, it may be that the Technical Writer could fall over — any minute now! — and start shilling All The Rules of The Software Development Life Cycle, this louder than a NYFD hook-and-ladder caught in the 5 PM rush. ‘David: comment your code!’ ‘DAVID! What the h-e-double-tooth-picks is $=a supposed to mean???’ ‘Daaaa-vid! Your math expressions look like the noise of a dropping comm line!!!’ ‘DAAAVID — *!*’
Fear not. The Technical Writer has mellowed in his age. Somewhat. A little. Perhaps. But don’t nudge him; he may yet fall over and then have Words with you too.