• j

    Josh Marinacci

    3 years ago
    i get the feeling there aren’t strict separation between declarative and imperative. it’s a spectrum and real world languages fall somewhere on the spectrum
    j
    d
    +4
    27 replies
    Copy to Clipboard
  • d

    Dan Swirsky

    3 years ago
    I'm designing a language that takes both roads. Objects are defined declaratively (and in any order), but object property values may be "defined" imperatively or declaratively. If the value of an object property depends on the value of another object property, its value is (by default) reevaluated (i.e., reactively) whenever the depended-on value changes. Like in a spreadsheet, but without the spreadsheet.
    d
    d
    +1
    4 replies
    Copy to Clipboard
  • Scott Anderson

    Scott Anderson

    3 years ago
    Scott Anderson
    1 replies
    Copy to Clipboard
  • Dan Cook

    Dan Cook

    3 years ago
    I'm just going to spill some thoughts here: There are multiple aspects to making programming more comprehensible, or perhaps even properly doable in the first place. The first obvious one is language. But even if you could have the perfect language, textual code is not the best for comprehending and manipulating complex models. So then there's presentation & modeling: perhaps some things are much better represented in a visually, or much easier to edit or build if working with a direct structure (rather than a typed out one). But if your program-flow is a mess or the abstractions are bad, then it's going to be hard to follow regardless. So then there's the actual form of the program itself: does it lay out what it is and what it does in a fairly straightforward and obvious way? How big of a gap is there between a human understanding of the software, and how it reads? Do you have to reverse engineer the code to make sense of it? All these things are essential: the presence of one cannot compensate for the absence of the other. For example, you can have a horrible mess of code, but that horrible mess can be diagrammed in a way that makes the exact nature / layout of that horrible mess immediately obvious. And having the flow and components of a program be obvious at a glance, does not mean that that flow itself is not convoluted and hard to follow in it's own rite. And likewise, a mass of textual code may do a horrible job of making a program easy to understand by looking at it, but the components and flow of the program may be laid out well and very easy to follow. I have a couple points about this, but I'll have to save it for a follow-up post
    Dan Cook
    Pezo - Zoltan Peto
    2 replies
    Copy to Clipboard
  • r

    rntz

    3 years ago
    @Daniel Hines what kinds of problems do you see answer set programming as being particularly well-suited for? I've heard of it and know vaguely what it does (finds all minimal models, like Datalog but without the stratification condition), but don't know what I'd use it for.
    r
    d
    3 replies
    Copy to Clipboard
  • Dan Cook

    Dan Cook

    3 years ago
    There are plenty of instances of badly written software putting lives in danger. And true, it was a new field at some point, but what still is allowed to pass as "professional" software is alarming and embarrassing. So that's one of my main points: on the whole, it's like even basic fundamentals of designing coherent software are by and large missing, ignored, or not even grasped. Things like proper decomposition and abstraction, etc. My guess is that this is largely due to that fact that you cannot "see" what's in a program: the data flows and execution flows, etc. Like many programmers are so used to having to decipher code anyway, that they either don't realize that it doesn't make sense, or that it can make straightforward sense. There are multiple times in my career where I've thought to myself: if the components and flows and organization in our code was something physical that any non-programmer could walk by and see -- if it was at least vaguely visible what their software "engineers" were doing with/in their software -- the business would be appalled. Hey, that's our name on that! We don't have time and money to waste this convoluted nonsense! We expect or customers to rely on this stuff! I know many consider this to be a subjective matter, but I'm not taking about I prefer Jim's style of writing versus Joe's, I'm taking about Sarah laid out the business requirements in two clear paragraphs and a few bullet points, and Sue wrote 5 pages about the same thing with no coherent train of thought. (names and examples are made up). My point is that language and tools will not fill this gap, but is something that needs to be understood and fixed in it's own rite. HOWEVER, I do think it can help tremendously if it's obvious at a glance whether a program (or software component) is straightforward, or horribly convoluted. If we can see what we're doing, maybe we can begin to understand what we're doing, see what we're doing, and talk about it and take ownership of it. (This is mostly coming from a context of what happens in professional software development, based on my experience and observations)
    Dan Cook
    1 replies
    Copy to Clipboard
  • Wouter

    Wouter

    3 years ago
    @Dan Cook I think you are over estimating the amount with which new representations can make code clearer, or at least, we haven't found such representations yet. There is plenty of super complex code out there that even a well meaning, talented programmer couldn't make simple, be it by "decomposition and abstraction" as you say (which are very limited in their power), or by using better representations of the code. The real complexity is in the "logic" (for want of a better word) of the code, and we have no silver bullet to simplify it.
    Wouter
    d
    +2
    29 replies
    Copy to Clipboard
  • John Austin

    John Austin

    3 years ago
    Not sure if this has been posted before, but this is quite close to the sort of thing I've been working on: http://nodes.io/
    John Austin
    i
    +3
    10 replies
    Copy to Clipboard
  • Benjamin Gudehus

    Benjamin Gudehus

    3 years ago
    So, I’ve been working on expert systems for two years. The central pitch (of a rules engine) is that it will allow business people to build their rules without programmer involvement. sounds nice, but is not often nice in practice. rule systems can grow very hard to maintain over time. and you maybe need tooling so you can cope with it by detecting overlapping rules or visualize the program flow. There is also the question, what skills you need to author and maintain rules. Do people who author rules automatically learn quasi programming skills? Is it maybe better to let (carreer) programmers author the rules, and have business-readable notation instead, to still allow to build a rich and deep communication channel between programmers and business/underlying domain? I’ve been reading halfway through “out of the tar pit”, watched half a dozen of lighttable/eve talks with all the eve experiments, and look into vega dataflow code. I think I’ll work in this area more in the upcoming months.
    Benjamin Gudehus
    i
    +1
    3 replies
    Copy to Clipboard
  • Benjamin Gudehus

    Benjamin Gudehus

    3 years ago
    Ahh, and the idea is to blog and open-source code while learning and building prototypes. Starting with an analysis of the vega dataflow paper (Reactive Vega: A Streaming Dataflow Architecture for Declarative Interactive Visualization) and code examples.
    Benjamin Gudehus
    d
    3 replies
    Copy to Clipboard