Research goal

I was recently asked to state my research goal, and this is what I came up with. Suggestions for clarification welcome.

Make simple things easy for amateur programmers.

Where simple things = small scale ad hoc internet applications:
< 100 users
< 100Mb data
< 1000 LOC (or equivalent)

Where easy = total documentation of the entire stack < 1000 pages, written to the comprehension level of a non-STEM undergraduate. But while still providing general purpose programming within some domain, like spreadsheets but unlike many no-code systems.

Where amateur = someone who wants to invest the minimum effort in learning technical details to make something work. It is not a goal to appeal to professional programmers nor train them. But perhaps the extreme simplification required for amateur programming will suggest ways to simplify industrial-scale programming too. For example SQL started as an end user tool.

I believe these goals can not be acheived by remixing our standard bag of tricks. If that were possible it would already have been done. We need fundamentally new ideas, or perhaps discarded old ones.

2 Replies to “Research goal”

  1. One language I think meets your goals (and some others) is Frink (, which Alan Eliasen has developed over the past 20 years. It certainly meets your documentation limit, ~all the docs are on the main page, and they’re a pleasure to read. It’s unique in using unlimited-precision rational numbers by default and being “physically-typed” (the physical unit types being any product of mass, time, distance, current, etc., each raised to a rational exponent). It also uses a space (overloaded, of course) to indicate multiplication, which is surprisingly convenient and unproblematic.

    It’s interpreted, has no dependencies, very rarely needs to load a library, runs on the JVM (including on Android and server-side on web pages), and is primarily used for one-line physics and engineering computations, but it also has some very nice programming features as well, including advanced variable constraints and data structures (including arbitrary-dimensional non-rectangular heterogeneous arrays with all the functions needed to slice, dice and shuffle). I use it more than just about anything but browsers and text editors.

    It does lack mouse interaction, (though it has decent graphics, including dimensioned drawings) and would benefit from a spreadsheet-like interface, or maybe dataflow interface or some of the ideas you advocate. Definitely worth learning from, though, if you want to make a language that will be used by amateurs for quick results.

    1. At this point, I think that anything that doesn’t run on the universal computing platform (you know the one—the “World Wide Wruntime”, you could call it) probably has to be eliminated right out of the gate. Anything that requires any non-trivial tool/stack setup and configuration before being able to go from zero to “hello world” is among them. This is true for all the reasons that Jamie Brandon wrote on the Light Table blog under the title “Pain We Forgot”.

      Note that that doesn’t necessarily mean “JS” (and rules out much of what professional JS programmers themselves put out today). I wrote a little bit about this, contrasting the uptake of Java vs JS vs everything else in a retrospective ~20 years out. (I’m linking it here by filling out the “Website” field in this comment widget with the URL in question. By a reasonable guess, that means you’ll need to click my name to get there—I don’t want to risk tripping a spam filter by including an inline link. Citation: “How to Displace JavaScript”, 2019.)

      Excel gives a nice-ish experience—for people with Excel. We can get there and past it by using universally (immediately) accessible formats.

Comments are closed.