Navigation Menu

Skip to content

Instantly share code, notes, and snippets.

@stevekrouse
Created July 2, 2018 19:25
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save stevekrouse/626422d9c0e99629afda2a227374911c to your computer and use it in GitHub Desktop.
Save stevekrouse/626422d9c0e99629afda2a227374911c to your computer and use it in GitHub Desktop.

Casually Editable Software

  • Title ideas
  • Outline
    • What is casual editing?
    • Why it's important
      • view source is where many kids learn to code
        • there's a keyframers video where he says this
      • it's so compelling, particularly when you can make changes
      • a world of infinitely customizable, always improving, open-source software
        • open source software would become better than closed source
      • democratizing software creation is meta because it democratizes/blurs the line for all
        • YouTube, Twitter, and Blogging
    • Getting from here to there
      • Casually comprehensibility
        • http://futureofcoding.org/essays/casual
        • Aside: this is distinct from "learnable programming"
          • Paul Chiusano's argument that learnability is a 1-time cost
          • Analogy: learning decimal vs roman numerals
            • Maybe need a better analogy
          • Learnability is important, but we optimize for comprehensibilty in complex applications, because that's what people use
        • We need to rule out parts we don't have to read
        • We need to show the data
          • Live
          • Makes it concrete
        • We need visual http://futureofcoding.org/essays/visual
          • Why are visuals important
            • Metaphors/analogies
              • The best thinkers think visually in their heads
            • Tufte
            • Glench legible mathematics
          • we can only do visuals with a simplified model
            • without simplified, we're stuck with
              • python tutor
            • which is why origami is so great
              • but we need to restrict more to make it scale
                • pulses
            • Rxmarbles
      • Casual editability
        • Live
          • Hose, not arrows (todo quote)
        • No dev env setup
      • Liberal software run-times
        • https://youtu.be/i3nJR7PNgI4?t=30m11s
        • "The hard part was getting the source code. We don't live in that world anymore. When you're using a computer, the computer you're using is nowhere near you. The computer is elsewhere. Google Docs, Twitter, Facebook. Anything you're doing with a computer, 99% of the processes are happening somewhere else where you can't download software stuff, and you can't build stuff. What you want to be able to do is.. deploy your code on somebody else's computer, which is the one that you're using. Cause that's that hard part. Replicating Google's 1.2M servers in your basement. That's a bigger impediment than reverse engineering the code."
          • We already have AWS so it's not the servers exactly
        • "GitHub does not work that way. I think it ought to work that way. So how do I make it work that way? There are two theorems. The first says if you have access to the source code, which you don't because it's not open source but that's neither here nor there, what you could do is reproduce all of Github's infrastructure in your basement and tell all your friends to get an account on your Github copy, which has this modification. Or you can convince GitHub that they ought to allow you to push in changes the way Github works for you."
          • It's more access to the resources and that's key
      • A non-linear version control system
    • Next Steps
      • Reflex visualizations, todomvc, maybe cyclejs devtools
      • Eventually, a tool for editing the visual streams.
      • And a way to edit the apps you’re using, as use use them
        • This will be a challenge on mobile but I don’t see why not
          • Universe / Hopscotch
      • You can follow the progress on futureofcoding.org/log
      • I’m always looking for collaborators
  • open questions
    • casually editable backend
      • where in the essay should I contextualize just to front-end?
        • maybe in the r0ml liberal section
        • maybe in the getting from here to there, casually editable section
      • liberality on the backend is complex
        • I wonder if the new social web, federation work would help with that
      • so much of the backend is incidental complexity
        • increasing the performance of things
      • the essential complexity of backend is
        • authentication
          • this seems mostly abstracted away with OAuth, etc
        • storage
          • you could bring your own cloud (dropbox) or local store with you
          • permissioning
    • vision articulating
      • where does this stuff go?
      • diSessa on medium
      • maybe: app boundaries
      • STEPS project
        • Many of the same goals
        • I want more web/internet than OS
        • I want more restrictive
      • CP4E
        • https://www.python.org/doc/essays/cp4e/
        • What will happen if users can program their own computer?" We're looking forward to a future where every computer user will be able to "open the hood" of their computer and make improvements to the applications inside. We believe that this will eventually change the nature of software and software development tools fundamentally.
        • We compare mass ability to read and write software with mass literacy, and predict equally pervasive changes to society. Hardware is now sufficiently fast and cheap to make mass computer education possible: the next big change will happen when most computer users have the knowledge and power to create and modify software.
        • The open source movement claims that peer review of software by thousands can greatly improve the quality of software. The success of Linux shows the value of this claim. We believe that the next step, having millions (or billions) of programmers, will cause a change of a different quality--the abundant availability of personalized software.
        • The tools needed for this new way to look at programming will be different from the tools currently available to professional programmers. We intend to greatly improve both the training material and the development tools available. For example, non-professional programmers should not have to fear that a small mistake might destroy their work or render their computer unusable. They also need better tools to help them understand the structure of a program, whether explicit or implied in the source code.
        • this will cause a massive surge in productivity and creativity, with a far-ranging impact that can barely be anticipated or imagined.
        • On a shorter term, the quantity and quality of available computer software will improve drastically, as the imagination and labor of millions is applied to the problem. Inventive users will be able to improve the software that supports them in their tasks, and share their improvements with their colleagues or--via the Internet--with others far away who are faced with the same tasks and problems. The ability to modify or customize software is important in crisis situations, when experts cannot be appealed to for help. It is also important for day-to-day activities: The number of unfilled programming jobs is currently estimated by some at 200,000 to 400,000.
        • In the dark ages, only those with power or great wealth (and selected experts) possessed reading and writing skills or the ability to acquire them. It can be argued that literacy of the general population (while still not 100%), together with the invention of printing technology, has been one of the most emancipatory forces of modern history.
        • Of course, most children won't grow up to be skilled application developers, just as most people don't become professional authors--but reading and writing skills are useful for everyone, and so (in our vision) will be general programming skills
        • For example, you might want to write a program to customize your PDA or toaster, but you might be discouraged if a small mistake could wipe out your address book or set your house on fire. Safeguards against disasters are needed, as well as ways of backing out of unwanted changes to a system as a whole. ("Undo", while very powerful, usually only applies to one file at a time. Backing out of unwanted global system changes typically requires a reboot or even painful data restoration from back-up media.)
          • Hazelnut and edit semantics are key
        • another concern for beginning programmers who are interested in customizing their computer is the daunting task of trying to understand a large piece of existing software. We need to look into user-friendly tools for program analysis; more about this later.
          • Program slicing and program paths
            • Turns out there’s a whole field about static analysis of what hits what.... relevant to /essays/casual
          • One of the key goals of empowering non-programmers to modify and customize software in the context of application frameworks or embedded devices is to reduce the cognitive load required to understand how the modification fits into the larger program. This is true even for experienced programmers new to an application's code base. Applications must be modular and provide sufficient high level abstractions so that their constituent parts can be understood quickly and independently. This lets people concentrate primarily on the parts that need to be changed.
        • Another intellectual challenge is visualization of (application-generated) data in ways that help novices. Spreadsheets are of great value here, but not all data fits the matrix form.
        • Rather than writing new programs from scratch, most people will add new code to existing programs. There are three significant challenges that must be addressed by programming tools aimed at this audience.
        • First, the environment must significantly ease the burden of writing, installing, and debugging new programs. The current generation of development tools can be cumbersome for expert users, let alone novices
        • We will develop tools to help users understand the structure of large programs so that they can identify where to make changes and what impact those changes will have.
        • Our tools will also help users manage and configure software, so that individual components can be replaced or upgraded over time. These tools will help users share new and modified programs by automatically tracking versions and dependencies.
          • If users are empowered to modify and customize code, they will be challenged to maintain those changes when the underlying software is upgraded or when system components are replaced.
          • hen a user makes a change to an application, what assurances are there that a future update to the application by the vendor will be compatible with these changes? How does the user himself keep track of just what changes they've made to an application? What happens when a future version of the product adds a feature, previously missing, that the user has added (in a different form)?
          • Our tools will help users keep track of changes they've made, through successive revisions, and help users merge their changes back when the primary application itself has been modified or updated by the vendor. A key to this approach is identifying each version of software and a simple language for describing its properties and dependencies. For example, we intend to improve version control systems so that they track changes at different abstraction levels and granularities than current systems, e.g. labeling changes based on the features they implement instead of the source files (or parts of files) they modify. The tool will automatically identify dependencies on other libraries and component. We will investigate ways to integrate testing frameworks into the configuration management systems so that when the primary application is upgraded, each feature change a user has installed, will be merged and tested.
    • why has this failed in the past and why it's possible now
      • where does this go?
      • OOP
        • opaqueness is actually bad?
      • Aspect oriented programming
        • What is this?
    • Paul Chiusano hash based deps
  • People to send to for review
    • Paul Chuisano
    • Jonathan Edwards
    • Glen Chiacherri
    • David K Piano
    • James Somers
      • Stream visualizations
    • Christopher Anand
    • Jonathan Leung
    • Brent Yorgey
    • Aidan Cunniffe
    • Scott Mueller
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment