Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Interesting. I feel like coding is not that dissimilar.

In the early phases of learning a new coding language, I learn how to write lines of code. Sometimes it compiles, most of the time it would cause errors.

At some point it works, but a more seasoned engineer could easily find places to refactor it in order to make it more extensible/flexible, easier to read, less brittle, and most importantly to this discussion on coding language, more idiomatic.

Now, you could say surely I could've seen these by reading the docs and learning about certain library features or patterns specific to the language. But in my experience, I tend to learn faster by first exercising my brain and trying it out on my own take before having someone (be it a mentor or a tutorial/book) correct me so that I have a bit more context about why an alternative approach is better.



The thing is, computer languages are extremely simple compared to human languages. Even the more arcane ones, like C++, probably have on the order of 1-200 'words' that you ahev to learn to 'speak' them fluently.

Of course, you also need to learn large amounts of library functions and their semantics, but that's more like learning who the people at court are and what their roles are than like the language. You could speak perfect French, but you still have to learn that you must call the Comptesse de Barry before calling the King if you don't want her to be upset. Even patterns are often more in this area of cultural/local context rather than the actual langauge - more like learning the difference between overly-descriptive prose and good prose is (which is why the knowledge about it also tends to translate better between different languages).


I don't understand this. If your code has wrong syntax it doesn't compile. If wrong grammar you can get very wrong results. But in english you can say "I go store" and it's understandable (which btw, can be a direct translation from several languages)


> If your code has wrong syntax it doesn't compile. If wrong grammar you can get very wrong results.

In both cases, when you get it that wrong that your meaning doesn’t come across correctly, it’ll usually get pointed out to you, either by the compiler or the person you’re talking to, so you can go back and try again.

Eventually, you’ve potentially gotten it right when the compiler stops throwing errors or the person you’re speaking to understands. Unfortunately, in both cases you may still not end up with the desired outcome as your compiler is “stupid” and cannot understand intent, only what you’ve written. Similarly, but different, the human you’re speaking to may bore of your broken language eventually and just move on.

There’s no perfect system for everyone, but it never hurts to remember the saying: perfect is the enemy of good enough. It doesn’t matter if your language skills are perfect, just that they’re good enough to convey your meaning effectively for the environment you’re in.


In my experience, when you're an adult, people are too polite/reserved/caring/uncaring to correct spoken language errors for you. They'll be much more likely to infer what you meant silently, and react as if you'd spoken the sentence perfectly. In that sense, people are much more like a web browser in how they process your language than a compiler.


Apologies, I realise the way I wrote this wasn’t clear enough:

> Eventually, you’ve potentially gotten it right when ... the person you’re speaking to understands

I can see that I wrote poorly here myself, and here you (and child) are correctly correcting me, while simultaneously arguing against that happening, which is kinda ironic!

What I failed to adequately express was that human languages are a lot more forgiving of errors, and as long as the message is understood, you’ve gotten it “right”


They aren't just polite, it's exhausting to play the pedantic compiler and generally degenerates or requires an agreement with an equivalent exchange.

Perhaps having an automatic compiler changes our perception much as an auto-tickling device doesn't work, but surely early levels of math and languages have similar learning paths.


Which is fine, you can learn a lot by immersion when you hear other native speakers talk. I only ask a person to repeat when I don't understand or if it's unclear and I need to be sure about something. Not breaking the flow of conversation is much more important to me


I disagree with this. How many people do you know that have been speaking English for years but still miss articles ('a', 'the')? It is still very easy to understand these people. We could say the same about tones, diction, and accents. Plenty of people that don't sound native can easily be understood. You'd actually be surprised how much you can butcher a language and still be able to communicate (this is really helpful to language learners!). There's so much fuzziness here that it I haven't seen any compiler (plugin, shell, etc) anywhere near this level of fuzziness.

Tldr: Compilers you need to be fairly precise, natural languages you barely need to be in the ball park.


The important part for the fuzzy understanding is shared context. This is what lets humans who have no languages in common communicate basic things in ad-hoc sign language bits as well.

And if the context fails, things can go just as badly as with computers, in the short run. In the longer run, people notice that something went wrong and are likely to go back to an earlier point and try to clarify, whereas computer systems are not great at it.


The people you're talking to are just incredibly intelligent compilers. We could make a compiler that takes something that resembles a for loop and changes it to be correct, but to do so would strip a programmer of the power to make something similar to but not quite a for loop, which would generally be undesirable in a programming language.

"I go store" is reasonably close to correct: you have a subject, predicate, and object and there is one meaning that fits far better than all others. However switch it up to "I store food" and now you have some ambiguity: are you saying you are storing food for later or are you saying you want to go to a grocery store or are you trying to talk about the food you purchased at the store? Again, a human being incredibly intelligent might be able to tell from context, analogous to how someone reviewing a block of code might recognize what a block of code is supposed to be doing, but in general you could expect the interpreter to raise an error, either of the form "bad syntax" or "sorry, I'm not sure what you mean."

If we consider "human languages" like legalese or diplomatic language, where the goal as with programming languages is to limit ambiguity as much as possible while maintaining the speaker's ability to potentially say as many things as possible, syntax becomes very important, and typically it's preferred that the interpreter raise an error rather than try to guess at the speaker's intentions.


The difference is in natural languages you can make tons of errors and be extremely fuzzy and it won't harm the interpretation. Compilers make you update, language doesn't (this does actually cause people to speak a language for decades and never sound native). Often times we can use grammar of another language and the words from another and still get concepts aligned (useful for language learners who will tend to use the grammar of their native language). "Pineapple store I go get" can be a perfectly understandable sentence when context is involved. You can also use direct translations of words from other languages "I put on my... uh... finger shoes." (contextual clues always help, especially in writing).

Humans are "fuzzy compiling" to such a degree (and giving no errors or warnings to the writer) that it is hard to compare the two.

> If we consider "human languages" like legalese or diplomatic language, where the goal as with programming languages is to limit ambiguity as much as possible while maintaining the speaker's ability to potentially say as many things as possible, syntax becomes very important, and typically it's preferred that the interpreter raise an error rather than try to guess at the speaker's intentions.

Such a concept is not even possible in natural languages. Natural languages are so full of ambiguity that even native speakers from similar regions often confuse one another. Because frankly many don't realize there's: what you intend to say, what you say, and what is heard (times number of listeners). When listening to a non-native speaker we focus a lot of trying to understand intent from them. When listening to native speakers we focus a lot on what is said and what we hear (often ignoring intent). There is just so much fuzziness to natural language that it is a bit ludicrous to compare them. The fuzziness of natural language and strictness of programming languages are necessary features too.


> The difference is in natural languages you can make tons of errors and be extremely fuzzy and it won't harm the interpretation.

> Natural languages are so full of ambiguity that even native speakers from similar regions often confuse one another.

These two statements are contradictory. There's a difference between not caring that an error is present and being robust to error. Natural language represents the former. Yes I might not shout "Error: finger shoes not recognized" but that error nevertheless occurred, I don't actually know what they meant. I'm going to assume gloves, but if their life depended on me getting them mittens they'ed probably wish I had said I don't understand. Luckily, we live in a world where getting things wrong is typically harmless, but history is full of disastrous misunderstandings. If you are doing something important like drawing up a legal contract, your lawyer should have no problem telling you "that wording is unacceptable." which is conceptually no different from a compiler's syntax error.

Natural language and programming languages are different in many ways in terms of degree. Natural languages need to be used in vastly more circumstances, they have been in use for vastly longer, and they generally represent an ad hoc development cycle involving millions of independent contributors. They thus have much more deprecated functionality and conflicting user conventions. But while different in degree, the two aren't really different in kind - every fundamental trait of one is shared by the other, which is why the fuzzy compiler for natural language will accept the terms for a programming language as a substitute without raising any error.


They aren't contradictory. You're working backwards to make humans like computers/interpreters. The fact that human interpretation 'doesn't care' is not so much a feature but a necessity. Ambiguity is inherent to natural languages, not a failure of them, nor a feature. On the other side, programming languages are strict my nature and it is a necessity. In programming we have a limited vocabulary and that limits our expressiveness, which is a feature. We don't want probabilistic outcomes for standard means.

So let's look at the two parts you quotes from me and give some examples. We've conversing quite well, wouldn't you say? You understand me and I understand you? So #1 must be true, right? But have you ever played the game telephone[0]. With the general outcome of every game that must mean that #1 cannot be true, yet here we are. Like I said before, when communicating there's: what is intended, what is said, and what is heard. Usually these align pretty well. But small fuzzing adds up quite quickly. But it should also illustrate to you that what you hear (or read) isn't what the speaker (or writer) intended. Their job is to convey as best as they can to you while your job is to interpret as best as you can. Language being of this form allows us to express wildly abstract concepts, especially ones beyond our capacity to even understand. This is the usefulness of natural languages. But it is also why we created mathematical and programming languages, but why they will never be able to have the same expressiveness. You cannot program what you do not understand. But you must be able to talk about what you do not understand, if you are ever to hope to one day understand it.

I'd encourage you to read both more about linguistics and compilers. If you're feeling lazy, Tom Scott has some decent linguistics videos and are aimed at STEM audiences. For more technical maybe see NativLang. For a book, checkout The Unfolding of Language.

[0] https://en.wikipedia.org/wiki/Telephone_(game)

Edit: btw, you did get the meaning of finger shoes (German) even with the extreme limitations of only text based communication.


In the first you say that ambiguity will not harm interpretation, in the second you say that it will cause confusion. I interpreted these statements to be contradictory because my compiler evaluates "harm interpretation" == "cause confusion" to be true.

I don't know if by "we've conversing" you meant we are or we have been conversing. Those two possibilities are close enough to one another that substituting the wrong one will probably not cause a catastrophic failure, but perhaps you meant to use the pluperfect to imply that the conversation was done in some "drop the mic" moment that was completely lost on me.

Telephone is not a game of ambiguity, but of noisy communication. If you start with cat you might get bat at the end, but you wouldn't get feline. You could easily win at telephone by speaking the same meaningless statement repeatedly and you can lose at telephone with a grammatically correct statement which is nevertheless phonetically similar to some other statement. "Blue blue blue blue" is going to make it, "blue crew flew you" probably won't. A fault in transmission is fundamentally different from a syntax error, more analogous to a letter getting lost in the mail or a mistyped letter on the keyboard.

There is a fundamental difference between getting your point across and getting a point across that's similar enough to accomplish your goals.

Consider the following statements:

"I want you to feed my cat

"I want my cat fed"

"I want feed cat"

"You food cat"

"Cat food"

"Weird Dog Rice"

"seltsamer Hundereis"

I am certain you know what I mean in the first sentence. I would be amazed if you could deduce the meaning of the last without further clarification. Between these extremes there is some point where your compiler's heuristics fail, and likely long before that you start losing nuance and details. Natural language error tolerance has its limits.

Now consider the following javascript expressions:

for (let cat in catstofeed) {feedCat(cat)}

var i=1; while (i) { try { feedCat(catstofeed[i-1]); i = i+1; } catch (e) { i = 0;};

var i=0; while (i) { try { feedCat(catstofeed[i]); i = i+1; } catch (e) { i = 0;};

while (i) { try { feedCat(catstofeed[i]); i = i+1; } catch (e) { i = 0;};

If you substituted the second for the first, you'd accomplish what you were setting out to do. The third would lead to a wildly different result but is still valid. The final case is ambiguous, a smart compiler could guess the programmer intended for statement 2's functionality, but asking for clarification is the safer option.

You are right that trying to have a human conversation with only a few dozen words and a very limited sentence structure would be very difficult - a vast vocabulary and complicated grammar is a hard requirement for a natural language, and ambiguity is thus unavoidable. Dealing with such a high level of ambiguity is thus also a requirement of a natural language compiler, and such a compiler is beyond the capability of any existing silicon computer. But just because a language has more words and more valid expressions does not fundamentally change what it is, any more than adding more processing power to a computer eventually makes it stop being a computer.

If you wanted to make a programming language with 50000 keywords and an extremely forgiving syntax, you could do so. It would be extremely impractical for programming a current computer, which is only capable of a few distinct operations and thus has no need for nuance, but it would still work, and damn wouldn't it be great at self documenting.


> In the first you say that ambiguity will not harm interpretation, in the second you say that it will cause confusion.

That's because that's not what I said nor what I meant.


Wrong syntax is more like using the wrong words in human languages than it is like what we normally call bad grammar.

If you write in C 'foo(a;', that's equivalent to saying 'ball foo with a' - the compiler really can't understand what you mean.

The equivalent of 'I go store' is something more like writing 'int p; printf("%d", p);' - the compiler understands what you mean, but it's bad style, and possibly wrong (you're supposed to initialize a variable before you read it).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: