←back to thread

1401 points alankay | 1 comments | | HN request time: 0.216s | source

This request originated via recent discussions on HN, and the forming of HARC! at YC Research. I'll be around for most of the day today (though the early evening).
Show context
logicallee ◴[] No.11940067[source]
1. What do you wish someone would ask you so that you could finally share your thoughts, but nobody has broached as a subject?

2. (This question is about interactive coding, as a dialogue).

Human dialogs (conversations) are interactive. I think in the past computers were limited, and computer languages had to be very small (as compared with any human language + culture) so that a programmer could learn what the computer could do. But now that services can be connected (programming as a service?), would it make sense to have a dialogue? My example is that in the 1980s it wouldn't have made sense for any programming language to have a function called double() that just multiplies by 2. There's * 2 for that.

But in 2016, it makes sense for a beginner to write "and double it" and considerably less sense for a beginner to have to learn x *= 2 if they wanted to double a number.

Human language is also ambiguous. It would make sense for an interactive language to ask:

"Did you mean, set x equal to x multiplied by 2?" which most people would select, but maybe someone would select

"Did you mean, set x equal to the string "x" appended to the string "x"?"

For these reasons: do you think it would make sense to have an interactive programming language that is connected with a server you "talk" with interactively?

Or should programmers still have to learn a fixed programming language that has no room for interpretation, but instead a strict meaning.

Among other things, this means programmers can never write "it", "that", "which" to refer to a previous thing (since the referent could be ambiguous if the compiler doesn't confirm.) But every human language includes such shorthand.

I'd love to hear your thoughts regarding a connected, interactive programming process similar to the above (or just on whatever lines).

replies(2): >>11940662 #>>11945188 #
1. mmiller ◴[] No.11945188[source]
What you ask here is very interesting to me, because some time back I got to thinking about what Alan Kay talked about with trying to negotiate meaning, in reference to using Licklider's concept of "communicating with aliens." Kay (IIRC) used a simpler concept of trying to order a burrito from a vendor, where neither the vendor nor the customer understand each other's language. He said by using gestures, you can get the idea across, because you can reference common concepts in each other's heads, and finally come to agreement about ordering a burrito. So, I started on a "sketch" for a language for a fairly simple task (converting between encoding schemes) where the code was suggestive, rather than prescriptive, and it just used a declarative style. One example is I just said, "a5 b6 10..." (including the double-quotes, and the trailing "...") to try to suggest a string containing a sequence of hex numbers of indeterminate length. I was saying, "Expect this type of information." As I did this, and thought about what else the language would need to express, I came to the exact same question you did, "There could be a variety of interpretations of this. Maybe the dev. environment should ask the programmer questions, 'Did you mean...?'" The programmer could respond in some way meaning "Yes" or "No." If no, the dev. environment could ask about other possible meanings it knows about, based on the syntax used. I could see this getting complicated very quickly, because what I hoped for was that the language would give a programmer the freedom to try expressions that made sense to them, in hopes that the language environment with which the programmer communicated would understand them, and that the language environment should try as "hard" as it could to understand them. However, not being skilled in AI, I wondered if the forms of expression I was thinking about were constrained enough in meaning that I could completely code a scheme whereby, looking at syntax "signals" in the code, it could reason through the expressions to make good guesses about their meaning, and then test them by formulating intelligible questions about them to confirm what the programmer was getting at. Going through that exercise told me I had a lot to ponder, learn, and explore with this idea, because I didn't come up with any ready answers that felt satisfactory. The best I could come up with was that I would code the language to allow a few possibilities with the syntax "signals," in combination with other "signals" that I could anticipate, but if the expression went beyond the coded meanings, I'd have to have the language say, "I don't understand what you're talking about. Please try expressing it differently," which would lead to a kind of guessing game between the programmer and the language, with the programmer quickly getting the idea, "There have got to be some rules to this system. Why don't I just look at its programming, and figure out how I use its rules to express what I want," which would defeat what I was going after. The whole thing would be an artifice, rather like an Eliza simulation.