Hacker News Reader

I think Perl is interesting here.

When we're talking about computer code, we humans say things like "Read in a line of text. If it ends in a newline, remove it." But we can't program computers that way. The compiler says, in effect, "Read in a line of text from where? And put it where? If it ends in a newline? If what ends in a newline?" And so on.

But Perl actually lets you program that way. Perl says, "Read in a line of text? You didn't say from where, so I'll assume the default place, which is the files that were named as arguments in the program invocation. You didn't say where to put it, so I'll put it in the default variable. If it ends in a newline? You didn't say if what ends in a newline, so I'll assume that you're talking about the default variable, which happens to contain the line we just read in." And so on.

Effectively, you can use "it" in your conversation with Perl, and it will do reasonable things. This is one of the places that it shows that Perl was designed by a linguist.

Yep, default variables and context are important to Perl. I like a lot of the design, but there is a lot of cruft that has piled up in 30 years. Perl6 addresses that while adding support for FP, OO, array programming, grammar based programming...etc. I find it quite pleasant to read and write. The problem is the implementation is immature and I'm not sure it will ever be as fast as we need for a production language.

The topic variable came from awk; most of the whipitupitude variables are direct ports of awks.

I completely forgot about that, good point!

By the way, an important problem in natural language processing, which is related to this at a high level, is anaphora resolution. When we use pronouns to refer to people and things we've mentioned before, there are often ambiguities about what the referent of a particular pronoun is, but native speakers almost never have to consciously think about this question. But in practice, resolving these references correctly may require sophisticated reasoning about our knowledge of the world in order to determine which interpretation is plausible.

An example adapted from the Winograd Schema Challenge is:

The file couldn't fit on the hard drive because it was too big.

The file couldn't fit on the hard drive because it was too small.

In the first sentence, "it" refers to the file; in the second sentence, "it" refers to the hard drive. Native speakers who know what files and hard drives or (or even who don't) should have no trouble understanding the references and might not even have noticed that there was any ambiguity (!), even though resolving the ambiguity requires bringing to bear specific knowledge about the world.

There is a whole family of AI language understanding problems based around this, such as

https://en.wikipedia.org/wiki/Winograd_Schema_Challenge

Looking over some examples shows just how challenging this can be, because of the way the sentences can require people to know arbitrary things about the world. ("The atom emitted a photon because it was entering a lower energy state.")

> even though resolving the ambiguity requires bringing to bear specific knowledge about the world

Actually, in this example knowledge of the world (I'm interpreting this as referring to knowing the details of how "files" and "hard drives" relate to each other) is not necessary. The ambiguity disappears as soon as you know the meaning of "fit" -- fitting requires a large thing to contain a small thing. Therefore if something is too large, it must be the contained object, and if something is too small, it must be the container, and those roles are marked directly within the syntax of the sentence.

You can easily see this experimentally by asking people about sentences with nonsense words:

1. The glirp couldn't fit on the vell because it was too small.

2. The glirp couldn't fit on the vell because it was too big.

Then again, I see you've already noted that speakers who don't know what files or hard drives are should have no trouble with these sentences. Is the lexical meaning of "fit" "knowledge about the world" to you?

That's a good point, and this might be an example of the selectional restrictions issue

https://en.wikipedia.org/wiki/Winograd_Schema_Challenge#Pitf...

or a similar kind of inference that could be considered easier than expected.

I'm not sure exactly what I would consider "knowledge about the world" in this setting. :-)

When you say "glirp couldn't fit on the vell", do you mean to say that the glirp was placed onto the veil, or that the glirp placed the vell on the glirp itself?

The melon could not fit on the hat because it was too small.

The melon could not fit on the hat because it was too big.

https://www.google.com/search?q=watermelon+hat

The first. If the glirp was trying to wear the vell, I'd say "the glirp couldn't put on the vell" or something else idiomatic, like "the glirp couldn't get the vell on". I cannot use "fit on" in the sense you're going for.

You can investigate this yourself at http://corpus.byu.edu/coca/ ; the first hundred results for "fit on" contain, by my eyeball estimate, more than 90 of the sense I describe, zero of the sense you insinuate, and a few spurious hits (such as "to spend as it sees fit on government services", "kept himself fit on a rowing machine", and my favorite, "I've worked with schools such as the Pratt Institute and FIT on developing eco-friendly vegan design programs").

There are six results, out of over 500 million words, for "fit it on", of which one matches your pattern. ("She passes it under the running tap and hikes her tank up to fit it [a strip of nylon] on around her rib cage")

> 1. The glirp couldn't fit on the vell because it was too small.

Situation 1: vell=table, glirp=dish. "It" refers to the vell.

Situation 2: vell=bolt, glirp=nut. "It" refers to the glirp.

Replace "on" with "in", and maybe there's less ambiguity.

The investigation here goes in the opposite direction. It's not "wouldn't it be nice if computers understood natural language" but rather "wouldn't it be nice if people understood programming languages". The former is just silly. The latter is a call to create, in programming languages, constructs that can be parsed by the language machinery in our brains.

If the goal of programming languages was to instruct the computer, after all, we'd be all writing machine code.

Humble submission to the cause - using "the" and "it" in a scripting language to avoid having to come up with variable names all the time.

Way back, I'd designed a scheme-based scripting language called "muSE" [1] in which we created specifications for video editing styles. I also toyed with the language. One such experiment was having a way to refer to values already computed using "the" and "it". [2]

[1] https://github.com/srikumarks/muSE [2] https://github.com/srikumarks/muSE/wiki/TheAndIt

edit: This project isn't maintained, but the latest version 711 still works on macosx [3]

[3] https://code.google.com/archive/p/muvee-symbolic-expressions...

There are already constructs like this. In all programming languages, you see variable names like data or result all over the place. Additionally, when using the python interpreter, there is a special variable _ for the last expression evaluated.

Either Kotlin or eXtend already have "it" for the default variable name of single-parameter lambdas.

"it" is common in that sense, but muse additionally models "the" as a function that turns verbs into nouns - like we do. For example,

    (open-file "blah" 'for-writing)
    (write (the open-file) "hello world")
    (close it)

Or

    (length (list "milk" "pudding"))
    (print "number of items is " (the length))

Perl has this, in $_, the default/implicit argument.

This has already been done. It's known as Non-Aristotelian General Semantics. It's even possible to teach yourself how to speak this way. Intelligence agencies sometimes train operatives in it, because then the reports they make are more useful for intelligence analysis. http://esgs.free.fr/uk/art/sands.htm

The self-help pseudoscience? https://en.wikipedia.org/wiki/General_semantics

Another related EWD is 667[1]

The paragraph that stuck out to me was: "Instead of regarding the obligation to use formal symbols as a burden, we should regard the convenience of using them as a privilege: thanks to them, school children can learn to do what in earlier days only genius could achieve."

[1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...

Specificity is always on a scale. In most cases, you don't want to tell the computer exactly how to lay out the memory (common in imperative programming). In other cases, you don't want to tell the computer exactly what sequence to perform the operations in (common in functional programming). In other cases, you allow for contradictory information to be provided to the computer (common in constraint based programming).

There's plenty of room for ambiguity or contradiction in programming, and good things happen on either end of the spectrum.

Love this, and agree. Though I would love to see a computer system which can resolve ambiguity in natural languages and formalize it for us. It would get it wrong often, but if it is good at it, no more so then a programmer gets the requirements wrong.

We may not be able to do this automatically, but you can use a kind of refinement calculus to accomplish this.

Start off with vague requirements from your client:

  We need a machine which can wash clothes at various
  temperatures and speeds. The user should have options
  to control the temperature and speed since they'll have
  different types of materials. Maybe we can give them
  some preset options?

Conversation:

  What are the temperature options?
  Hot, warm and cold; but it's in two cycles and each can
  have a different temperature.
  How long should it wash the clothes for?
  That depends on the material and how dirty it is.
  What if it's really dirty?
  They should be able to do an extra rinse cycle.
  How fast should it spin?
  That depends on the material and how dirty it is.

Refined (control panel only):

  Dial presenting options for:
    Sanitary
    Normal
    Sensitive
    Bulky
  Buttons allowing further refinement:
    Water: Hot/Cold, Warm/Warm, Warm/Cold, Cold/Cold
    Extra Rinse: (yes or no)
    "Dirtiness": light, normal, heavy (impacts wash duration)

If you use a proper requirements management tool, you can trace every one of those final system requirements back to some (slightly editorialized) conversation or initial (ambiguous, plain language) requirement description. Of course, this will, in reality, be an iterative process as you discover ambiguities in the specification and code and go back to the client for feedback and clarification.

You could potentially have a compiler that would infer meaning & only fail compilation if the fuzzy natural language terms were ambiguous in context — just like languages like Scala currently infer types when unambiguous.

Also, feels like Inform7 should be mentioned in any discussion on NLP and programming: http://inform7.com

First thing to mind based on the article's premise and hits a lot of the article's desired points already.

Interesting. This feels like a great way to prototype functional requirements. Express the full process as an interactive fiction novel, and let people play it. Get feedback, iterate on the novel, until they are satisfied, then implement.

One thing that would be interesting is if you could write a compiler front end that was interactive so that it could give you better error messages.