[p-e-w]

It's actually a pretty interesting question why programming languages that work like that are a bad idea.

From decades of experience, I know intuitively that they are, but I find myself unable to formulate a concise description of what exactly is wrong with this approach.

[jacobolus]

Because they turn out to be just as precisely fiddly as any other programming language, but deceptively appear not to be.

If you treat them as English you'll get burned. You have to still treat them as very precise formal languages where apparently trivial/irrelevant details are significant, and minor hard-to-spot mistakes will break your program.

Having more explicitly formal/structured syntax makes it easier to distinguish the different parts of the language, make sense of the details, and figure out what is or isn't allowed.

The best description I have for languages like this, e.g. Applescript, is that they are "read only languages" (in the opposite direction old-style Perl has been called a "write only language"): That is, if you have an already written program in hand it will be easier for a complete novice to read (at least, single isolated lines of code will be). But writing new programs is a huge pain in the ass.

[xypage]

My guess would be that it's because spoken languages and programming languages are fundamentally different, so in trying to make one fit the other you might end up with a programming language that looks and reads a lot like English, but it's almost become self obfuscating because now your brain could automatically try parsing it using the rules for English and not the rules for the programming language, making things look like it should work even if it doesn't. The example the comment you're replying to works pretty well, we probably largely ignore punctuation at the end of sentences in terms of actually consciously seeing it as opposed to just inserting a pause in our mental cadence, so if they're suddenly important pieces of syntax in statements that look like English you could easily start messing up the use of it

[ryanschaefer]

I might offer an alternative perspective.

In my opinion it’s because of english’s evolution over time. Something that might have made perfect sense in the past becomes an antiquated way of saying the same thing in the future. It also deliberately encodes the authors belief about how language should be spoken ignoring any regional variances you see in the real world.

When you abstract away the English meaning of code into something new and unchanging, you provide stability not seen in natural language.

[frutiger]

Too much ambiguity that needs a large amount of context to resolve.

[p-e-w]

But why is that a problem? That's literally how we speak every single day.

In fact, given that this is how all the languages that humans are already familiar with work, it's hard to see why this wouldn't be the best approach for constructing a programming language.

[behnamoh]

Because:

- humans can ask back questions to clarify any ambiguity; computers don't have the capacity to understand ambiguity, let alone asking for clarification.

- computers are trusted to work w/o failure almost 100% of the time. humans err (to be human is to err, anyway), so we'd never put a human in charge of critical things we use computers for.

[readthenotes1]

I agree with your sarcastic reply that naturally grown languages are simply horrible for shared comprehension!

For instance, the poem, or should I say program using the example in the post has several different interpretations, and at least some of those teachers would say are flabbergastingly incorrect.

[oarabbus_]

It’s quite literally a problem, every day.

[alanbernstein]

Because "computers aren't human"