• robenkleene

    robenkleene

    2 years ago
    Is there any hope for end-user programming when programmers themselves don't use programming to solve their own problems? For a long time, I've been asking myself the question about why more programmers don't use programming to solve their own problems, but it just occurred to me the implications of that to end-user programming. Does end-user programming ever have a chance of succeeding for non-programmers to solve their problems if programmers themselves aren't using programming to solve their problems? When I say programmers don't solve their own problems with programming, what I mean is, there is sort of a ladder of useful techniques to use programming to make programming itself easier. It starts with customizing your shell or your text editor by cut-and-pasting code snippets you find online, and progresses to writing your own customizations from scratch, to writing your own shell/text editor extensions, and finally to writing your own full programs to solve your own problems. I find it so odd that it's so rare for any of the programmers I know personally to progress beyond the first stage (some light shell/text editor customization by cut-and-pasting some code they found online). Since programmers are experts at programming, and they generally choose not to use solve their own problems with programming, what hope is there for end-users to use programming to solve their problems? Or is there something wrong with the lens I'm looking through here? Perhaps programmers are using programming to solve their own problems in a way I'm not seeing? (I.e., that aren't shell and text editor scripting)?
    robenkleene
    e
    +15
    153 replies
    Copy to Clipboard
  • Kartik Agaram

    Kartik Agaram

    2 years ago
    I'm going to start an opinionated overflow thread for the previous discussion (https://futureofcoding.slack.com/archives/C5T9GPWFL/p1599588394135900) Why programmers shouldn't program for themselves (my editorializing) Focusing on "quantity of programming" feels like the wrong frame. My ideal society of people educated in programming may not involve most people actually doing much programming most days. What matters is the potential. Compounding advantages from programming for one day per year. * Impulse to generalize is self-limiting (some maintenance burden may be irreducible). A good end-user computer needs to be extremely parsimonious in out-of-the-box capabilities, and leave lots of space for users to "pollute" it with what they care about. Give people space to make mistakes, raze things and start over. If it's too built-up, it discourages experimentation and customization. * Baiting big to catch small. (https://xkcd.com/1319) The long tail of manual tasks are not really economic to automate just for oneself.* First-world problems. Until we get good sensors/actuators, programming is kiddie-pool stuff for the most part. "I wrote a script that lets me open projects easily so that I can write more scripts." There's more to life. (Not for me, but for most people 😄) Why programmers don't program for themselves (snapshot summary of the previous thread) * Interoperability limitations. Between any putative new script and other devices, platforms, programs. * GUI limitations. * Operational/maintenance burden (Ivan Illich). Keeping up with security advisories, for example (https://mastodon.social/@akkartik/104790515855023278)* Programming for employers sucking up all the oxygen. Building for oneself is economically invisible in the current paradigm. (Thanks @Konrad Hinsen.)* Long-term trend towards locked-down, consumption-oriented devices. Morlocks turning Eloi. * Lack of DIY culture. Programming for others may be poor preparation for listening to one's own needs (e.g. https://mastodon.social/@akkartik/103994830568601931). Perhaps the original sin was framing programming as driven by exernal "requirements"? But computers always had to start out expensive; hard to imagine how we could dodge that bullet..* Fragmentation in incumbent programming models. High barrier to entry for exploring new programming models. * Poor discoverability/unmemorability/anti-memorability. (Bullets are not disjoint, just interlocking/overlapping frames I've been finding useful.)
    Kartik Agaram
    j
    +7
    22 replies
    Copy to Clipboard
  • r

    Robin

    2 years ago
    Broad question here. Do people here know of any tools that separates the complexity component of a program from the underlying behavior it would eventually produce, and then let you manipulate code so the behavior is fixed? By behavior I mean something like the user-facing behavior of a program, or its effect on some data. Its a flexible concept in my mind. A large portion of programming seems to be rewriting code so it maintains the same behavior, but is then also extensible in some way. Factoring code is an example of this activity, but you could also rewrite code to produce the same behavior which is not a factorization of the original code. To be concrete, you could factor in two different ways, so each factorization would produce the same behavior but neither is a factorization of one another. Moving back to the unfactored code and factoring in the other way is then a means of transforming the code to produce the same behavior that isn't mere factoring. (picture: code<--factoring<--code-->factoring-->code) (this is very reminiscent of factoring in abstract algebra and you could imagine an algebra about manipulating the code in this way, and going down this road you can ask whether two programs will produce the same behavior implies there is a common factorization but this might be another conversation). I'm curious about this question mostly as a proxy for a related question in math: How can you transform one proof into an equivalent proof? This is a slippery concept because nobody knows how to make precise the idea of "equivalence of proofs". If you know about Hilbert and his 23 problems you might find it interesting that he originally had a 24th problem on the equivalence of proofs! Even though the idea is notoriously difficult to pin down, I think it is intuitive enough to take a pragmatic stance and ask how you could go about implementing technology to carry out these transformations. This is important to me because in math we "factor" proofs all the time and often compare proofs to determine the essential and incidental aspects of each. So what I'm really looking for is any techniques or perspectives in the domain of programming that could be taken back into mathematics. I've seen some approaches down at the level of the lambda calculus but I haven't found them useful. I think a pragmatic/experimental approach is better than a theoretical approach at this point.
    r
    j
    +4
    9 replies
    Copy to Clipboard
  • shalabh

    shalabh

    2 years ago
    (My comment below generated a bit of interest in another forum so I want to copy it here as a prompt.) What do folks think about the emphasis on "readability" for programming languages?
    Readability in PLs is nice, but ultimately a red herring. It doesn't scale. We may be able to read a small snippet and get it, but once we have more code or more abstractions, we're lost again. The real goal should be to offload all mechanical computation to the machine.
    IOW, readability gives a very small step. It may be easier to build a "structure in your head" after reading a "more readable" representation (vs a less readable representation of the same thing). However the work really starts after you have this structure, when we begin "playing computer" in our heads.
    shalabh
    Kartik Agaram
    +5
    12 replies
    Copy to Clipboard
  • Prathyush

    Prathyush

    2 years ago
    I tried to write a narrative of how studies in universal algebra and category theory is providing a deep understanding of how programming languages are united/distinct in the way they treat computational structures: https://github.com/prathyvsh/morphisms-of-control-constructs I am pretty new to this field and thought the story of this evolution is less told away from academic circles and started piecing together parts of the story as I read twitter feeds / blogposts / papers on it. If anyone here is knowledgeable in this, can you please provide some feedback on what I have missed or what needs polishing? Pretty sure that there could be some significant details I have missed out.
    Prathyush
    Stefan
    +2
    30 replies
    Copy to Clipboard
  • d

    Drewverlee

    2 years ago
    What if it's important, for comprehension, that we be able to speak programming languages not just write them.
    d
    Cole
    +4
    12 replies
    Copy to Clipboard
  • a

    Anthony Bramley

    2 years ago
    Is this a "general" of sorts?
    a
    Mariano Guerra
    +2
    6 replies
    Copy to Clipboard
  • Konrad Hinsen

    Konrad Hinsen

    2 years ago
    Since many of you are interested in visual programming, I wonder what your take is on accessibility issues. Motivated by this message found on today's Emacs News (https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00286.html) which basically says "Emacs is a great application platform for blind users like myself because it has a plain text user interface that can be adapted to voice I/O."
    Konrad Hinsen
    m
    +1
    3 replies
    Copy to Clipboard
  • robenkleene

    robenkleene

    2 years ago
    In the thread I started asking why programmers don't program more for themselves (https://futureofcoding.slack.com/archives/C5T9GPWFL/p1599588394135900 thanks for all the interesting responses everyone! I largely came to the conclusion that they do program for themselves, it just takes the form of personal sites and side projects, rather than the type of thing I was looking for), I got a couple of requests for some examples of what I mean, so I decided to start a thread to share customizations. There are three categories I had in mind when I started that thread: 1. Using programming to support software development with things like continuous integration, and automated testing (these are both actually popular, but in my experience programmers tend not to like working on them very much). 2. Solving problems programming problems programmatically, e.g., writing shell scripts or using text editor marcos (https://www.emacswiki.org/emacs/KeyboardMacros) to perform a refactor that isn't supported by refactoring tools. 3. Writing scripts and customizations to help improve your own personal workflow. I think of those three, only the last one that I think only #3, personal customizations, needs examples to understand, so that's what this thread is about. I'm going to try to share a mix of things that I think would be helpful to any programmer, and things that are very specific to my own workflow. I'd love for anyone else to share their own customizations. I'd also love to hear of people think these types of customizations would be helpful (or not helpful) for the way they work. (Or also just if my presentation of them isn't clear.) Cheers!
    robenkleene
    Srini K
    +5
    33 replies
    Copy to Clipboard
  • Nick Smith

    Nick Smith

    2 years ago
    Who here is working on a logic programming system? I feel if there are a few of us it could be nice to form a little subgroup to share questions and ideas that require a background in logic programming. Perhaps there are not many of us, though.
    Nick Smith
    i
    +8
    18 replies
    Copy to Clipboard