• i

    Ivan Reese

    3 years ago
    @wtaysom I generally loath force directed layouts
    Me too — usually because they're something applied to your work in one fell swoop, not a tool (or suite of tools) you wield interactively. Compare: the tools used for UVW unwrapping when texturing 3d models.
    @Nick Smith 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.
    Yes, yes, hell yes. And anyone saying "In text languages, we have names, which (while sometimes problematic) are more powerful than arrows" is missing the fact that VPLs also use names: to name "functions" (whatever form they take), to name "parameters" (ditto), and sometimes even to name variables/data representations/abstractions. In a rich VPL, names are used to great effect. In this way, the visual languages are a superset of the text languages. ... Zooming out for a sec — we should all make sure we're looking at the implied higher points found by ascending from the local maxima of the best existing languages (text, visual, what have you) when discussing paradigms. The line of reasoning, "Most ______ have sucked, therefore we shouldn't bother anymore with _____" inhibits progress. Yes, most boxes-and-arrows languages have sucked. But a few of them are fucking phenomenal. When we speak of text languages, we're all proceeding with the tacit assumption that APL & Idris & Racket & other "great languages" are our baseline, not Pascal & SPARC assembly & xBase. Since we're here to study and create something better than the best of what currently exists, we shouldn't mire ourselves in the bottom of the barrel wrestling over which bad thing is most indicative of the failings of its class. ...
    @Nick Smith Two major dimensions are composition and choice. Almost every language construct in any functional language is just a combination of these. 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.
    [vibrant whirring noises coming from our brains as we take in all our favourite language constructs with these fresh eyes]
    @Nick Smith But either way, it's not up to a disbeliever to prove the absence of something; it's up to a believer to prove its existence.
    Working on that.
    i
    ibdknox
    +1
    19 replies
    Copy to Clipboard
  • Duncan Cragg

    Duncan Cragg

    3 years ago
    .. but .. something can be conceptually/theoretically very simple yet pointlessly hard to use in practice - e.g. Forth, S+K combinators, FP needing Monads to be useful, thus losing simplicity, etc.
    Duncan Cragg
    Jeremy Penner
    +6
    45 replies
    Copy to Clipboard
  • Duncan Cragg

    Duncan Cragg

    3 years ago
    .. and, I'm completely content with state complecting value and time, because as a human being it's as familiar to me that way as the air I breathe
    Duncan Cragg
    1 replies
    Copy to Clipboard
  • b

    Benoît Fleury

    3 years ago
    I personally got a lot of mileage from Rich's idea of simplicity and decomplecting, especially at small scale. It is nice to have everything decomplected. You can just drop what you don't need anymore, compose, add new things... while avoiding breakage. Many other authors advocate the idea of not overloading concepts in design. That said, we need to be careful, especially at scale. Something that may seem simple can become a mess. I would say that something like software semaphors are simple in Rich's sense. I don't think they're simple at scale. Alan Kay has a also a talk on simplicity where he emphasizes the importance to find "slightly more sophisticated building blocks". (

    https://www.youtube.com/watch?v=NdSD07U5uBs

    ) But they both seem to agree that "easy" shouldn't be a goal.
    b
    shalabh
    2 replies
    Copy to Clipboard
  • Kartik Agaram

    Kartik Agaram

    3 years ago
    @ibdknox That was what I got out of @Jeremy Penner’s point at https://futureofcoding.slack.com/archives/C5T9GPWFL/p1556655545323500 as well: The Game of Life has simple rules, but they lead to highly non-linear effects. Perhaps composability is more important than simplicity. (Simplicity = virtue ethics, composability = consequentialist ethics?)
    Kartik Agaram
    ibdknox
    4 replies
    Copy to Clipboard
  • ibdknox

    ibdknox

    3 years ago
    But! Emergent behavior is the place where bugs arise. It's where the system does things that you didn't explicitly intend for it to do.
    ibdknox
    1 replies
    Copy to Clipboard
  • ibdknox

    ibdknox

    3 years ago
    the simpler your ruleset is the more likely your system will do things you didn't intend for it to do
    ibdknox
    1 replies
    Copy to Clipboard
  • w

    Will

    3 years ago
    Two things to add. First, I just want to distinguish between emergent behavior and inconsistent models. I would expect that most bugs come from the programmer thinking the program did one thing, but then it does another. As opposed to thinking the program does something, it does that thing as you expect, but it also does another thing that’s unexpected. Second, this idea of emergent behavior in programmable systems is part of what killed off cognitive science research in programming in the mid 90s. Here’s a quote from “Let’s Get Real: A Position Paper on the Role of Cognitive Psychology in the Design of Humanly Useful and Usable Systems” (Landauer 1995): “Now consider that present computer programs and systems have sufficient com­plexity that most programs cannot be proved, and that irreducible bugs are the norm, and it is apparent that the other side of the interface is also severely limited in its theoretical tractability. When we then put humans and computers together into a jointly functioning interactive whole, we are almost certain to have a situa­tion in which all of the prediction-defying pathologies of highly complex nonlinear dynamical systems will abound.”
    w
    stevekrouse
    +1
    5 replies
    Copy to Clipboard
  • Duncan Cragg

    Duncan Cragg

    3 years ago
    You can get the benefits of emergent behavior and mitigate errant behaviour if you have good visibility of the overall system and if what you see is intuitive in human terms (thus visualisation and HCI/UX) .. going back to the cell model: simple rules of cells at the micro level can create complex macro-level behaviour, but it's not scary if it results in fun, playing the game of life, or growing a plant.. Again, visibility of state is the most important thing.
    Duncan Cragg
    ibdknox
    +2
    13 replies
    Copy to Clipboard
  • Duncan Cragg

    Duncan Cragg

    3 years ago
    Alan Kay: you can't scale and be centrally controlled
    Duncan Cragg
    2 replies
    Copy to Clipboard