|
 |
Mutual intelligibility of computer languages? | ||
Tags: Computer | ||
Share with:
| ||
 Language Learning Forum : General discussion |  | |
| OlafP Triglot Senior Member Germany Joined 5437 days ago 261 posts - 667 votes  Speaks: German*, French, English | Message 17 of 20 09 January 2010 at 4:34pm | IP Logged | |||||
|
The fact that this thread is somehow sneaking around different aspects without any clear focus seems to support doviende's point, that programming languages are no languages in the proper sense. Sure, you have to get used to any programming language's world view, otherwise you fall into the trap of "writing COBOL in any language". I think C++ was a very bad idea to come up with in the first place. If you want to understand OOP you have to leave structured programming behind, but not add it on top of what you've done in C before.
That aside, I think programming languages have a completely different goal than "normal" languages. On the surface it looks like it's are all about communication, the former with machines and the latter with human beings. The difference becomes clearer if we look at how these two means of communication have developed. Let's focus on "normal" or natural languages first. There can be no doubt that highly developed animals have some sort of reason. They use tools to get food when it's difficult to reach, and it has been observed with monkeys and some birds that they can actually make tools by modifying sticks they find, so that they suit their needs. Obviously they can have ideas on their minds to pursuit particular goals, and some animals can think "around corners" to get there. Cats can learn that a door opens when you push down the handle just by observing humans doing it. But we must assume that their ideas are only representational, i.e. they can only think of things that you could draw. Monkeys may dream of oranges and bananas, but they surely can't grasp the idea of fruit. The crucial point here is that "fruit" is not a representational idea, but an abstract one. You cannot draw an image of fruit. You can draw oranges, bananas, and as many different kinds of fruit as you like, but the picture will never express the whole of the abstraction "fruit". Abstractions are not about multitudes of things, but about properties that these multitudes have in common. Now, the only way to think in abstractions seems to be human language. It allows to understand the past, at least vaguely anticipate the future, and it gave rise to art and science by the sheer power of non-representational thinking. Language doesn't just increase the comprehension of the world, but puts it on a whole new level. (BTW, in German there are two different words for these capabilities: representational reason is called "Verstand", non-representational reason "Vernunft") Programming languages are different. The don't abstract from the machine level. If you know fruit, you still know oranges and bananas, but if you know only Java, you might have no idea of what is going on at machine level, i.e. what a call stack is, how parameters are passed around, why an infinite recursion will crash the program instead of just running forever like an infinite loop. High level programming languages don't want you to get an overall understanding of how computers work, but their goal is that you can write programs without fully understanding what is going on inside the box. Whether this is a good or a bad thing depends on your point of view. If you want to write portable code, it's just what you need. Programming languages want to get rid of ambiguities and be as precise as possible. On the other hand, in the process of abstracting common properties out of a multitude of things in the case of a natural language, you must accept ambiguities to some extent. Programming languages can be precise only because they are *not* like natural languages. The fact that we use the expression "programming language" illustrates a feature of natural language to group things under the term "language" just because they have some things in common. In programming this would be like treating all variable types as bit arrays, which isn't a good idea, because then the compiler couldn't help you to find mistakes by enforcing type safety. In natural languages you can write poetry just because they are *not* like programming languages and often allow for completely different interpretations. 2 persons have voted this message useful | ||||||
| DaraghM Diglot Senior Member Ireland Joined 6153 days ago 1947 posts - 2923 votes Speaks: English*, Spanish Studies: French, Russian, Hungarian | Message 18 of 20 11 January 2010 at 12:17pm | IP Logged | |||||
This raises one of the greatest challenges in designing an application. How do you translate the imprecise real language, into the concrete programming language ? Can the language the functional spec is written in affect the final code ? Aside questions: Do Russian programmers have to use the Latin alphabet ? Has anyone else had to modify code written in a non-native language ? - A long time ago, I worked on an application where all the comments, and all the variable declarations, were in Swedish. This was not easy. 1 person has voted this message useful | ||||||
| numerodix Trilingual Hexaglot Senior Member Netherlands Joined 6785 days ago 856 posts - 1226 votes Speaks: EnglishC2*, Norwegian*, Polish*, Italian, Dutch, French Studies: Portuguese, Mandarin | Message 19 of 20 11 January 2010 at 12:35pm | IP Logged | |||||
This is a software engineering problem. Natural language as we like to use it is not precise, it's not thorough. We say many things that are vague. This is not sufficient for a specification. In the course of "translating" (as you say) this into more formal language, it occurs that many things are not stated unambiguously, many small decisions need still be made. You can say something that you think needs no further clarification, like "Here should have an input field for the user's name". But that's not sufficient for a spec. We need to know how does the application handle names? Do we have first name + last name? What about middle names? What about compound last names like Smith-Johnson? Are they stored as one name or separately? What about things like "Andy van der Meyde"? How do we divide that up into first and last name? What about Chinese names, do we support Chinese characters? How do we handle first name/last name in that case? Any small thing like that can become ridiculously complicated the more precise and accurate you want to be.
That goes without saying. A spec should even have a glossary that explains the meaning of the terms specifically as used in this document. That means you shouldn't even necessarily trust common words to be understood the same way by all readers of the spec. Edited by numerodix on 11 January 2010 at 12:36pm 1 person has voted this message useful | ||||||
| zooplah Diglot Senior Member United States zooplah.farvista.net Joined 6370 days ago 100 posts - 116 votes Speaks: English*, Esperanto Studies: German | Message 20 of 20 20 January 2010 at 11:56pm | IP Logged | |||||
I don't know. I think Pascal/Object Pascal tends to be smaller than C/C++. C/C++ uses funky symbols, but is quite verbose in some operations. Even more verbose is Java: public static void MyMethod(...) public static Integer Method2(...) 1 person has voted this message useful |
If you wish to post a reply to this topic you must first login. If you are not already registered you must first register
|  | 
Printable version
|
| Copyright 2024 FX Micheloud - All rights reserved No part of this website may be copied by any means without my written authorization. |
