Ooplie is a programming system where you write in English. It runs in Node.js and in the browser.
There's a nice little console where you can try it out so far.
It has a Parts menu where you can see the available commands and expressions.
Each command has multiple synonyms, often many.
Everything is organized into libraries, including things like conditionals.
To access libraries for File System manipulation etc. you need to install the console as a desktop app.
To do so, clone the repository, open a terminal/command prompt in console/ and enter npm install.
Then to run the app, enter npm start.
So far Ooplie is completely imperative, and you can't do much with it. You can output text, evaluate JS, and evaluate Ooplie code (from Ooplie code), write mathematical expressions with worded operators ("2 to the power of 4"), Unicode operators, or ASCII operators, write trivial conditionals which are useless because there are no variables yet, and read and write text files.
At the risk of citing an article where the author calls out a programming system citing the author's work as inspiration as terrible as inspiration, Brett Victor's Learnable Programming expresses some great ideas about the future of programming.
If you're not excited by the prospect of programming in English, then at least check out some of Brett Victor's work or maybe Toward a better programming, and get excited about the future of programming in general.
There's a project called EVE that looks interesting. I'll have to try it out and see what it's like.
Also, check out Apparatus!
I want see what it would be like to program in English.
I don't think this is the be-all and end-all of programming paradigms.
Unless a future of realtime cross-translated collaborative structured document editing is realized, it's probably not going to be better than a more syntactical programming language for international collaboration on software projects.
High expectations of lingual disambiguation and common sense mean it will may never feel smart enough without machine learning and huge amounts of data.
That would make it harder to distribute programs, so a compiler would probably work better.
Although then you miss certain possibilities afforded by a dynamic interpreter / runtime.
But anyways, I think Ooplie might be a good tool for learning and getting into programming, as an alternative to drag-and-drop-based systems, and for automating lots of things that might be too trivial to automate considering you'd have to write a program for it.
It also could be great option for programming if you're blind, as long as it's designed with that in mind.
Also, I think radical ideas like this need to be explored. Because even if Ooplie fails as a whole / as a project, there still might be ideas in there that, if people try programming in this new way, might expand people's minds and end up being applied to other programming languages or systems. It might raise expectations for clarity in code, expressitivity, richness of authoring environments, etc. (expressitivity is related to... well, both of those other things. it's really in the middle. perfect, I planned that.[sarcasm needed])
The first aim will be to get it usable as an imperative interpreter for simple shell scripts.
Scripts will be able to use a shebang comment like #!/usr/bin/env ooplie
or... sh, bash, ksh, zsh, fish, english! It fits the pattern!
Ooplie will need some better natural language processing.
But parsing handwritten English text files is unsustainable.
I think Ooplie programs should be stored in a format that contains concrete and explicit information alongside the plain English. The format can still be text-based, but it should be designed for IDEs (with an additional goal of being nicely diffable as text... and possibly editable as plain text to some degree).
It should understand a superset of what it accepts. In authoring you should be able to use autocomplete and such and express ideas freely and easily, and then it should help you form those ideas into clearer, more concrete representations. For example, you might type "x * 5-4" and it could transform that into "(x * 5) - 4" (following order of operations) or "x * (5 - 4)" following whitespace, as two suggestions.
Ooplie should have a good module system. You should be able to easily write wrappers for modules on npm to give them lingual interfaces. File system support and other things should be implemented this way. How the interop should work is not entirely decided.
After that, more complex control flow and mathematics can be added, and various modules can be developed.
Eventually I want to try hooking speech recognition up to Ooplie and playing around on a canvas with physics, maybe try making a web app with this...
There should be an IDE, because an interpreter is not good enough.
It would feature "Did you mean?" style error handling that can update your actual code (especially for disambiguation).
It should encourage you to write robust, explicit code. It might give you fields to fill out in response to commands:
"Draw a circle."
- Where? / Center point: [0, 0]
- How big? / Radius: [1]
- What color? / Color: [#000000]
It might highlight paths of execution that aren't handled like failure cases and else clauses. Of course it's perfectly valid to do else-nothing, but it could require or strongly encourage you to be explicit about it, because sometimes you really should throw/raise/return an error/exception (depending on the paradigm we go with), and you might just not think of it. It could unhandled paths with questions, like "What if this fails?" or "Else what?", with easy default answers like "just continue [below?]" / "do nothing" (no-op), "this is an error" / "show a failure message" / whatever, and "let me know if this happens" (ideally you could resume execution of the program after deciding what to do when the case pops up, optionally updating the program with some general handling of that scenario)
Errors should be considered UI. Errors are already UI, just generally shitty, shoddy, untested UI. Aside from having good, clear error messages:
- There should be good patterns for propagating error/exception cases up to the user,
with good contextual information in the message
(such as parameters passed to the things that might fail,
or maybe separate messages at each
raise/throwlevel). - Error messages should be able to contain references to objects/values for inspection,
similar to
console.log. That would include strings, so you wouldn't have to either escape strings withJSON.stringify()which makes them hard to read, in order to make it unambiguous, or use quote characters around the string that you think/hope are not going to be used in it (as often).
It could let you dig down into statements and expressions to see the underlying meaning and implementation, through your code, through libraries, and to the underlying JavaScript.
Similar features exist in other IDEs, but I can imagine it working more like a variant of code folding where you fold layers of meaning and abstraction rather than just blocks of code.
Perhaps like this?
(Except you wouldn't have to write that lower layer of code, print the numbers 1 to 10 would just work 😄)
It should also let you write code that isn't understood and subsequently define/explain it, implementing it in detail.
It could automatically search for modules related to phrases it doesn't understand. Maybe not totally automatically as it could be a privacy issue sending code to some server, but maybe at the click of a button when it gives an "I don't understand" type error. That would be good. (And if the search DB was mirrored locally that could eliminate the privacy issue, but it might take up a decent chunk of space, so there could be three options for this, auto (not private), manual (not private), and local db (private).)
It should try to show you what's going on with the program as much as possible.
It could have dynamic underlines on timers like Every N seconds / After N seconds,
and maybe underlines to any line of code being executed.
That would be optional, though, as it could obviously be distracting.
Also I'm not sure how it would work with asynchronous code being run multiple times.
(Execution underlines CSS animation on jsfiddle)
When you have multiple asynchronous code paths, they may be run either in parallel or in series. The IDE could show the flow of execution with lines in the margin, making it clearer what would happen.
For example, here the intent is clear, but will the second action actually run after 10 seconds, or after 15?
After 5 seconds, say "reached 5 seconds mark"
After 10 seconds, say "reached 10 seconds mark"
Here it's disambiguated:
After 5 seconds, say "reached 5 seconds mark"
Then after 5 seconds, say "reached 10 seconds mark"
You could also write:
After 5 seconds, say "reached 5 seconds mark"
After 5 more seconds, say "reached 10 seconds mark"
Dragging the line could change the control flow, updating the code to reflect the changes.
The IDE could support visual mathematical equation/expression editing, and resources like images could be dragged and dropped and used directly in expressions.
It could blur the line between entering commands and writing a program (if that's a good thing).
(Like a notebook? I think I was thinking specifically about being able to extract commands entered into a console out and factor them into a program retroactively... but probably this would work like "notebook IDEs" - Jupyter Notebook for lots of languages including JS, RunKit for JS specifically)
(...but my experience with notebook systems has been that it parts awkward constraints on your program to try and structure it to get any benefit - not having published anything, so I haven't really made use of the markdown/prose blocks, but - it seems like it needs some Light Table magic or something)
Syntax highlighting could work in other apps to some degree, but the Ooplie file format would likely include lots of markup needed to identify/lock-down semantics. You would probably want your editor to hide the markup, unless it's somehow kept terse like markdown. But I don't know how much use that would be, if there's a tightly integrated development environment that you're meant to use. (If the format is designed to encode semantics, is that directly editable too? Otherwise, how would you produce that? Maybe you go thru cycles of editing and having the tool update your code, with did-you-mean style modifications from the command-line?)
However, the entire IDE could be made reusable as a component, and could be included as a plugin in web-based code editors like Atom and Code.
Fork the repository on GitHub, and
with Node.js installed run npm install in the project directory.
Run npm run dev (and leave this running) to watch the source files and recompile when changes are made.
(In the future this could also run the tests after each recompile.)
Run npm test to run the tests.
You can also open test.html (maybe with a live-server) to test Ooplie in a browser,
but note that only a subset of the tests are run.
The File System module isn't tested in the browser, for instance.
(In the future it could use a mock FS.)
To run a specific test or tests, do e.g.
npm test -- --grep "multiple statements"
If you've been running tests in a browser,
be sure to run the full suite of tests with npm test at least once before committing.
Run npm run prepublish to make sure ooplie.js is compiled.
It's included in the repository for GitHub Pages usage.
(In the future this should be an automated step of the release process,
not a manual step before every commit.)
The Ooplie console app lives in console/
and has a separate package.json.
It runs as a desktop app with NW.js.
(Could use either electron or NW.js since it's not doing anything fancy.)
CoffeeScript is included in 2 different ways:
lib/coffeescript.jsis the CoffeeScript browser compiler, used intest.html.coffeescriptis a dev dependency, used for building and for testing withnpm test.
Mocha and Chai are similarly included in 2 different ways:
- via a CDN in
test.html - as dev dependencies for
npm test