Hacker News Reader

How many people can describe an algorithm properly in English? Probably the same set of people that can program a computer.

It would take a lot less training however, if 'programming in English' was widely available.

English is such an ambiguous language, I would think that training would be a lot harder (especially for native speakers to unlearn the imprecise parts of English).

English is so ambiguous and so large that it would probably be best to reduce it to a strict, unambiguous vocabulary.

It might take a few tries to get that right.

We might see, say, "Unambiguas English version A", as an experimental or academic version.

Then a trial "English B".

And maybe on the third try, they'd get it right, say, "English C". We could call it "C" for short.

(I know, I skipped BCPL.)

Probably not. Currently, the part of training/learning time spent in educating developers that refers to the language syntax is at most 5% of the whole; perhaps 10% for the most junior developers; so 'programming in English' saves you just a tiny part of the training.

However, as a specialized language can quite plausibly make you 10% or 100% more productive, no one serious would use general english even if it was a possibility. You might imagine a somewhat efficient programming in a very "jargony" english (similar to "legalese") with very specific (and likely unintuitive) meanings of a large number of particular phrases, but then there's no meaningful advantage of it, it's just as far from everyday english as any other programming language, and requires just as much training.

Yeah, you can see this in comparing how long it takes a person to learn a new programming language versus someone learning their first programming language. Learning a new language is trivial, learning to program not so much.

I'd guess it would be more of a question-and-answer session between the computer and the designer rather than attempting to describe the algorithm up front.

Very little programming needs any algorithms though. Most of it is literally deciding what data to record, what validation rules to apply, and how to aggregate the collected data in to something useful. It's why MS Office is so prevalent - most business software is written in Excel with all the "code" abstracted in to forms and macros.

More likely an even smaller set.

Todays dynamically typed languages are already too ambiguous for most people to write correct software without tests, how should this get any better with using English? :D

Yeah, I think this is the key. English is simply not specific enough to work as code. To the extent that "English" some day becomes a programming language, it will be a special dialect that looks an awful lot like something along the lines of SQL.

Yeah, because current paradigm in programming is about specification. When dominant paradigm becomes focused on probability, then English could become programming language.

Your money was transferred to your account with 60% probability and donated to the Trump Foundation with 40% probability. Press escape or e to abort with 10% probability.

So uhm... More seriously, what do you mean?

The tests are not because the languages are 'ambiguous'.

sure it is, you can have syntactically correct programs that do the wrong thing because of name lookup.

That name lookup is ambiguous.

What's an example of such a program?

I'm not going to play that game, if you can't think of an example of a dynamic language that's syntactically correct but fails at runtime due to name lookup issues, that's on you, but it doesn't change the validity of the point.

Very well.

I think he should have said that we don't need tests 'only' because of ambiguity. Even with no ambiguity at all, would still be needed.

You're in an empty room with a light switch. GLaDOS says 'please turn on the light'. You flip the switch and the floor disappears, dropping you into a pool full of hungry gators. That doesn't make 'turn on the light' ambiguous.

Thankfully, that's not how programs work, so your analogy doesn't really apply.

No, dynamic languages are not "ambiguous" in any possible way. Programming languages are unambiguous by definition, as any formal languages.

What they are, indeed, is dynamic. The lookups you are talking about are done in runtime, so the result of these lookups can vary depending on the state in memory at a given time.

That doesn't mean they're ambiguous. Everything is perfectly unambiguous and deterministic. They're just dynamic. And that's fine.

FYI: People also write tests in static languages.

Sorry, I'm not a native speaker.

What I meant were things like automatic type conversions or used of undefined object properties, which aren't ambiguous, but certainly seem ambiguous and lead to many errors.

    User: 'Make me a sandwich'

    *mighty robot slices up user and places in between two pieces of bread*

    Computer: 'You are now a sandwich'

See, that's the issue, incorrectly specced software.

Exactly, so what we need to do is use a formalized language with strict rules to keep out any ambiguity. And then we fully specify what software we want and... this process is called 'programming'.

And then we can automate this 'programming' and people can ask the automation software to 'make them a sandwich'

But what if the programmer program could identify possible ambiguities and interactively ask you to clarify them? That would obviate the need for a formal language specification.

>Make me a sandwich.

Do you want to (1) be turned into a sandwich or (2) have a sandwich prepared?

>2

What ingredients do you want in the sandwich?

(etc.)

This is an agile development process.

Although in principle it should be possible to have a machine that performs each iteration near-instantaneously, rather than wait three hours between each change.

I'm working in this space (check my profile) and I'm betting pretty heavily on the idea that the problem there is not the user's conception of their idea, but the flawed nature of language. If users can interact with their concept as they build it, and shape it like you would a physical product, they can get much closer to the ideal stored in their head than if they have to describe the idea in minute detail using ambiguous concepts.

This is why you shouldn't run commands as root.

I assume you're thinking of this :-)

https://xkcd.com/149/

True, but in this case the user owned the file^ that was being worked on

^ everything is a file...

That is an error, which will be backpropagated and forever corrected. We have to assess whether 1 human life per ambiguity is an appropriate price to pay

This always makes me think of scene from Star Trek next generation when Geordie is on the holodeck trying to create a table. It takes 4 attempts for star fleets top engineer to get what he wants. I've often pondered this deeply illustrative example.

Everyday language is made of leaky abstractions.

Ruby is a good example of this direction; it's intended to (mostly / sometimes) read like actual english (RSpec is an even better example), but in the context of the language, Ruby's abstractions are precise, rather than the vague abstractions of human language.

Additionally, there's a difference between "able to speak the language the computer can understand" and "able to program something"; that difference is "detail of thought".

I tried to demonstrate this to a friend with a pretty good "Uber but for X" idea. I said - Okay, you want to rate people. Who rates whom? When? On what scale? What do you want each rating to mean? What do you use the ratings for?

Following this train of thought - it's not JUST that we (as in the entire software engineering community) are adding levels of automation, it's that each higher level language adds "default" answers to those questions, so that at some point, you could just say: "Give me a rating system", and you'll get the usually-best one that you can refine; like the core CSS classes. We're rebuilding language from scratch, layer by layer, in order to have non-leaky abstractions.

Or maybe we'll see something like the neural nets that can draw based off a phrase - you say "give me a rating system between users and drivers", and the NN generates something that satisfies, and then you refine from there - "give me a rating system... from 1-10, where normal service is a 7".

We already have this--contracts are "programs" that specify how other people should perform some action.

Nevertheless, entire industries revolve around correctly writing contracts, making sure they are executed in the intended way, and resolving ambiguities and disputes about the original specification.

If it's ever possible to go directly from English to running code, programmers will still be around; they'll just sound more like lawyers.

Agreed.

You're always going to have people that manage the details and edge cases of complex software systems. Those people will be programmers.

And if there is ever an AI invented that can replace those people then many white collar workers are at risk of losing their jobs, not just programmers.

And yet there's a lot of effort in automating lawyers, so maybe the future will be setting more higher level .

Higher order lawyers - where you can do with one HOL in a day what took a month with regular lawyers (just like Python vs Assembler).

Contracts are not "programs", any more than programs are binding legal agreements between users.

Lawyers are only paid to create clear specifications some of the time, and that mostly in criminal law and political legislation.

In non-trivial corporate contract law they're paid to find favourable ambiguities in existing specifications, and to build possible ambiguities and hidden implications into negotiated agreements.

They're also paid for their ability to use rhetorical, verbal, and theatrical tricks to persuade counterparties, judges, and juries of their point of view.

Outside of STEM, the relative predictability of code is a very poor and superficial model for the relationships, transactions, and goals that define most domains.

You're making my point for me.

Natural language is rife with ambiguities, contextual information, and implicit assumptions. It is a terrible method for precisely conveying instructions or expectations, even to equally intelligent peers. Making this work at all requires a whole specialised profession with its own elaborate procedures and complicated argot.

If you wandered into an IBM office and said, "I need a document storage system. Here's a blank check; make it happen!", do you think you would be happy with the outcome? Probably not. What changes when you tell this to a chatbot instead of a guy in a suit? Instead, you'd work with someone lawyer/programmer who knows how to spec out the solution in enough detail that the vendor/optimizer can't go "well, you said STORE the documents, but you never said anything about RETRIEVING them later!"

> Contracts are not "programs", any more than programs are binding legal agreements between users.

The conversation at hand is not about "programs" in the traditional sense, but more a conversation between a human and an AI which is providing what is asked for.

This is very similar to asking a Genie to satisfy your wishes. You need to be clear and precise or it is likely you'll get exactly what you asked for, but not what you intended.

We're NOT talking about traditional programming here.

> Lawyers are only paid to create clear specifications some of the time, and that mostly in criminal law and political legislation.

Sure, but it appears that a Lawyer's domain involves the interaction between intent, specifications and reality. In all the points you raise, this is what the lawyer is doing.

> In non-trivial corporate contract law they're paid to find favorable ambiguities in existing specifications, and to build possible ambiguities and hidden implications into negotiated agreements.

This is exactly what a programmer is doing almost all the time (when not talking to clients). Finding the edge cases, creating rules. Avoiding or documenting them. Closing the loopholes, turning them into features or guiding the user away from them.

> They're also paid for their ability to use rhetorical, verbal, and theatrical tricks to persuade counterparties, judges, and juries of their point of view.

Okay, so lawyers are sales-people too. Do you really think that programmers are not already salespeople, or have people on their team that are?

> Outside of STEM, the relative predictability of code is a very poor and superficial model for the relationships, transactions, and goals that define most domains.

Bear in mind that a programmer RIGHT NOW is managing the issues that you are discussing, as the computer is only half their domain. The other half is interactions with teammates, clients, etc. They already have to manage "human relationships, transactions and goals."

But everyone can use language to clarify things, not just lawyers. A proper AI system would fill in the missing info with the optimal defaults, and ask for clarification for the rest. Every new edge case added makes the system smarter

This is exactly what a skilled developer does. In principle you could probably design a system that does it automatically. Sounds like strong AI territory though.

Of course! I'm not saying that only people with 180s on the LSAT will be able to program.

Instead, I'm arguing that writing an air-tight specification of your goals can be tricky, time-consuming and requires a certain mind-set, even if we assume perfect natural language understanding and ignore all the implementation details by saying that wizards...err...deep neural networks solve those issues. As support for this argument, writing contracts is still tricky, despite everyone involved having perfect language understanding and the sort of generalized intelligence that computers lack.

Therefore, if there ever is an English-to-bytecode compiler, I expect that the "programs" written for it will look much more like a contract with lots of awkward but precise language and much less like "Yo Siri, build me a chatbot." You can call the person who spends all day drafting these things and interacting with the code-generating software something other than a programmer if you want, but if the shoe fits....

I'm also not convinced that optimal defaults exist for many things. You could certainly recommend a data structure based on the way it is accessed (if it's always being queried for the min, throw it in a heap, but use an array or hash table for random access), but how do you gradient-descent your way to a fun original video game without also assuming a decent model of human psychology? At some point, you have to specify that "when the player does X, Y happens", which is programming.

Programming languages have gradually evolved into higher levels of abstraction, but they haven't consistently become more humanlike.

You can't fully understand human language with anything short of Strong AI. And yes, we made some progress in our ability to extract specialized meaning from natural language with high level of accuracy for things like translation or indexing - but we didn't get any closer to having computers understand and reason about the meaning of the text.

In short, to say that we're rapidly getting to the point where computers can replace programmers in understanding natural language requirements and designing programs that achieve these requirements, you need to show consistent progress in general-purpose AI.

The elephant in the room is that programming in English would be a huge step backwards. Modern programming languages are all about scalable, modular abstractions.

Natural language typically doesn't supply many sound abstractions. Everything you say is open to interpretation, as the many misunderstandings in this very thread clearly demonstrate...

You no longer have to deal with solution domain issues (memory leaks, crashes, deadlocks, type errors ...).

However, you might still need a huge bunch of english text to describe the problem domain. If such a text isn't already available, you need to write it yourself (coding).

However, you might not write it in one shot, so you need to store it in text files that you can read and modify later. Maybe you would team with other people to write it, and you would share and track your modifications (versioning). Maybe, to make it easier to manage, you would split your description in multiple text files (modularizing).

And then, you'd need a way to ensure that your text actually unambiguously means what you want. So you'd need ways to identify (testing) and correct (fixing) theses ambiguities.

And maybe, at some point you would change your mind on some behaviours ; and then you'd come back to your description and modify it so future behaviours changes might be easier to deal with (refactoring).

And also, maybe your intelligent system has inferred a correct way of doing things that is actually too slow. Maybe you could order "do it faster!", or maybe you would need to identify the source of slowness (profiling), and edit your description so a faster behaviour is inferred (optimizing).

At this point, you in an attempt to improve your efficiency, you might consider using a simplified notation, which would be less-ambiguous and less verbose (like did scientists, musicians, engineers, mathematicians ...).

See, nothing to do with programming!