Aide pour un programme langage c
-
From a factual point of view, you are perfectly right. Nevertheless, I disklike the fact. It does express a kind of cultural imperialism, which I think is without justification. There has been attempts - usually unsuccessful - to allow people to express their problem solutions in their own language. Algol68 was specified in abstract language tokens, and there was made at least one compiler with all keywords in German. In my student days, we made a preprocessor for Pascal replacing Norwegian (actually 'Nynorsk' - the south-west dialect-based variant of Norwegian) into the English equivalent before forwarding the source to the standard compiler. It was rather primitive, translating even words in string constants ... Some applications were 'localized', including their script languages. For a number of versions, Excel formulas were stored with localized function names, so a sheet could not be moved to an Excel instance of a different locale. My hope (but I am not very optimistic!) is that all application programming will move over to an abstract representation where the language form is merely a display phenomenon; the program itself is stored in an abstract, language independent form. For keywords, this is simple, but it would require a mechanism where code maintainers could assign alternate, language dependent tokens for programmer assigned names of variables, methods, constants, comments, ... In application development, the great majority of your communication is done in the local language. Communication with users and co-developers would benefit greatly from using the language that they all master the best. This also includes solution examples, in the form of program code. For core software, such as operating systems, maybe compilers, we may use English sort of as an 'assembly language' - low level stuff of no interest to the everyday programmer or customer. And, just as different CPUs have different instruction sets, if an OS is programmed in a German-based language, it shouldn't bother anyone any more than X64 instruction set extensions. You are left with the problem when you ask for help from someone who knows nothing but English. The helper may see your code in English terms, but incapable of understanding your problem statement. Maybe you will have to ask someone who speaks your language - and if programming in your native language is common, they may be readily available. And they are far more likely to see the application in the right cultural context, well familiar with aspects suc
You post something that should be an article, not as a mere comment.
trønderen wrote:
From a factual point of view, you are perfectly right.
Well, I'm never wrong..
trønderen wrote:
In application development, the great majority of your communication is done in the local language
I only work in English, all comments in code are in Engrish, and all documentation is. Never, ever, do I code in the local language, as no dog is ever gonna learn Dutch just for maintaining a code base. Ever.
trønderen wrote:
rather than assuming that the U.S. interpretation is globally valid.
They stuck with Fahrenheits and inches.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Some languages do not have words for concepts that exist in other languages. You're adding to a problem with a "universal language interpreter", not solving it.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Gerry Schmitz wrote:
Some languages do not have words for concepts that exist in other languages.
That's called evolving.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
From a factual point of view, you are perfectly right. Nevertheless, I disklike the fact. It does express a kind of cultural imperialism, which I think is without justification. There has been attempts - usually unsuccessful - to allow people to express their problem solutions in their own language. Algol68 was specified in abstract language tokens, and there was made at least one compiler with all keywords in German. In my student days, we made a preprocessor for Pascal replacing Norwegian (actually 'Nynorsk' - the south-west dialect-based variant of Norwegian) into the English equivalent before forwarding the source to the standard compiler. It was rather primitive, translating even words in string constants ... Some applications were 'localized', including their script languages. For a number of versions, Excel formulas were stored with localized function names, so a sheet could not be moved to an Excel instance of a different locale. My hope (but I am not very optimistic!) is that all application programming will move over to an abstract representation where the language form is merely a display phenomenon; the program itself is stored in an abstract, language independent form. For keywords, this is simple, but it would require a mechanism where code maintainers could assign alternate, language dependent tokens for programmer assigned names of variables, methods, constants, comments, ... In application development, the great majority of your communication is done in the local language. Communication with users and co-developers would benefit greatly from using the language that they all master the best. This also includes solution examples, in the form of program code. For core software, such as operating systems, maybe compilers, we may use English sort of as an 'assembly language' - low level stuff of no interest to the everyday programmer or customer. And, just as different CPUs have different instruction sets, if an OS is programmed in a German-based language, it shouldn't bother anyone any more than X64 instruction set extensions. You are left with the problem when you ask for help from someone who knows nothing but English. The helper may see your code in English terms, but incapable of understanding your problem statement. Maybe you will have to ask someone who speaks your language - and if programming in your native language is common, they may be readily available. And they are far more likely to see the application in the right cultural context, well familiar with aspects suc
Aight, my turn, and I'll provide justification. I'm a non English native, but all documentation is in English. It has nothing to do with imperialism, it's just the ring that binds us all. Engrish is simple to learn, and as such it became the language of documentation. So. If you want to code, you better learn English and not French. As for your Frenchies, I do not take your questions into consideration if you cannot speak English. Any code written containing French isn't worth the time. Or simpeler, I'd delete it :) Ctrl A. delete.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Gerry Schmitz wrote:
Some languages do not have words for concepts that exist in other languages.
That's called evolving.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
That's what I said: no common base.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Some languages do not have words for concepts that exist in other languages. You're adding to a problem with a "universal language interpreter", not solving it.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Gerry Schmitz wrote:
Some languages do not have words for concepts that exist in other languages
That is certainly not limited to programming languages! It is a general problem for any translator of natural languages. From an end user point of view, you can expect the user to have the required terms in his language. If English (i.e. the programming language) lacks the ability to express the problem concepts, then that is a problem belonging to the programming language, not to the problem solution as experienced by the customer / end user. You simply cannot go to a custormer and say: Sorry, mate, your suggested solution is perfectly fine, but we cannot use it, because the English language doesn't have words for those concepts! We have to solve the problem in a different way! When programming in a high level language, you will almost always make use of concepts that do not exist in machine code. Even a 'high level machine code', such as .net CIL, lacks a lot of higher concepts. Yet you can express a problem solution that can be handled in CIL. You can even express problem solutions in lots of different languages, and they can all be handled by CIL! Or moving yet another level up: With the GNU Compiler Collection, each source language - which on the surface may be quite different from other source languages - are parsed down to a parse tree, a format common to all languages. And then: I never was considering any "universal language interpreter". You need not lump everything from lisp to Algol68 to APL to Erlang into one single structure to get away from programming being forced to be done in English. Different languages have different uses; that should be maintained. It is sufficient that the standard representation of a language such as C# used abstract tokens: Rather than 'w', 'h', 'i', 'l', 'e' in a 7-bit-ASCII-file (you still see that a lot of places!), the representation is [while loop], which can be displayed in various languages. A variable reference is not coded as 't', 'o', 't', 'a', 'l', '_', 's', 'u', 'm', but as [variable 277], which may be assigned the external identifier 'total_sum' for English, and 'totalbeløp' for Norwegian presentation. I frequently get the feeling that we programmers actively want our code to be unintelligible for the customer (and for that sake, for other programmers of a different clan), so that we maintain full control over it. We do not ask the customer for his opinion about how the problem ca
-
You post something that should be an article, not as a mere comment.
trønderen wrote:
From a factual point of view, you are perfectly right.
Well, I'm never wrong..
trønderen wrote:
In application development, the great majority of your communication is done in the local language
I only work in English, all comments in code are in Engrish, and all documentation is. Never, ever, do I code in the local language, as no dog is ever gonna learn Dutch just for maintaining a code base. Ever.
trønderen wrote:
rather than assuming that the U.S. interpretation is globally valid.
They stuck with Fahrenheits and inches.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Eddy Vluggen wrote:
Never, ever, do I code in the local language, as no dog is ever gonna learn Dutch just for maintaining a code base. Ever.
My idea of a token-style representation of a program is that noone should have to learn Dutch for maintaining your code base. If all they master is English, then the tokens are mapped to their English representation for that programmer. You map the tokens to Dutch when discussing the solution with your Dutch customer. Or to German if the customer (or end user) is German. The idea is not having to learn a different language. Not even English.
-
Aight, my turn, and I'll provide justification. I'm a non English native, but all documentation is in English. It has nothing to do with imperialism, it's just the ring that binds us all. Engrish is simple to learn, and as such it became the language of documentation. So. If you want to code, you better learn English and not French. As for your Frenchies, I do not take your questions into consideration if you cannot speak English. Any code written containing French isn't worth the time. Or simpeler, I'd delete it :) Ctrl A. delete.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Eddy Vluggen wrote:
So. If you want to code, you better learn English and not French.
My concern is not that I have to master English (I guess I do master it far above the level required for programming), but the customer / end user. We programmers have a tendency to lock ourselves up in an ivory tower, where we want to lock the door and work in total isolation (although maybe as a programming team, not as individuals), most certainly isolated from the customer and the users. We refuse to communicate with anyone that doesn't master our tribal language to perfection. I think this is very bad for our profession. We have a lot to learn from those who have the problems/tasks that we are trying to solve. They do not speak our tribal language. We have to speak their language.
-
From a factual point of view, you are perfectly right. Nevertheless, I disklike the fact. It does express a kind of cultural imperialism, which I think is without justification. There has been attempts - usually unsuccessful - to allow people to express their problem solutions in their own language. Algol68 was specified in abstract language tokens, and there was made at least one compiler with all keywords in German. In my student days, we made a preprocessor for Pascal replacing Norwegian (actually 'Nynorsk' - the south-west dialect-based variant of Norwegian) into the English equivalent before forwarding the source to the standard compiler. It was rather primitive, translating even words in string constants ... Some applications were 'localized', including their script languages. For a number of versions, Excel formulas were stored with localized function names, so a sheet could not be moved to an Excel instance of a different locale. My hope (but I am not very optimistic!) is that all application programming will move over to an abstract representation where the language form is merely a display phenomenon; the program itself is stored in an abstract, language independent form. For keywords, this is simple, but it would require a mechanism where code maintainers could assign alternate, language dependent tokens for programmer assigned names of variables, methods, constants, comments, ... In application development, the great majority of your communication is done in the local language. Communication with users and co-developers would benefit greatly from using the language that they all master the best. This also includes solution examples, in the form of program code. For core software, such as operating systems, maybe compilers, we may use English sort of as an 'assembly language' - low level stuff of no interest to the everyday programmer or customer. And, just as different CPUs have different instruction sets, if an OS is programmed in a German-based language, it shouldn't bother anyone any more than X64 instruction set extensions. You are left with the problem when you ask for help from someone who knows nothing but English. The helper may see your code in English terms, but incapable of understanding your problem statement. Maybe you will have to ask someone who speaks your language - and if programming in your native language is common, they may be readily available. And they are far more likely to see the application in the right cultural context, well familiar with aspects suc
trønderen wrote:
For keywords, this is simple, but it would require a mechanism where code maintainers could assign alternate, language dependent tokens for programmer assigned names of variables, methods, constants, comments,
I would say...no. First, at least last time I created a compiler much less studied compilers it is not "simple" to replace keywords. Second the latter part of that statement seems to suggest exactly the problem that compilers need to solve with the first part of what I said. Compilers (and interpreters) already convert key words into tokens. Those that do not are very inefficient (as I know since I had to work with one long ago.)
trønderen wrote:
I think the global software culture would be enrichened if we could disengage from the absolute binding to the English-speaking culture.
No as you already pointed out prior to that. Most discussion about what the software does happens in a natural language. Very likely in the vast majority of cases a single natural language. Requirements, Architecture, Design are all in that natural language. All of those have much more impact on the solution than the actual code itself. Significant failures do not happen at the code level. They happen due to a failure in the above processes. Such as the failure with the Mars Climate Observer. The specifications were exact and numerical (which is universal). The communication was not.
-
Gerry Schmitz wrote:
Some languages do not have words for concepts that exist in other languages
That is certainly not limited to programming languages! It is a general problem for any translator of natural languages. From an end user point of view, you can expect the user to have the required terms in his language. If English (i.e. the programming language) lacks the ability to express the problem concepts, then that is a problem belonging to the programming language, not to the problem solution as experienced by the customer / end user. You simply cannot go to a custormer and say: Sorry, mate, your suggested solution is perfectly fine, but we cannot use it, because the English language doesn't have words for those concepts! We have to solve the problem in a different way! When programming in a high level language, you will almost always make use of concepts that do not exist in machine code. Even a 'high level machine code', such as .net CIL, lacks a lot of higher concepts. Yet you can express a problem solution that can be handled in CIL. You can even express problem solutions in lots of different languages, and they can all be handled by CIL! Or moving yet another level up: With the GNU Compiler Collection, each source language - which on the surface may be quite different from other source languages - are parsed down to a parse tree, a format common to all languages. And then: I never was considering any "universal language interpreter". You need not lump everything from lisp to Algol68 to APL to Erlang into one single structure to get away from programming being forced to be done in English. Different languages have different uses; that should be maintained. It is sufficient that the standard representation of a language such as C# used abstract tokens: Rather than 'w', 'h', 'i', 'l', 'e' in a 7-bit-ASCII-file (you still see that a lot of places!), the representation is [while loop], which can be displayed in various languages. A variable reference is not coded as 't', 'o', 't', 'a', 'l', '_', 's', 'u', 'm', but as [variable 277], which may be assigned the external identifier 'total_sum' for English, and 'totalbeløp' for Norwegian presentation. I frequently get the feeling that we programmers actively want our code to be unintelligible for the customer (and for that sake, for other programmers of a different clan), so that we maintain full control over it. We do not ask the customer for his opinion about how the problem ca
trønderen wrote:
I frequently get the feeling that we programmers actively want our code to be unintelligible for the customer...I think we ought to.
It has been tried. On large scale and small. And it continues to be tried. But it does not work. I repeatedly run into feature discussions where there claim is made that it must support complex scenarios but must also be 'simple' enough for users to understand it. That has resulted in in the following real cases. 1. Customer is now responsible for learning a programming language and providing programmers for it. Different projects required C#, Java and even a variation (and not a good one) of C. (The solution requires them to write code, application compiles it and dynamically injects it into the application.) 2. Solution is provided that does not provide full functionality for the actual known more complex cases. The customer is told they cannot have that feature. There is always a point where one reaches that the complexity of the allowed solution requires specialized knowledge and training just to achieve the task. Thus no matter how one wraps it up there must always be a 'programmer'.
trønderen wrote:
it could even be possible to discuss the code with a customer who is not fluent in English!
But only if they can program. And except for algorithm discussions they would also need to be a programmer in the language you are discussing.
-
trønderen wrote:
For keywords, this is simple, but it would require a mechanism where code maintainers could assign alternate, language dependent tokens for programmer assigned names of variables, methods, constants, comments,
I would say...no. First, at least last time I created a compiler much less studied compilers it is not "simple" to replace keywords. Second the latter part of that statement seems to suggest exactly the problem that compilers need to solve with the first part of what I said. Compilers (and interpreters) already convert key words into tokens. Those that do not are very inefficient (as I know since I had to work with one long ago.)
trønderen wrote:
I think the global software culture would be enrichened if we could disengage from the absolute binding to the English-speaking culture.
No as you already pointed out prior to that. Most discussion about what the software does happens in a natural language. Very likely in the vast majority of cases a single natural language. Requirements, Architecture, Design are all in that natural language. All of those have much more impact on the solution than the actual code itself. Significant failures do not happen at the code level. They happen due to a failure in the above processes. Such as the failure with the Mars Climate Observer. The specifications were exact and numerical (which is universal). The communication was not.
jschell wrote:
trønderen wrote:For keywords, this is simple, but it would require a mechanism where code maintainers could assign alternate, language dependent tokens for programmer assigned names of variables, methods, constants, comments, I would say...no.
Or perhaps yes. Many years ago, when I was just starting university, the community college had a very old (even then) IBM mini. I don't recall the model number, but it was somewhat larger than an "executive" office desk, with a disc-pac to one side, and one of those 7 foot tall chain-driven line printers to the other. It might have been something from the 1400 series: [IBM 1400 series - Wikipedia](https://en.wikipedia.org/wiki/IBM\_1400\_series) I think the instructor said that he knew of one other example of that model of computer, but it was in a museum! Anyway, we used that computer to learn Algol and Fortran. The Algol compiler was written somewhere like McGill university, in Quebec. As such, I seem to recall that the keywords were bi-lingual, you could use either English or French. So either if or si. But the error messages were all in French. So maybe at the time the requirement that we take first year French wasn't so pointless after all. Maybe it was written in Paris: [https://dl.acm.org/doi/pdf/10.1145/872738.807150\](https://dl.acm.org/doi/pdf/10.1145/872738.807150) See note about bilingual details on P113
Keep Calm and Carry On
-
jschell wrote:
trønderen wrote:For keywords, this is simple, but it would require a mechanism where code maintainers could assign alternate, language dependent tokens for programmer assigned names of variables, methods, constants, comments, I would say...no.
Or perhaps yes. Many years ago, when I was just starting university, the community college had a very old (even then) IBM mini. I don't recall the model number, but it was somewhat larger than an "executive" office desk, with a disc-pac to one side, and one of those 7 foot tall chain-driven line printers to the other. It might have been something from the 1400 series: [IBM 1400 series - Wikipedia](https://en.wikipedia.org/wiki/IBM\_1400\_series) I think the instructor said that he knew of one other example of that model of computer, but it was in a museum! Anyway, we used that computer to learn Algol and Fortran. The Algol compiler was written somewhere like McGill university, in Quebec. As such, I seem to recall that the keywords were bi-lingual, you could use either English or French. So either if or si. But the error messages were all in French. So maybe at the time the requirement that we take first year French wasn't so pointless after all. Maybe it was written in Paris: [https://dl.acm.org/doi/pdf/10.1145/872738.807150\](https://dl.acm.org/doi/pdf/10.1145/872738.807150) See note about bilingual details on P113
Keep Calm and Carry On
Algol68 was explicitly defined for adaptation to different languages: The syntax was defined using abstract tokens that could be mapped to various sets of concrete tokens. This is no more difficult than having a functional API definition with mappings to C++, PHP, Fortran, Java, ... Obviously, to define these mappings, you should both thoroughly understand the API, and of course the language you are mapping to. It is not always a trivial thing to do. When you choose concrete tokens for a programming language, it is not something that you do a Friday night over a few beers. It is professional work, where you must know the semantics of those abstract tokens, and you must know the natural language from which you select your keywords. You must be just as careful when selecting a term as the English-speaking language designers when they select their English terms. If the language defines some tokens as reserved, you must honor that even for your alternate concrete mapping. In your French Algol version, I assume that the source code was maintained in a plain text file (probably in EBCDIC, for IBM in those days), handled by the editor of your choice. Switching between English and French would require a textual replacement. If the source code was rather stored as abstract tokens, maybe even as a syntax tree, it would require an editor specifically made for this format. (Note that you could still have an selection of editors for the same format!) The editor might choose to look up the concrete syntax only for that part of the tree that is at the moment displayed on screen. 'Translation' is done by redrawing the screen, using another table of concrete symbols. This is certainly extremely difficult, probably across the borderline to the impossible, if we insist on thinking along exactly the same tracks as we have always done before, refusing to change our ways even a tiny little bit. I sure can agree that it is fully possible to construct obstacles for preventing any sort of change in our ways of thinking. I am not hunting for that kind. Like you, k5054, I observe that 'It happens, so it must be possible'.
-
trønderen wrote:
For keywords, this is simple, but it would require a mechanism where code maintainers could assign alternate, language dependent tokens for programmer assigned names of variables, methods, constants, comments,
I would say...no. First, at least last time I created a compiler much less studied compilers it is not "simple" to replace keywords. Second the latter part of that statement seems to suggest exactly the problem that compilers need to solve with the first part of what I said. Compilers (and interpreters) already convert key words into tokens. Those that do not are very inefficient (as I know since I had to work with one long ago.)
trønderen wrote:
I think the global software culture would be enrichened if we could disengage from the absolute binding to the English-speaking culture.
No as you already pointed out prior to that. Most discussion about what the software does happens in a natural language. Very likely in the vast majority of cases a single natural language. Requirements, Architecture, Design are all in that natural language. All of those have much more impact on the solution than the actual code itself. Significant failures do not happen at the code level. They happen due to a failure in the above processes. Such as the failure with the Mars Climate Observer. The specifications were exact and numerical (which is universal). The communication was not.
jschell wrote:
First, at least last time I created a compiler much less studied compilers it is not "simple" to replace keywords.
You certainly must know the semantics of the abstract token. And you must know the concrete language you want to use. This is not a job for Google Translate. But we are not talking about defining a new programming language; just modifying the symbol table used by the tokenizer. That is magnitudes simpler than making an all new compiler.
jschell wrote:
Second the latter part of that statement seems to suggest exactly the problem that compilers need to solve with the first part of what I said. Compilers (and interpreters) already convert key words into tokens. Those that do not are very inefficient (as I know since I had to work with one long ago.)
Quite to the contrary. If you store the source code by their abstract tokens, the result of the tokenizers job (and maybe even after a fundamental structure parsing), that heavy job you are referring to is done "once and for all". Or at least until the code is edited, but then a reparsing is required only for that substructure affected by the edit. Further compilation would be significantly faster, as much of the work is already done. We have had precompiled header files for many years. This is along the same lines, except that the pre-parsed code is the primary source representation, with a mapping back to ASCII symbols is only done for editing purposes, and only for that part of the code displayed to the programmer at the moment.
jschell wrote:
Requirements, Architecture, Design are all in that natural language. All of those have much more impact on the solution than the actual code itself.
In "a" natural language, yes. English. Far too often, the design language is English, even if the customer and end users have a different natural language. The norm is that in the very first input steps from the customer, the native language is used. Then the developers retract to their ivory tower to create The Solution, as they see it. First: Then it is back to English, and second: The ties to whatever was discussed with the customer is next to non-existing. The software structure is not a more detailed break-up of the boxes you showed the customer. The modules, functions, methods, data structure names are unrelated to the terms used in the discussion with the cu
-
trønderen wrote:
I frequently get the feeling that we programmers actively want our code to be unintelligible for the customer...I think we ought to.
It has been tried. On large scale and small. And it continues to be tried. But it does not work. I repeatedly run into feature discussions where there claim is made that it must support complex scenarios but must also be 'simple' enough for users to understand it. That has resulted in in the following real cases. 1. Customer is now responsible for learning a programming language and providing programmers for it. Different projects required C#, Java and even a variation (and not a good one) of C. (The solution requires them to write code, application compiles it and dynamically injects it into the application.) 2. Solution is provided that does not provide full functionality for the actual known more complex cases. The customer is told they cannot have that feature. There is always a point where one reaches that the complexity of the allowed solution requires specialized knowledge and training just to achieve the task. Thus no matter how one wraps it up there must always be a 'programmer'.
trønderen wrote:
it could even be possible to discuss the code with a customer who is not fluent in English!
But only if they can program. And except for algorithm discussions they would also need to be a programmer in the language you are discussing.
jschell wrote:
trønderen wrote:I frequently get the feeling that we programmers actively want our code to be unintelligible for the customer...I think we ought to.
Rather creative quoting you are doing there! I do not thing we ought to make "our code to be unintelligible for the customer"!
jschell wrote:
It has been tried. On large scale and small. And it continues to be tried. But it does not work.
I know of lots of end user 'macro' languages that exist in different language varieties; even system functions are localized. People with no programming background are capable of adapting applications to their own needs without having to learn English. It certainly works in the small. I do not know of any compiler storing the code as a semi-parsed tree of abstract tokens, applying a concrete syntax only in the presentation for a human developer. I am simply unfamiliar with any other large-scale failed try to localize any tool, whether programming tool or tool for other application areas, where a significant deployment of localized versions was pulled back and replaced with English language versions. If you can point to one example of failure: One failed project does not imply that the principle has no merit. If you are eager to 'prove' that English Is The Answer, you may of course justify you attitude by referring to the failure. Otherwise, you may study the failure to learn why it failed, and what could be done in better ways. An example: The first release of localized Excel formulas did localize function names. In multi-language corporations, you could not share a spreadsheet between those working in an English context with those in a Norwegian context - the function names from the 'other' language were not found. In your approach, it seems like the proper solution would be to force everyone back to English. Rather, a later Excel version replaced the internal representation of system functions (which was by the localized name) with an abstract reference, sort of like 'built-in 37', which was displayed as 'average' in English versions, 'gjennomsnitt' in Norwegian versions. (In a spreadsheet, 'variables' are referenced by row and column, so the problem of localized variable names does not occur.)
jschell wrote:
it could even be possible to discuss the code with a customer who is not fluent in English!
-
Aight, my turn, and I'll provide justification. I'm a non English native, but all documentation is in English. It has nothing to do with imperialism, it's just the ring that binds us all. Engrish is simple to learn, and as such it became the language of documentation. So. If you want to code, you better learn English and not French. As for your Frenchies, I do not take your questions into consideration if you cannot speak English. Any code written containing French isn't worth the time. Or simpeler, I'd delete it :) Ctrl A. delete.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
Eddy Vluggen wrote:
Engrish is simple to learn
I wish you'd tell some Brits that! :laugh: (Many "native" English speakers ... don't. At least not half as well as most non-native speakers.)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Gerry Schmitz wrote:
Some languages do not have words for concepts that exist in other languages
That is certainly not limited to programming languages! It is a general problem for any translator of natural languages. From an end user point of view, you can expect the user to have the required terms in his language. If English (i.e. the programming language) lacks the ability to express the problem concepts, then that is a problem belonging to the programming language, not to the problem solution as experienced by the customer / end user. You simply cannot go to a custormer and say: Sorry, mate, your suggested solution is perfectly fine, but we cannot use it, because the English language doesn't have words for those concepts! We have to solve the problem in a different way! When programming in a high level language, you will almost always make use of concepts that do not exist in machine code. Even a 'high level machine code', such as .net CIL, lacks a lot of higher concepts. Yet you can express a problem solution that can be handled in CIL. You can even express problem solutions in lots of different languages, and they can all be handled by CIL! Or moving yet another level up: With the GNU Compiler Collection, each source language - which on the surface may be quite different from other source languages - are parsed down to a parse tree, a format common to all languages. And then: I never was considering any "universal language interpreter". You need not lump everything from lisp to Algol68 to APL to Erlang into one single structure to get away from programming being forced to be done in English. Different languages have different uses; that should be maintained. It is sufficient that the standard representation of a language such as C# used abstract tokens: Rather than 'w', 'h', 'i', 'l', 'e' in a 7-bit-ASCII-file (you still see that a lot of places!), the representation is [while loop], which can be displayed in various languages. A variable reference is not coded as 't', 'o', 't', 'a', 'l', '_', 's', 'u', 'm', but as [variable 277], which may be assigned the external identifier 'total_sum' for English, and 'totalbeløp' for Norwegian presentation. I frequently get the feeling that we programmers actively want our code to be unintelligible for the customer (and for that sake, for other programmers of a different clan), so that we maintain full control over it. We do not ask the customer for his opinion about how the problem ca
I found that if I deliver software that "I would like to use", it never fails to please. I also write in such a way, that I don't need to create help files. If I needed something, a video screen capture would be all that was needed; perhaps 10 minutes. As for "communicating", I learn the users job, and lingo, to the point I can do it. In English. No new languages were created. (And the end user doesn't care what "coding" language I use; as long as they're happy) And I have no problem talking customers out of software and services, including my own, that they don't need.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Eddy Vluggen wrote:
Never, ever, do I code in the local language, as no dog is ever gonna learn Dutch just for maintaining a code base. Ever.
My idea of a token-style representation of a program is that noone should have to learn Dutch for maintaining your code base. If all they master is English, then the tokens are mapped to their English representation for that programmer. You map the tokens to Dutch when discussing the solution with your Dutch customer. Or to German if the customer (or end user) is German. The idea is not having to learn a different language. Not even English.
Adding an interpreter, adds another burden and potential failure point to the tool chain. Plus the requirement for an in-house local language to interpreter translator.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Eddy Vluggen wrote:
So. If you want to code, you better learn English and not French.
My concern is not that I have to master English (I guess I do master it far above the level required for programming), but the customer / end user. We programmers have a tendency to lock ourselves up in an ivory tower, where we want to lock the door and work in total isolation (although maybe as a programming team, not as individuals), most certainly isolated from the customer and the users. We refuse to communicate with anyone that doesn't master our tribal language to perfection. I think this is very bad for our profession. We have a lot to learn from those who have the problems/tasks that we are trying to solve. They do not speak our tribal language. We have to speak their language.
You're talking about an IT "shop"; individuals and smaller outfits wouldn't be able to function in the outside world with that attitude. The one thing that progress did, was create middle men (i.e. Business analysts) that separated user and "creator". A Technical Lead cannot be a lead without having interacted with the eventual users, IMO.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
jschell wrote:
trønderen wrote:I frequently get the feeling that we programmers actively want our code to be unintelligible for the customer...I think we ought to.
Rather creative quoting you are doing there! I do not thing we ought to make "our code to be unintelligible for the customer"!
jschell wrote:
It has been tried. On large scale and small. And it continues to be tried. But it does not work.
I know of lots of end user 'macro' languages that exist in different language varieties; even system functions are localized. People with no programming background are capable of adapting applications to their own needs without having to learn English. It certainly works in the small. I do not know of any compiler storing the code as a semi-parsed tree of abstract tokens, applying a concrete syntax only in the presentation for a human developer. I am simply unfamiliar with any other large-scale failed try to localize any tool, whether programming tool or tool for other application areas, where a significant deployment of localized versions was pulled back and replaced with English language versions. If you can point to one example of failure: One failed project does not imply that the principle has no merit. If you are eager to 'prove' that English Is The Answer, you may of course justify you attitude by referring to the failure. Otherwise, you may study the failure to learn why it failed, and what could be done in better ways. An example: The first release of localized Excel formulas did localize function names. In multi-language corporations, you could not share a spreadsheet between those working in an English context with those in a Norwegian context - the function names from the 'other' language were not found. In your approach, it seems like the proper solution would be to force everyone back to English. Rather, a later Excel version replaced the internal representation of system functions (which was by the localized name) with an abstract reference, sort of like 'built-in 37', which was displayed as 'average' in English versions, 'gjennomsnitt' in Norwegian versions. (In a spreadsheet, 'variables' are referenced by row and column, so the problem of localized variable names does not occur.)
jschell wrote:
it could even be possible to discuss the code with a customer who is not fluent in English!
trønderen wrote:
I do not thing we ought to make "our code to be unintelligible for the customer"!
I realize what you are saying.
trønderen wrote:
My old mother could not distinguish between a PC
I didn't claim people were stupid. I never do that. I disdain programmers that think users are stupid. But as I pointed out your idea is not new. COBOL was created with that in mind in that someone besides a programmer could read the code and more easily understand that. The problem however is still that to actually create an application which is complex the details/process requires that someone somewhere must still be a 'programmer'. And all attempts to move that out of the developer space either result is something that only supports simplistic examples or it requires that someone else (like a customer) must then become a 'developer.'
trønderen wrote:
I have been teaching '101 Programming' to people who had never before sat down at a computer
So you were teaching them to be programmers. Not users.
trønderen wrote:
I know that users with domain knowledge and experience are very good at understand even tiny little details in a computer solution, if you are willing to listen to them when they tell you something and try to talk in a similar language when you explain your proposals to them.
I have written requirements for entire systems based on user/customer requests. Designed architectures and designs to meet the needs as they describe. While leading them through the process of not only describing what they want and need but also picking through the parts that they understand but have not verbalized such as (the very common need) of how to handle failure scenarios. But I do that so they can focus on what they do best while others (developers) focus on what they do best.
-
I found that if I deliver software that "I would like to use", it never fails to please. I also write in such a way, that I don't need to create help files. If I needed something, a video screen capture would be all that was needed; perhaps 10 minutes. As for "communicating", I learn the users job, and lingo, to the point I can do it. In English. No new languages were created. (And the end user doesn't care what "coding" language I use; as long as they're happy) And I have no problem talking customers out of software and services, including my own, that they don't need.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Gerry Schmitz wrote:
I have no problem talking customers out of software and services, including my own, that they don't need.
My understanding now however is that... Customers need applications to do certain tasks. From the service provider point of view you must provide that so they continue to be a customer. Customers want applications to do certain tasks. From the service provider point of view you must provide that so they become a customer. The two might overlap but certainly sometimes they do not.
-
Gerry Schmitz wrote:
I have no problem talking customers out of software and services, including my own, that they don't need.
My understanding now however is that... Customers need applications to do certain tasks. From the service provider point of view you must provide that so they continue to be a customer. Customers want applications to do certain tasks. From the service provider point of view you must provide that so they become a customer. The two might overlap but certainly sometimes they do not.
Quote:
Customers need applications to do certain tasks. From the service provider point of view you must provide that so they continue to be a customer.
The customer who wants an applications to do certain tasks is "wrong". They tell me what they "need", and I tell them what "tasks" the application will perform, if any. e.g. (1.) "We send sports statistics for evaluation and reports". It is very slow and we need you to write a new app to speed up the process. All they needed to do was zip the files. (True story). (2.) Streamlining a law office. I sent them happily off using SharePoint Online subscriptions. § You're suggesting you would write them a redundant app and take the money ... because "I must provide it, etc." Not for me you don't.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
