Comment by maryrosecook | Hacker News Reader

Comment by maryrosecook | Hacker News Reader

Hi everyone. I'm Mary and I am making Isla. It's exciting to see the language posted to HN, and great to see so much discussion.

I agree with the people who say that a programming language that apes natural language can be frustrating. Inevitably, it cannot support even a fraction of the constructions that a human brain can parse. What made me try a natural language approach is the following (contentious) ideas:

* Children find it hard to type punctuation. Natural language can be parsed without punctuation.

* Someone new to programming probably knows nothing of conditionals, loops, logical operators and functions. So, a language that codifies these concepts as jargon in the form of keywords is going to be alien.

* If you ruthlessly constrain the features of a natural language-like programming language, it's possible that you can keep the advantage of human readability and dodge the disadvantage of the "uncanny valley", as `antihero` succinctly put it. In Isla, the only expressions are instantiations, assignments (with support for objects), `if this then that` style rules (maybe), and invocation of built in functions.

* The joy of programming is in building something. To get children interested in programming, the language they use needs an application. Children love telling stories, so why not make the application a story-telling environment? This gels nicely with the sparse feature set of the language: writing a story is mostly a matter of data definition.

This is the first programming language I have ever made. All these ideas are theories. Isla is just my first shot in the dark.

I thought the example was intriguing, but it would be nice to have some minimal installation instructions for someone with no Clojure experience. Often the initial investment in getting something to function the first time is the biggest obstacle to using it. I'd like to play around with this language with my son (age 11), but I've got a ton of other things on my plate and he's got a ton of distractions (Roblox, WoW, etc.), so having to go off and look up a Clojure reference moves this pretty far down the queue for me, unfortunately. But, it's bookmarked for revisiting later.

I stuck an executable jar on my server just for you: http://classifyr.com/~zak/isla.jar - run this with

    java -jar isla.jar

then follow the instructions starting from the part about connecting with a web browser. On some operating systems and configurations, you can just double-click it and open your browser.

Thanks a lot. I've added a hastily compiled quick start readme to the repo: https://github.com/maryrosecook/isla/blob/master/README.md

It's not as complete as I would like, but I am working on it.

Is that enough to get you started? I'm happy to help out if you email me at maryrosecook@maryrosecook.com or tweet @maryrosecook

Do you think that a professional programming language based off a spoken language would be feasible if it were based off of something like lojban? It would be pretty neat if the distinction between code and language could be blurred.

While it's relatively easy to define a grammar for a severely restricted subset of a natural language that's both unambiguous and, given appropriate "vocabulary", sufficient to describe a wide variety of programming tasks — AppleScript is a readily available example — that's only a small part of the problem.

For instance, you also need to allow users to define "vocabulary words", including some way to import it from one or more external libraries that haven't necessarily been designed either well, or together. To remain unambiguous without sacrificing capability or becoming unnecessarily verbose, you then end up needing the same sorts of features for scoping, renaming, and qualified names you'd have in a more traditional language, versioning problems if you allow anything beyond fully qualified and explicitly imported vocabulary terms. AppleScript does little to prevent terminology conflicts — if anything, certain aspects of its design seem to encourage them — leading to unexpected behavior and hard-to-find bugs.

Also, you may as well introduce "unnatural" syntax like parentheses for regrouping arithmetic and conditional expressions, as all the ostensibly "natural" alternatives I can think of (requiring a series of assignments to often arbitrarily chosen variables to force subexpression evaluation, say) seem worse.

Furthermore, the simplest side effecting subexpressions can easily lead to hopelessly "unnatural" situations: suppose I have two objects "Alice" and "Bob", each with an integer property "age", defined as follows:

    Bob's age is twice Alice's age.

and

    Alice's age is 35 minus the number of previous calls to Alice's age.

Then, assuming we have not previously asked for Alice's age,

    the sum of Alice's age and Bob's age

is either

    (2 * 35) + 34

or

    35 + (2 * 34).

Given that integer addition is naturally commutative, unambiguous "natural language" seems to require some way to express explicit sequencing, whether sequential assignment to temporaries, or by some special syntactic device along the lines of

    the sum of first getting Alice's age, then getting Bob's age.

This is also necessary when any other observable side effects differ: perhaps Bob is always 70 and Alice is always 35, but that each "age" is recorded at the end of a shared log file immediately before it's returned.

And so on. Seems to me that starting with a less ad hoc natural language would, at best, only help with the easiest parts.

from your third point above I immediately wanted to be able to write 'maybe' clauses, like 'if door is red then maybe door opens' :)

Reply on news.ycombinator.com