• Nick Smith

    Nick Smith

    3 years ago
    I guess spreadsheet languages qualify too, though I haven't found many of them interesting
    Nick Smith
    1 replies
    Copy to Clipboard
  • Stefan

    Stefan

    3 years ago
    It's 90% boxes-and-arrows, 8% Scratch clones, and 2% of unique stuff
    This strikes me as an important insight which leads to the question, “Why is the distribution so heavily skewed towards boxes-and-arrows?” If we’d be completely in the dark, couldn’t we expect a lot more variety? Maybe one possible answer has to do with the challenge that building a generic visual programming system is by definition domain-agnostic and therefore can’t take advantage of established metaphors in a target domain? I’m thinking of (as usual) music or video production tools, where a lot of the visual tools rely on metaphors that represent time by mapping it to (horizontal) space, which rests on the importance of time in these domains. If you can’t define certain specifics because you want to create something universal, the visualizations available to you will be limited to the most abstract of domains, often math — and then you end up representing minimal structure as an abstract graph, with generic arrows, their positions and lengths without meaning, pointing from and to equally as dimensionless boxes, all floating in a space that has no meaningful coordinates either — you can move things around and it doesn’t change anything other than the visualization.
    Stefan
    1 replies
    Copy to Clipboard
  • Stefan

    Stefan

    3 years ago
    The more I think about it, the more I feel like replacing text with another form of visualization isn’t going to be the solution. Text-based programming is better with an IDE that offers different visualizations for different tasks/contexts (hat tip to @Tudor Girba). So I think the question is not “What will replace text-based programming?” and instead “Which visualizations will enhance programming so much that we find ourselves preferring those over text in specific contexts?”
    Stefan
    ogadaki
    +6
    31 replies
    Copy to Clipboard
  • Nick Smith

    Nick Smith

    3 years ago
    I'm seeing the proliferation of this false dichotomy again between text and visuals. Text IS a visual. This is a more relevant point than it appears at first glance. It indicates that you can mix text with other kinds of visuals. Despite what has historically been produced, the other kinds of visuals do not have to be in the form of boxes and arrows, or lego blocks, or anything which has proven itself objectively bad through 5 decades of repeated failed attempts. I believe people designing these visuals just need to try something different. It's true that there aren't many concepts in an abstract language that can even be visualised. But there are some. Two major dimensions are composition and choice. Almost every language construct in any functional language is just a combination of these. (Imperative languages throw in 70 other "features" which I argue makes visualisation a fool's errand). Function application, function composition, product types, and sum types are just different flavours of composition. If-expressions, case-expressions, and pattern matching are all just different flavours of choice. Visualising these naively leads you to some kind of graph, which leads to a naive boxes and arrows visualisation. But Stefan rightly points out that humans are good at recognising names, and are bad at navigating a soup of arrows, so we should probably use names as the building blocks of the visualisation. This does not necessarily lead to "text-based programming", but it does lead to a generous use of text within the visualisation.
    Nick Smith
    1 replies
    Copy to Clipboard
  • Nick Smith

    Nick Smith

    3 years ago
    So to come full circle: representations do matter, and there is still, despite historical failings, an opportunity for visual representations to improve comprehensibility. It's easiest to see when you look at learners, but they needn't be the only ones to enjoy the possible benefits. Give me a few weeks to produce a demonstration of the kind of representations I'm talking about and maybe it will be easier to believe my argument.
    Nick Smith
    y
    3 replies
    Copy to Clipboard
  • Edward de Jong / Beads Project

    Edward de Jong / Beads Project

    3 years ago
    in building many products over the years, the best test of how good the interface was, was to put the product into the hands of seniors or young children. Both are excellent test audiences. If it is truly intuitive, the kids pick it up fast. If it is simple and well organized, the seniors will respond. Both groups have different strengths: seniors have no memory, and kids have little abstraction power.
    Edward de Jong / Beads Project
    1 replies
    Copy to Clipboard
  • Kartik Agaram

    Kartik Agaram

    3 years ago
    @Nick Smith Looking forward to it. I had no idea you were one of us with experience teaching kids. Here’s what I did for two years, and it worked great in a 1-on-1 setting: http://akkartik.name/post/mu (Spoiler: it’s absolutely text-based). I saw no problems with (a small number of) keywords. I did see value in minimizing punctuation. One implication: don’t start kids on one of the Lisps. (Even though I love Lisp in general.) I don’t understand your “It’s 90% boxes-and-arrows, 8% Scratch clones, and 2% of unique stuff” comment. Why chase novelty for its own sake? Similarly, I don’t think boxes and arrows or blocks have been given nearly enough rope in the last 5 decades. You’ll need to elaborate on why you think they’re “objectively bad”. It’s not at all obvious that we need to try something different. One could equally make the case that we need to persist with and incrementally improve already-attempted ideas. (I say this as someone pro-text for the most part.)
    Kartik Agaram
    Nick Smith
    +4
    11 replies
    Copy to Clipboard
  • Tim Swast

    Tim Swast

    3 years ago
    I just attended Linux Fest Northwest, and there were a lot of GNU / FSF people there. It got me thinking again about that community, and I think they're motivation aligns well with this group. They want software to be modifiable in ways that aren't legally encumbered, whereas this group wants software to be modifiable in ways that aren't unnecessarily complicated. I wonder how this group would modify the FSF's 4 user freedoms to align with the goals of the future of coding?
    Free [libre] software means users have the four essential freedoms: (0) to run the program, (1) to study and change the program in source code form, (2) to redistribute exact copies, and (3) to distribute modified versions.
    Tim Swast
    Kartik Agaram
    2 replies
    Copy to Clipboard
  • p

    Peter van Hardenberg

    3 years ago
    Who here has tried the new Dreams "game" for PS4? I feel like in many ways it represents the fulfillment of the dreams of a lot of folks here.
    p
    g
    +5
    22 replies
    Copy to Clipboard
  • i

    Ivan Reese

    3 years ago
    I highly enjoyed the recent discussion of Visual Programming Languages. Here are some of my favourite quotes, that seemed to capture something particularly meaningful to me. (Sorry about all the notifications <= credit where due. Broken into a few messages due to message length limits.)
    @Edward de Jong / Beads Project very few languages today include FSM syntax, even though it is one of the key fundamental components of every program. Also, in every real-world FSM you have the possibility that one of the steps will fail. Having a system fail softly on a key step failing is a very interesting aspect neglected in most languages.
    Warm take: Any new [visual?] language worth its salt should include a simple, generic FSM facility as part of the standard library.
    @Stefan [...] an abstract graph, with generic arrows, their positions and lengths without meaning, pointing from and to equally as dimensionless boxes, all floating in a space that has no meaningful coordinates either — you can move things around and it doesn’t change anything other than the visualization.
    It feels like there's another shoe yet to drop, when it comes to the design of VPLs — even the boring, traditional "node-and-arrow" ones. Giving the graphical characteristics of a visual language heightened meaning, representation, and dynamism is easily imaginable, and under-explored (evidence to the contrary heartily welcomed — I'll add it to the codex). So why don't we have it yet? One theory: used to be a painfully high bar for creating dynamic visual environments, but the explosive advancement of video game authoring tools is really lowering that bar. I mean.. have y'all played SpaceChem? Despite its intentionally constrained GUI (it is a game, after all), it's richer with metaphor than any VPL I've yet laid my mouse on.
    @Tudor Girba it’s also important to distinguish between the way we write and the way we understand code. Whenever we talk about programming languages, we tend to conflate the two. The code is always consumed in the same shape it’s written in. I believe that is unnecessarily limiting.
    This is probably my favourite reason to be optimistic about visual languages. With a text language, programmers would not tolerate the structure of their program being changed willy-nilly by their IDE. You expect the code to execute in the order it's written, within the scope it's declared, conveyed by the file you've allotted to it. With a visual language, programmers could be more permissive of wild alterations of structure and substance of the code in flagrante, including things like: which connections actually exist, how visual code-elements are laid out, how many & which names are assigned to a given thing, whether data may only flow along programmer-established paths, what data is present in the system, whether the execution model should be deterministic or not, and so forth. Why more permissive? Both for the cultural reason that this is uncharted territory free of the spectre of entrenched norms, and for the technical reason that visual communication allows a plurality of representations of the same fundamental thing, all of which can be treated as variably "real" or "virtual". The artifact of writing does not allow this flexibility — at most, it has typography; there's no "impressionistic" lettering versus "abstract" lettering, outside of concrete poetry. Again, the space of powerful system-building interfaces with shifting representations of the system has been best explored by video games (as a whole — not any specific game). But it's also been very well explored by 3D modelling/animation tools, which must show many, many different-but-mostly-equivalent representations of their data, all of which with subtly different degrees to which a detail is "real" or "virtual". All existing visual language GUIs (*That I've seen — counterexamples welcome) seem starved by comparison.
    i
    1 replies
    Copy to Clipboard