Ask HN: Is coding like speaking another language?
72 comments
I think comparing programming languages to natural languages will lead your listener down the wrong path.
Programming is writing instructions for a computer. It's just like how you program your alarm clock to go off at a certain time. But imagine if you could write instructions like, "If it's a weekday ring at 8, if it's a weekend ring at 9. If I hit snooze, ring again in 5 minutes." A programming language is a formal way of writing this down so it's easy for the computer to understand.
Programming is writing instructions for a computer. It's just like how you program your alarm clock to go off at a certain time. But imagine if you could write instructions like, "If it's a weekday ring at 8, if it's a weekend ring at 9. If I hit snooze, ring again in 5 minutes." A programming language is a formal way of writing this down so it's easy for the computer to understand.
Programming imperative languages is like giving instructions to a computer. Logic programming is like explaining your problem to a computer. Functional programming feels somewhere in between.
I'd say functional programming could be compared to constructing a mathematical expression (at least, this is what it feels like Haskell is trying to push).
As a programmer who is working on a language learning startup, I've thought alot about how and why these two disciplines are different. And I believe that learning a spoken language is actually much harder than learning a programming language for the following reasons:
* In order to strengthen your spoken language skills you must engage in what amounts to a performance in front of experts, akin to getting on stage as an raw amateur and performing jazz music to a crowd of experts. Programming can be learned in the quiet and safety of your home.
* Speaking a language is a synchronous activity, programming is asynchronous. You need full command over an enormous amount of new material when speaking a new language, whereas with programming you can always pause things in order to look something up.
* Learning to speak a language has a slow feedback loop compared to programming. You learn concept or word A, and by the time you first need to deploy that word or concept in the wild, it has been forgotten.
* Learning to speak a language has inconsistent feedback, with native speakers giving contradictory or unclear advice. Compilers, not so much.
* Speaking a language requires relearning muscoskeletal behavior that has been ingrained since birth.
* Speaking a new language badly is an act of courage that often penalizes introverted or perfectionist personality types. These types thrive when learning computer programming.
I could go on... :)
* In order to strengthen your spoken language skills you must engage in what amounts to a performance in front of experts, akin to getting on stage as an raw amateur and performing jazz music to a crowd of experts. Programming can be learned in the quiet and safety of your home.
* Speaking a language is a synchronous activity, programming is asynchronous. You need full command over an enormous amount of new material when speaking a new language, whereas with programming you can always pause things in order to look something up.
* Learning to speak a language has a slow feedback loop compared to programming. You learn concept or word A, and by the time you first need to deploy that word or concept in the wild, it has been forgotten.
* Learning to speak a language has inconsistent feedback, with native speakers giving contradictory or unclear advice. Compilers, not so much.
* Speaking a language requires relearning muscoskeletal behavior that has been ingrained since birth.
* Speaking a new language badly is an act of courage that often penalizes introverted or perfectionist personality types. These types thrive when learning computer programming.
I could go on... :)
[deleted]
No. It's more like speaking the same language (English or whatever) aimed at a very specific audience. A bit similar to talking to someone who takes everything literally. Without room for interpretation.
In that sense, it's closer to a method of organizing thought than it is to another language.
Background: software engineer who speaks 5 languages.
In that sense, it's closer to a method of organizing thought than it is to another language.
Background: software engineer who speaks 5 languages.
Do you feel like learning each of the languages you can speak has affected the way you think in any way?
In other words, does being fluent in different languages cause people to think differently?
In other words, does being fluent in different languages cause people to think differently?
Yes, different languages make you think differently. Some things are easier to express in one language than the other.
I think it is very unfortunate that we use the same work "language" for human languages and computer languages. They are nothing alike, except you can write them in textual form and they have some kind of "grammar". It's a bit silly, but if you can't say "I love you", it is not a language to me.
I would rather say, programming is like designing an intricate mechanism, such as a mechanical clock. Some people have compared it to carpentry, or engineering.
I would rather say, programming is like designing an intricate mechanism, such as a mechanical clock. Some people have compared it to carpentry, or engineering.
> if you can't say "I love you", it is not a language to me.
void declareEmotion( bool isInLoveWith ) { if( isInLoveWith ) { printf("I love you\n"); else printf("I'm sorry, this isn't working out...\n"); } }
void declareEmotion( bool isInLoveWith ) { if( isInLoveWith ) { printf("I love you\n"); else printf("I'm sorry, this isn't working out...\n"); } }
> if you can't say "I love you", it is not a language to me
Japanese don't say "I love you" (winky face)
[1] https://www.quora.com/Do-Japanese-people-say-I-love-you-to-p...
[2] https://answers.yahoo.com/question/index?qid=20090222081745A...
[3] https://www.youtube.com/watch?v=azLpKvKBdHE
Japanese don't say "I love you" (winky face)
[1] https://www.quora.com/Do-Japanese-people-say-I-love-you-to-p...
[2] https://answers.yahoo.com/question/index?qid=20090222081745A...
[3] https://www.youtube.com/watch?v=azLpKvKBdHE
In the native dialect of western Austria you can't say "I love you".
Some form of "I like you" is as high as the emotions get there.
Some form of "I like you" is as high as the emotions get there.
While I don't agree with OP, I don't think this is a valid argument. One can say "I love you" in a subset of formal Sanskrit which obey's Panini's grammar and rules.
I don't understand - Sanskrit is a human language (albeit a dead one).
Whereas, you could "write" programs by arranging little pieces of would with symbols on them on a board. You could punch hole cards for a mechanical loom, or you could solder electronic components together. None of that involves communicating with other people.
I think a better analogy than language would be a mathematical calculus - i.e. the way you can write down certain symbols, and manipulate them using certain rules, and you have certain guarantees about the result.
Another analogy would be a "kit" of standardized/conventional elements for construction, e.g. I-beams, windows, tiles, 2x4s, doors, cable channels, ... . You arrange these things, and if you do it properly, you get something meaningful and useful like a house.
Whereas, you could "write" programs by arranging little pieces of would with symbols on them on a board. You could punch hole cards for a mechanical loom, or you could solder electronic components together. None of that involves communicating with other people.
I think a better analogy than language would be a mathematical calculus - i.e. the way you can write down certain symbols, and manipulate them using certain rules, and you have certain guarantees about the result.
Another analogy would be a "kit" of standardized/conventional elements for construction, e.g. I-beams, windows, tiles, 2x4s, doors, cable channels, ... . You arrange these things, and if you do it properly, you get something meaningful and useful like a house.
Writing a program is different from the concept of what a programming language is. A programming language has an underlying grammar/rules. Through Panini's work, a subset of Sanskrit can also be expressed through rules.
This link on grammar might also interest you- https://en.wikipedia.org/wiki/Formal_grammar
This link on grammar might also interest you- https://en.wikipedia.org/wiki/Formal_grammar
It's a series of tools and components required to fit certain related theories?
In carpentry you have many standardized off-the-shelf tools and components (hammers, nails, windows, tiles, dimensional lumber) and you have an almost endless number of ways to combine them. You can also create your own tools and components (which is harder). You also have some pre-determined guidelines that are meant to protect/regulate things so that they're safer and easier for a wider audience to live with, maintain, and edit (building codes).
Any of this stuff will work together as long as you stick to the constraints of individual objects as they fit into the laws of physics (a component can only bear X load in Y configuration).
The concept of "properly" is a bit varied. I can build a house with mud and straw and it's a "proper" house in some parts of the world... but it might kill me in an earthquake. This might be due to a pre-determined assessment of earthquake risk, or it might be because of limited knowledge and resources available (very common in coding, and often OK in small scale scenarios).
In carpentry you have many standardized off-the-shelf tools and components (hammers, nails, windows, tiles, dimensional lumber) and you have an almost endless number of ways to combine them. You can also create your own tools and components (which is harder). You also have some pre-determined guidelines that are meant to protect/regulate things so that they're safer and easier for a wider audience to live with, maintain, and edit (building codes).
Any of this stuff will work together as long as you stick to the constraints of individual objects as they fit into the laws of physics (a component can only bear X load in Y configuration).
The concept of "properly" is a bit varied. I can build a house with mud and straw and it's a "proper" house in some parts of the world... but it might kill me in an earthquake. This might be due to a pre-determined assessment of earthquake risk, or it might be because of limited knowledge and resources available (very common in coding, and often OK in small scale scenarios).
It's not like working in another language at all (I speak English and Mandarin).
When I try to explain to non-programmers what programming is like, the analogy I like to use is drawing.
With drawing, you start of with a blank piece of paper, and someone asks you to draw something (or you decide to draw it for yourself) and so you draw away, adding bits here and bits there, adjusting things, erasing things, redoing mistakes and maybe even starting over entirely. Slowly it starts to take shape and you keep going until you are satisfied with the end result (though sometimes you are never fully satisfied and there are always small adjustments you feel you could make).
Each artist has their own style and you could ask 10 people to draw you a picture of a house or a dog, and you'd get 10 different pictures of houses and dogs, each one definitely a house or a dog (assuming competent artists here), but each one unique and drawn in the style of the individual artist.
Programming is then drawing with math and logic. You start with a blank file, and someone asks you to program something (or you decide to program it for yourself) and so you program away, adding bits here and bits there, adjusting things, erasing things, redoing mistakes and maybe even starting over entirely. Slowly it starts to take shape and you keep going until you are satisfied with the end result (though sometimes you are never fully satisfied and there are always small adjustments you feel you could make).
Each programmer has their own style and you could ask 10 programmers to implement a given program or feature and you'd get 10 different programs, each one matching the requirements (assuming competent programmers here) but each one unique and programmed in the style of the individual programmer.
Anyway, it's not a perfect analogy, but I've found it works quite well to explain things to non-programmers.
When I try to explain to non-programmers what programming is like, the analogy I like to use is drawing.
With drawing, you start of with a blank piece of paper, and someone asks you to draw something (or you decide to draw it for yourself) and so you draw away, adding bits here and bits there, adjusting things, erasing things, redoing mistakes and maybe even starting over entirely. Slowly it starts to take shape and you keep going until you are satisfied with the end result (though sometimes you are never fully satisfied and there are always small adjustments you feel you could make).
Each artist has their own style and you could ask 10 people to draw you a picture of a house or a dog, and you'd get 10 different pictures of houses and dogs, each one definitely a house or a dog (assuming competent artists here), but each one unique and drawn in the style of the individual artist.
Programming is then drawing with math and logic. You start with a blank file, and someone asks you to program something (or you decide to program it for yourself) and so you program away, adding bits here and bits there, adjusting things, erasing things, redoing mistakes and maybe even starting over entirely. Slowly it starts to take shape and you keep going until you are satisfied with the end result (though sometimes you are never fully satisfied and there are always small adjustments you feel you could make).
Each programmer has their own style and you could ask 10 programmers to implement a given program or feature and you'd get 10 different programs, each one matching the requirements (assuming competent programmers here) but each one unique and programmed in the style of the individual programmer.
Anyway, it's not a perfect analogy, but I've found it works quite well to explain things to non-programmers.
Not really. Looking at my code, I'll often see myself writing comments where I refer to functions and the like as "things". I never see written sentences as things, at least not in the same way.
The closest analogy I can think of are magic spells. When I think of, say, a wizard, casting a spell, I don't think of him speaking some kind of magical language, he's uttering some words which have magical consequences. In this way a spell is a thing which results in an action. In the same way I use a programming language to write what I see as discrete blocks of code that cause something to happen. By contrast, "normal" languages are just used for communication.
It's kinda hokey, and you probably won't be able to tell people that programming is like creating magical spells, but you asked.
The closest analogy I can think of are magic spells. When I think of, say, a wizard, casting a spell, I don't think of him speaking some kind of magical language, he's uttering some words which have magical consequences. In this way a spell is a thing which results in an action. In the same way I use a programming language to write what I see as discrete blocks of code that cause something to happen. By contrast, "normal" languages are just used for communication.
It's kinda hokey, and you probably won't be able to tell people that programming is like creating magical spells, but you asked.
When it comes to code, English speakers like to talk about how good, pure, or expressive a code language is. For example, ask people up in here to describe PHP and you'll get bile. Ask them to talk about Closure and you'll get accolades. Usually summarized as "because the language is bad the result will be bad"
...the irony is that the discussion will be in English. One of the worlds most inconsistent, awkward, written languages. [1] Further more, most code is English. Example: it's usually "if/else" not "si/sinon" or "と/又は"
IMHO I don't think the analogy holds. However, I don't know of a better way to describe it.
PS: I'm bilingual (French/English)
[1] http://aclassen.faculty.arizona.edu/content/english-language...
...the irony is that the discussion will be in English. One of the worlds most inconsistent, awkward, written languages. [1] Further more, most code is English. Example: it's usually "if/else" not "si/sinon" or "と/又は"
IMHO I don't think the analogy holds. However, I don't know of a better way to describe it.
PS: I'm bilingual (French/English)
[1] http://aclassen.faculty.arizona.edu/content/english-language...
There are a number of polyglots who disagree with your sentiment. Nabokov immediately comes to mind. He preferred english because of its capacity for precision and expressive-ness.
[deleted]
Well, yeah. English is the JavaScript of natural languages.
Could you explain what you mean by this?
I am not the original commenter, but - English is full of slang and borrowed concepts. And it has rules, but they aren't really enforced and there are many cases where the rules are explicitly broken. Every generation, we see new additions to the English language and removals of old/out of date phrasing.
When you look at it like that, yeah, it's kinda like JavaScript - not really object oriented and not really functional but borrows concepts from both, loosely typed (rules aren't really enforced), and there's a new library every month that drastically changes the language (slang, evolving with the generations).
I only speak English, so I'm not sure if other languages are like this.
When you look at it like that, yeah, it's kinda like JavaScript - not really object oriented and not really functional but borrows concepts from both, loosely typed (rules aren't really enforced), and there's a new library every month that drastically changes the language (slang, evolving with the generations).
I only speak English, so I'm not sure if other languages are like this.
No, definitely not. To me it is about the logical flow of thought that is put into a structured format. That might sound like spoken language, and to a certain extent it is. But code is more than just that. It is precise. There is no ambiguity. There are hard rules. A violation of format/structure/syntax is not allowed.
Most importantly, logical errors result in unexpected behavior. In most spoken language, someone could be an absolutely terrible speaker and can still manage to get the idea across. There is no code equivalent of saying to someone, "I dunno, it's hard to explain, but you know what I mean, right?"
I would say the closest "language" that code can be related to is legalese. It has definitions and exceptions and legal agreements tend to conform to standard to ensure their validity and enforceability. A significant error in this regard would void the agreement, or at least part of it - similar to a compiler error. Also, I like to think of good code being a battle plan where you want to make sure no one is able to do anything you don't want them to do, even if they do something unexpected or deliberately try to break your code. You try to think of every scenario that you can possibly encounter and you code for it. This creates a defense for your code. Legal documents tend to be created with a similar mindset of protection and survival.
Most importantly, logical errors result in unexpected behavior. In most spoken language, someone could be an absolutely terrible speaker and can still manage to get the idea across. There is no code equivalent of saying to someone, "I dunno, it's hard to explain, but you know what I mean, right?"
I would say the closest "language" that code can be related to is legalese. It has definitions and exceptions and legal agreements tend to conform to standard to ensure their validity and enforceability. A significant error in this regard would void the agreement, or at least part of it - similar to a compiler error. Also, I like to think of good code being a battle plan where you want to make sure no one is able to do anything you don't want them to do, even if they do something unexpected or deliberately try to break your code. You try to think of every scenario that you can possibly encounter and you code for it. This creates a defense for your code. Legal documents tend to be created with a similar mindset of protection and survival.
I think it's more like learning to express yourself in a different style, rather than learning an entirely different language.
The style we are accustomed to allows for an interlocutor with significant ability to fill in the gaps in what you've said or written. To read appropriate context and subtext into your words and interpret them meaningfully despite ambiguity.
The style we must learn when programming is to remove all possible ambiguity and subtext, and explicitly provide a context (arguments, scope, closure, environment, etc.) for evaluation.
When we learn a new language we learn new vocabulary and alternate syntax but we still express ourself in the same style. When we learn a new style we must unlearn and relearn all of our assumptions about how language is interpreted. That's what learning programming is like.
The style we are accustomed to allows for an interlocutor with significant ability to fill in the gaps in what you've said or written. To read appropriate context and subtext into your words and interpret them meaningfully despite ambiguity.
The style we must learn when programming is to remove all possible ambiguity and subtext, and explicitly provide a context (arguments, scope, closure, environment, etc.) for evaluation.
When we learn a new language we learn new vocabulary and alternate syntax but we still express ourself in the same style. When we learn a new style we must unlearn and relearn all of our assumptions about how language is interpreted. That's what learning programming is like.
I don't think they're similar at all. It's an anecdote and all, but I am terrible at learning foreign languages. Something about the way my brain works. I lived in France for two years and married a French woman and I still couldn't get by for more than a day or two in that country on my own. Yet I picked up programming pretty quickly and consider myself good at it.
I think the best analogy is mathematics, in the sense that you're reasoning about abstract objects and solving puzzles. Unfortunately most people don't think about math that way so it probably doesn't help much.
I think the best analogy is mathematics, in the sense that you're reasoning about abstract objects and solving puzzles. Unfortunately most people don't think about math that way so it probably doesn't help much.
The authors of SICP draw a distinction between declarative knowledge (facts about the world) and procedural knowledge (instructions for how to do things). Programming, they say, is a way to precisely communicate procedural knowledge.
Most interpersonal communication is both imprecise and not procedural knowledge, and that is the biggest difference between speaking with a person and programming a computer.
Most interpersonal communication is both imprecise and not procedural knowledge, and that is the biggest difference between speaking with a person and programming a computer.
Linguist here. It's doesn't seem very similar to speaking another language at all. Hockett's Design Features is a set of features that is commonly used to distinguish natural human languages from other systems of communication: https://en.wikipedia.org/wiki/Hockett%27s_design_features
Not that those features are requirements or anything, but they serve as a good guideline. As you can see, programming languages lack many of these features. For one, lack productivity — you can't suddenly switch up the syntax in some novel way or make up a new keyword to achieve some effect and expect the compiler/interpreter to just understand it.
Programming is probably more akin to a jargon + some technical knowledge to go with it, but it's still a bad comparison because a jargon is still a part of a natural language — programming languages are not.
Not that those features are requirements or anything, but they serve as a good guideline. As you can see, programming languages lack many of these features. For one, lack productivity — you can't suddenly switch up the syntax in some novel way or make up a new keyword to achieve some effect and expect the compiler/interpreter to just understand it.
Programming is probably more akin to a jargon + some technical knowledge to go with it, but it's still a bad comparison because a jargon is still a part of a natural language — programming languages are not.
I like to equate it to giving instructions to someone who takes everything you say extremely literally. Ask me to make a PB&J? If you tell me to stick the knife in the PB, since you didn't specify what side to stick in, I sometimes put it in handle first, sometimes knife edge first, depending on how I found it. To make a successful program, you would need to account for all the possible inputs (the different orientations of the knife in the drawer, the possibility that there might not be a knife, etc.). The difference between good software and bad software is that the good software will properly handle all of these error conditions, and the bad software will either do the wrong thing (sticking it in handle first, because the instructions assumed the knife was always oriented correctly) or will crash when something unexpected happens (such as there not being any more knifes, or running out of peanut butter half way through making a sandwich).
Coding is like describing a trip to the grocery store in 100 pages.
"He stood up, he walked forward 10 paces, he grabbed the door, he opened the door, he walked through the door..."
"He stood up, he walked forward 10 paces, he grabbed the door, he opened the door, he walked through the door..."
Let's all stop using such imperative languages!
...(by walking through the door (by opening the door (by grabbing the door (by being close enough to grab the door (by taking one step towards while being more than one step away from the door and repeating until he was close enough to grab the door))))...)
closeDoor >>= foldM (stepsTo valhalla)
How about, let's all stop being so judgmental about other peoples' language choices.
I'm confused. Is this directed at me or the top post?
At you - or at least at your post, the one that is great-grandparent to this one.
Someone else was complaining about the excessive pedantry imperative languages and I pointed out not all languages are so pedantic.
And you're calling this judgement? I mean, in the objective sense: declarative languages abstract over control flow and make programs less repetitive. If you (like me) think that's bad, then I think my conclusion is obvious. If you don't, why would my opinion concern you at all?
It's almost like your comment is, "Hey don't have opinions about tooling."
If that's your message: I apologize but I both cannot and will not oblige you.
And you're calling this judgement? I mean, in the objective sense: declarative languages abstract over control flow and make programs less repetitive. If you (like me) think that's bad, then I think my conclusion is obvious. If you don't, why would my opinion concern you at all?
It's almost like your comment is, "Hey don't have opinions about tooling."
If that's your message: I apologize but I both cannot and will not oblige you.
Well, to me at least, you came across as more than just saying "here's a solution to the excessive pedantry". I read your response as being more judgmental than that. Perhaps that's my problem rather than yours, but that's how I read it.
As qbrass pointed out, though, a functional language doesn't really save you from (most of) the detail, but only lets you express it somewhat better. (Your foldM reply, if I understand correctly, only eliminates the loop of taking steps. Somewhere you still have to put your hand on the door, turn the doorknob, swing the door open, etc.)
So the excessive pedantry is still there. It's just slightly less, because you use a fold[M] rather than explicitly write the for loop. That's... a bit of improvement. It's a detail you don't have to pay attention to when you don't need to, which is most of the time. But (at least in this example), the vast bulk of the detail remains, even in a functional language.
As qbrass pointed out, though, a functional language doesn't really save you from (most of) the detail, but only lets you express it somewhat better. (Your foldM reply, if I understand correctly, only eliminates the loop of taking steps. Somewhere you still have to put your hand on the door, turn the doorknob, swing the door open, etc.)
So the excessive pedantry is still there. It's just slightly less, because you use a fold[M] rather than explicitly write the for loop. That's... a bit of improvement. It's a detail you don't have to pay attention to when you don't need to, which is most of the time. But (at least in this example), the vast bulk of the detail remains, even in a functional language.
It's true: we'd need a way to describe the tiny imperative steps.
The benefit is that we DON'T need all the glue between them. Few languages and methodologies can deliver on this problem as well as Haskell can. Consider what my example is folding over and how those elements must connect.
I'm not sure we could really do that monoidally. For a sequence of steps: probably. For opening doors and other conditional actions: we might need a more flexible strategy (I'm sure at the end though we'd call sequenceA on it!)
The benefit is that we DON'T need all the glue between them. Few languages and methodologies can deliver on this problem as well as Haskell can. Consider what my example is folding over and how those elements must connect.
I'm not sure we could really do that monoidally. For a sequence of steps: probably. For opening doors and other conditional actions: we might need a more flexible strategy (I'm sure at the end though we'd call sequenceA on it!)
As a bilingual person, I wouldn't describe learning to code as being similar to learning a new human language. The fundamental building blocks of programming (loops, variables, functions, etc.) are vastly different from the building blocks of human language (nouns, verbs, adjectives, etc.).
However, I would describe learning a new programming language if you already know one (say, C++ to Python) as similar to learning a new human language (English to Spanish). The languages in both cases may be different, but the fundamental building blocks of expression are mostly the same.
However, I would describe learning a new programming language if you already know one (say, C++ to Python) as similar to learning a new human language (English to Spanish). The languages in both cases may be different, but the fundamental building blocks of expression are mostly the same.
Who's your target audience, and what will that description be used for?
That single sentence of description is fine for a general audience, and as a lead-in to a more in-depth discussion but it's a single sentence and not an in-depth analysis. There are books more that could be said about the differences and similarities between being multilingual for programming languages verses spoken languages but a dissertation on why the comparison (likely) not what's being asked of you.
The follow-on ramifications of something being in a different language than one you speak, rather than a comparison of multilinguality itself might be useful to highlight. It's one thing for you as a person to speak two programming languages, but if one language runs server-side, and the other is client side, it's good to illustrate that teaching Chrome to "speak" a different language is going to be harder than for your company to provide translations. Similarly, if the company is trying to move to and canonicalized on a second programming language, it needs to be illustrated (in lines of code) as to how much currently exists at in the first language, and must be translated to the second.
Programming languages are not like spoken languages because people there can be discussions about syntax and parsing, but then a new version of the compiler comes out and the system is rolled and every"one" speaks the new version (and the old, for that matter). Meanwhile we're still working on being able to do that for humans.
That single sentence of description is fine for a general audience, and as a lead-in to a more in-depth discussion but it's a single sentence and not an in-depth analysis. There are books more that could be said about the differences and similarities between being multilingual for programming languages verses spoken languages but a dissertation on why the comparison (likely) not what's being asked of you.
The follow-on ramifications of something being in a different language than one you speak, rather than a comparison of multilinguality itself might be useful to highlight. It's one thing for you as a person to speak two programming languages, but if one language runs server-side, and the other is client side, it's good to illustrate that teaching Chrome to "speak" a different language is going to be harder than for your company to provide translations. Similarly, if the company is trying to move to and canonicalized on a second programming language, it needs to be illustrated (in lines of code) as to how much currently exists at in the first language, and must be translated to the second.
Programming languages are not like spoken languages because people there can be discussions about syntax and parsing, but then a new version of the compiler comes out and the system is rolled and every"one" speaks the new version (and the old, for that matter). Meanwhile we're still working on being able to do that for humans.
I know several programming languages (e.g. Elixir, Elm, Erlang, Haskell, Ruby, Python, etc.), and I also speak English and Japanese fluently. With programming languages, the fundamentals beneath the syntax are basically the same. For example, whether I use recursion or for loops, all of the programming languages I know support iterating through a list of data. Similarly, they all have some mechanism for making logic decisions, such as if or case statements. So, learning a new programming language is just a matter of mapping new syntax to concepts I already know. If learning a new spoken language were simply a matter of mapping vocabulary words to meanings, then I would say both are the same, but this is not the case.
In spoken languages, there are cultural differences that have to be learned and concepts that just don't translate well between languages, if at all. Idioms are also difficult. Often times, there is no cultural foundation in one language to make sense of the idioms used in another. Unlike computer programming, there is no underlying base that you can use to map new knowledge too. You have to build your entire understanding from scratch.
In spoken languages, there are cultural differences that have to be learned and concepts that just don't translate well between languages, if at all. Idioms are also difficult. Often times, there is no cultural foundation in one language to make sense of the idioms used in another. Unlike computer programming, there is no underlying base that you can use to map new knowledge too. You have to build your entire understanding from scratch.
I would assume it feels that way to those who don't speak English natively. Otherwise, I would say it's more like turning math into a language.
Programming is a "class of language" ... latin/romance, germanic, slavik, etc.
"I speak programming. Specifically I speak C++."
Furthermore, within programming there are classes of languages (imperative, functional, oo, pattern matching, etc).
"I speak programming. I understand imperative and OO from C++, but struggle to understand functional, as I'm not used to composing my thoughts that way."
There are varying degrees of fluency / literacy in each of these classes of languages.
"I'm an expert in C++11, and wouldn't hesitate to write or maintain any C++ code. I can also read and modify many C-like languages (Java, JavaScript, Objective-C, Go) and may play with them on the weekend, but they would not be my first choice in starting a project at work. I can read some lisp code, but I can never understand something written in erlang no matter how many times I try."
So I would say that you can draw comparisons between northern v. southern english (ie: versions of C++) then english (ie: C-like languages) rolling up into germanic / romance (ie: imperative languages).
Regarding "translation", that's reasonable to understand. However, a programming translation has extra requirements to be successful.
1) it must be complete (at least the translated portion) 2) it must be 100% correct 3) regardless of the language, it must cause the same effect
...a partial translation, a translation with errors, or a slightly different meaning can "ruin" the programming translation, whereas minor errors or awkwardness in your normal translation are generally easy to overcome compared to a traditional written text designed for human (not computer) consumption.
"I speak programming. Specifically I speak C++."
Furthermore, within programming there are classes of languages (imperative, functional, oo, pattern matching, etc).
"I speak programming. I understand imperative and OO from C++, but struggle to understand functional, as I'm not used to composing my thoughts that way."
There are varying degrees of fluency / literacy in each of these classes of languages.
"I'm an expert in C++11, and wouldn't hesitate to write or maintain any C++ code. I can also read and modify many C-like languages (Java, JavaScript, Objective-C, Go) and may play with them on the weekend, but they would not be my first choice in starting a project at work. I can read some lisp code, but I can never understand something written in erlang no matter how many times I try."
So I would say that you can draw comparisons between northern v. southern english (ie: versions of C++) then english (ie: C-like languages) rolling up into germanic / romance (ie: imperative languages).
Regarding "translation", that's reasonable to understand. However, a programming translation has extra requirements to be successful.
1) it must be complete (at least the translated portion) 2) it must be 100% correct 3) regardless of the language, it must cause the same effect
...a partial translation, a translation with errors, or a slightly different meaning can "ruin" the programming translation, whereas minor errors or awkwardness in your normal translation are generally easy to overcome compared to a traditional written text designed for human (not computer) consumption.
It really depends on the language and what you are doing. The majority of of the field is closest to working with mathematical equations which makes sense as the people who created the languages took ideas from mathematics when designing the language and did the hard work of transforming those ideas into something that could be ran on a computer.
However, as you get closer to the hardware level, you move away from the abstract and need to think about the way the machine is built/configured and the actual instructions that will be executed. There are some languages, like C, that kind of bridge the divide between the two. Others, like Lisp, are almost entirely abstract with little need to think about how the instructions get ran at a lower level.
However, as you get closer to the hardware level, you move away from the abstract and need to think about the way the machine is built/configured and the actual instructions that will be executed. There are some languages, like C, that kind of bridge the divide between the two. Others, like Lisp, are almost entirely abstract with little need to think about how the instructions get ran at a lower level.
Combining a few other answers, I'd say it's a lot like writing a goosebumps (choose your own adventure) book in another language.
While I do like the analogy of writing instructions for someone who is very dumb, that analogy doesn't capture the different paths of execution that a program can take.
While I do like the analogy of writing instructions for someone who is very dumb, that analogy doesn't capture the different paths of execution that a program can take.
Not quite, but what I do believe is true is that learning multiple programming languages is similar to learning multiple spoken languages.
Just as knowing Spanish will aid you in learning Portuguese, knowing Python will help you pick up Ruby. After you know a few varying languages it becomes much easier to pick up a new one. You notice that they all share the same basic constructs.
Also, each language (in both realms) brings new modes of expression to the table and these can open your mind to alternate ways of thinking. You notice this with spoken languages most when you run into a phrase that is untranslatable to some other languages. This part is perhaps more true of programming languages than spoken languages, but I believe it is true of both to some degree.
Just as knowing Spanish will aid you in learning Portuguese, knowing Python will help you pick up Ruby. After you know a few varying languages it becomes much easier to pick up a new one. You notice that they all share the same basic constructs.
Also, each language (in both realms) brings new modes of expression to the table and these can open your mind to alternate ways of thinking. You notice this with spoken languages most when you run into a phrase that is untranslatable to some other languages. This part is perhaps more true of programming languages than spoken languages, but I believe it is true of both to some degree.
It depends. But generally, I think it is. Although it uses different facilities from those which we commonly use to speak languages.
It's most evident when you use related families of languages. Using up to Python, Ruby or Coffescript is a lot like the related family of english languages; once you know one or two you sort of get them all fundamentally. Javascript, Io and Perl are like lost cousin languages; you can often recognize bits but the sentence structures and dialogue conventions may seem quite foreign.
Confronting purely functional languages is VERY much like having to relearn the same skills of communication from the ground up.
It's most evident when you use related families of languages. Using up to Python, Ruby or Coffescript is a lot like the related family of english languages; once you know one or two you sort of get them all fundamentally. Javascript, Io and Perl are like lost cousin languages; you can often recognize bits but the sentence structures and dialogue conventions may seem quite foreign.
Confronting purely functional languages is VERY much like having to relearn the same skills of communication from the ground up.
I'd say it's like writing down very specific instructions to do something, that afterwards can be translated to manipulation of numbers.
The results get to be stored, retrieved and displayed.
Since it's a manipulation of numbers, the set of rules you get to use are all based on logic (if this, then that, etc)
Then you can add an extra step of number manipulation can be boiled down to manipulating binary numbers consisting of 0s and 1s, so the logic used is boolean logic etc.
So I'd say programming is more like learning logic constructs (math) - it's a universal language with rules that are interested in manipulating values in very complex ways.
The results get to be stored, retrieved and displayed.
Since it's a manipulation of numbers, the set of rules you get to use are all based on logic (if this, then that, etc)
Then you can add an extra step of number manipulation can be boiled down to manipulating binary numbers consisting of 0s and 1s, so the logic used is boolean logic etc.
So I'd say programming is more like learning logic constructs (math) - it's a universal language with rules that are interested in manipulating values in very complex ways.
Yes. It's a way of thinking that is communicated by words. Same as speaking a foreign language for me. I wouldn't be surprised to find out that the same parts of the brain are involved.
To elaborate, in some spoken languages you have adjective noun (e.g. blue house), but in others the order is reversed (casa azul). At some point of learning you just subconsciously know which form to use. This is similar to programming when you can use the appropriate idioms in each language. E.g. using duck typing in python vs type checks/conditionals etc. in Java.
To elaborate, in some spoken languages you have adjective noun (e.g. blue house), but in others the order is reversed (casa azul). At some point of learning you just subconsciously know which form to use. This is similar to programming when you can use the appropriate idioms in each language. E.g. using duck typing in python vs type checks/conditionals etc. in Java.
I think it's more like a different type english.
You express the same types of concepts, but you break them down into very small parts and than build up the argument comprised of small parts.
Like instead of saying "the bike went forwards" which is very conceptual and requires a lot of background understanding of bikes and physics, you describe a bike consisting of wheels, a frame, a steering wheel etc. than describe the action of moving in a direction. finally you apply to action to the bike.
You express the same types of concepts, but you break them down into very small parts and than build up the argument comprised of small parts.
Like instead of saying "the bike went forwards" which is very conceptual and requires a lot of background understanding of bikes and physics, you describe a bike consisting of wheels, a frame, a steering wheel etc. than describe the action of moving in a direction. finally you apply to action to the bike.
No, coding is a series of instruction put on a specific order for a machine to process not an a instrument to communicate with another (computer) entity.
Modern languages are designed to be the most human-friendly possible to express those "commands", even the "lowest" language you could learn (assembly) it's still way to human friendly if compared to real bare bones communicating with the computer hardware.
Modern languages are designed to be the most human-friendly possible to express those "commands", even the "lowest" language you could learn (assembly) it's still way to human friendly if compared to real bare bones communicating with the computer hardware.
It's not (quite)
Despite being called "programming languages", they are not really languages for people to communicate, but for computers to understand instructions (although, humans do need to understand a programming language to be able to code).
Saying that coding is like speaking another language can be confusing, so I'd recommend that coding is more like instructing a computer to do something (by writing instructions).
Despite being called "programming languages", they are not really languages for people to communicate, but for computers to understand instructions (although, humans do need to understand a programming language to be able to code).
Saying that coding is like speaking another language can be confusing, so I'd recommend that coding is more like instructing a computer to do something (by writing instructions).
I don't think so at all. Natural languages evolve with ambiguity built in — any sort of ambiguity is almost always an error in programming.
Someone can say "coding is like solving equations" another "coding is like wandering in a (irl) forest." I don't think there is any right or best answer. My take on it is that coding is like sculpturing, but that answer is just as flawed as all the others. Few activities (that I know of) are very similar to computer programming.
I actually agree with your simulacrum. I also agree with others that code has more in common with a cake recipe than Pride and Prejudice ;-)
The above said, language is language whether you're struggling to control a state-machine, baking vegan cookies or ordering lunch in Paris. It's difficult, it takes time to learn and delivers the same rewards all around.
Cheers
The above said, language is language whether you're struggling to control a state-machine, baking vegan cookies or ordering lunch in Paris. It's difficult, it takes time to learn and delivers the same rewards all around.
Cheers
Programming is about defining requirements in excruciating detail. A business person says "I want this data stored somewhere" and a programmer has to define where it comes from, what the schema is, what transformations happen, how does it get stored, where does it get stored, and what happens if anything in that pipeline goes wrong.
To code is to be very, very specific. That's it. Imagine asking someone to get you a coffee, but you have tell him exactly how to do it down to the tiny details of how to grip a cup with fingers.
The challenge of learning to code is largely the challenge of learning to be specific in your communication and having the patience for all that entails.
The challenge of learning to code is largely the challenge of learning to be specific in your communication and having the patience for all that entails.
Not even a little bit. It's more (but not perfectly) like if we had multiple alphabets to express the same language.
A cogent thought, by which I assume you mean, it's all ultimately bit manipulation.
But in this view can't all the world's languages be seen as multiple alphabets that express and manipulate quantum fluctuations?
Or do different human languages create different underlying realities?
But in this view can't all the world's languages be seen as multiple alphabets that express and manipulate quantum fluctuations?
Or do different human languages create different underlying realities?
Most of the code I write is a mix of broken English and simple equations.
I agree with you: programming languages are languages.
I personally find them simpler than normal languages (no gender pronouns like in German, no special rules for past and present tense etc. Oh, and immediate honest (if somewhat mumbling) feedback from the compiler.
I agree with you: programming languages are languages.
I personally find them simpler than normal languages (no gender pronouns like in German, no special rules for past and present tense etc. Oh, and immediate honest (if somewhat mumbling) feedback from the compiler.
Polyglot here, dont think that it matters tho.
I think of it more as a notation and has more in common with constructs like mathematics than actual spoken language. Yeah we have rules and syntax grammer, but at the end of the day you are expressing it in plain ol English.
I think of it more as a notation and has more in common with constructs like mathematics than actual spoken language. Yeah we have rules and syntax grammer, but at the end of the day you are expressing it in plain ol English.
No, it's not really like that. It's more like preparing an instruction on how
to execute some complicated process, say, cook a fancy meal, for somebody who
is very dumb (but will follow the instruction precisely).
I find that programming feels more like spatial navigation than speech or language.
Cognizing (e.g.) the Eclipse codebase might be roughly equivalent to maintaining a complete mental model of NYC.
Cognizing (e.g.) the Eclipse codebase might be roughly equivalent to maintaining a complete mental model of NYC.
I would say no. It's a shorthand way of writing very explicit instructions. There is far more variety and nuance in human languages than in programming languages.
No. In my opinion, it's much closer to domain specific jargon. Similar to other specialized fields (e.g., paleontology).
"Coding is like working in another language. Just like spoken languages, programming language each have their own grammar and keywords. Reading code and understanding it is like having to translate a document."
However, I'm not bilingual, so I was wondering if someone who was could tell me if this is a reasonable simulacrum. Especially the comparison of effort and difficulty between grokking code and successfully translating documents.