for -- else: what was the motivation?

Drew Pierson drewmossedyou1 at gmail.com
Sat Oct 22 11:32:10 EDT 2022


the fuck?

On Sat, Oct 22, 2022 at 9:06 AM Peter J. Holzer <hjp-python at hjp.at> wrote:

> On 2022-10-19 12:10:52 +1100, Chris Angelico wrote:
> > On Wed, 19 Oct 2022 at 12:01, Peter J. Holzer <hjp-python at 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.
> |_|_) |                    |
> | |   | hjp at hjp.at         |    -- Charles Stross, "Creative writing
> __/   | http://www.hjp.at/ |       challenge!"
> --
> https://mail.python.org/mailman/listinfo/python-list
>


More information about the Python-list mailing list