On 2022-10-19 12:10:52 +1100, Chris Angelico wrote: > On Wed, 19 Oct 2022 at 12:01, Peter J. Holzer <hjp-pyt...@hjp.at> wrote: > > On 2022-10-17 09:25:00 +0200, Karsten Hilbert wrote: > > > http://literateprogramming.com/ > > > > Right. That's one of the inspirations for my comment. > > > > But literate programming is of course still very much rooted in the > > "linear text representation" paradigm. You have one definite source > > which is a linear text. > > > > In a world of IDEs, databases and hypertext that's probably not the best > > we can do. As Raymond Hettinger would say, "there must be a better way". > > > > It would be very different from mainstream programming languages, > > however. And ideally you would want it to integrate with a lot of other > > infrastructure. So that alone might make it a non-starter, even if it > > was really good (which realistically early iterations wouldn't be). > > There are special-purpose languages like Scratch which are not simple > text in that form.
Yes, I know.
It has a different goal though: Scratch tries to establish a friendly
learning environment. Get rid of typing and syntax errors that beginners
find so frustrating.
What I'm interested in is an enviroment for developing medium-sized real
applications. Somewhere in the several person-months to several
person-years of effort, hundreds of user-stories, maybe thousands of
bug-reports and change-requests over its life-time.
The people using such a system/language would be professional
programmers. They probably don't need much help to get the syntax of a
for loop right. What they do need, though:
* Cross-reference between requirements and code. (Yes, you can write
comments, yes, you will hopefully have meaningful commit messages.
Still, I see a lot of room for improvements there)
* Cross-references between related parts of the code. (Yes, many IDEs
can jump to the definition of an instance or list all instances of a
definiton, But sometimes the relationship isn't that mechanic. And
yes, you can use comments fpr that, too)
* Views which highlight some parts of the code and omit others. (Folding
editors do that in a very limited fashion)
* For example, I might want to see only the code proper when I'm
focusing on an algorithm or I might want to see lots of context
(type definitions, requirements, test results, ...)
* Classes often have quite a lot of methods with no natural order.
Being able to view only a subset of them in some custom order may
help.
* Going back to the core idea of literate programming: Especially
views which show some requirement(s) together with the code that
implements them plus some explanation why that implementation was
chosen.
Presented like this, it's clear that the "language" (i.e. the file
format) is probably the smallest part of the problem. How the user can
view the program, how they can edit it, and how to keep the whole thing
manageable is a much bigger question. And it would probably be a good
idea to start at the system level and not at the language level.
> My Twitch channel bot has a command executor whose language, if you
> call it that, is basically JSON - and the way to edit those commands
> is very Scratch-inspired.
I designed a graphical filter language for database queries once. The idea
was that you could combine various operations (selects, projections,
grouping, transformations, ...) into pipelines via a web interface. We
did implement it (sadly it wasn't me who did it), and it turned out to
be a lot harder than I thought to make that actually usable.
And of course there have been lots of CASE tools over the years. That
seems to have been mostly a fad of 90s. Still, there were some good
ideas there (although not alway implemented well), and something bubbles
back up every now and then.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | h...@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
-- https://mail.python.org/mailman/listinfo/python-list
