David Christensen <dpchr...@holgerdanske.com> wrote:
... What is needed is way to take the best results
of TIMTOWTDI and unify them into a coherent "programming systems
product" [1]. Has anyone seen an effective way to do this?
On 04/25/2014 12:53 AM, Shlomi Fish wrote:
There's https://metacpan.org/release/Task-Kensho for that, but it may not solve
the whole problem. There are also various frameworks and systems on CPAN for
various tasks: Catalyst, Mojolicious, Dancer, PDL, Dist-Zilla, etc. What is
your vision for this coherent “programming systems product”?
I've wrestled with this idea for years and it's still hard to describe
what I'm looking for. So, I'll pick one word, "consistency", and try to
place my ideas around it.
The fundamental level of consistency that I'm looking for in a software
library is consistency of programming paradigm -- e.g. functional,
imperative, inheritance OO, interface OO, declarative, etc.. "Changing
gears mentally" on each line of code that calls into different library
modules is something I find very difficult. And, sometimes the apples
just plain refuse to plug into the oranges. So, I'm wishing for a
library that uses one paradigm throughout, but allows for accessing (or
wrapping) code written in others.
The next level up is consistency of design -- e.g. consistency in the
grand scheme of things and consistency across all of the conceptual
pieces that the library implements. So, if I learn the overall
organization of the library and then some portion of the library, I
should be able to make educated guesses about where to find other parts
of the library and how to use them. Or, if those parts are absent, I
will have some idea of how to extend the library correctly.
Finally, when I'm coding, I want consistency at the API level -- e.g.
name spaces, identifiers, constants, literals, etc. (taxonomy, tense,
capitalization, underscores), arguments and return values (positional,
named, list, required, optional, default, by-value, by-reference,
infinite stream, etc.), exception/ warning/ other messages, etc..
Coding with the library should blend naturally with the native language,
so that I can think in one language.
The above represent "systems" concerns. But, as often as not, it's
"product" issues that break me -- documentation and work flow. There is
a saying: "a good picture is worth 1,000 words". My work flow is
primary text-based using console windows on a graphical desktop. In the
past, I figured out how to create and edit drawings using a desktop
application, export those to a graphics file, convert those to HTML, cut
and paste the HTML into POD, and then generate HTML documentation, but
it was too much work. The library would benefit if the Perl tool chain
made it easy to include diagrams in POD (such as an "=image" command).
Other suggestions include automating the inclusion of synopsis scripts
(and sample runs) and generating local HTML documentation trees.
David
