As someone who worked on a 35 million loc cobol and jcl system for several years in the late 90's, I don't find this to be funny at all. Cobol was purported to be readable with english language like syntax to make it more understandable. Giving gems such as: MULTIPLY TAX-RATE OF STATE(43) BY BALANCE GIVING SALES-TAX-AMOUNT. Note the period is sigificant.
It's actually a pretty interesting question why programming languages that work like that are a bad idea. From decades of experience, I know intuitively that they are, but I find myself unable to formulate a concise description of what exactly is wrong with this approach.
The English Programming Language
31–40 of 78 posts
Re: The English Programming Language
#32Earlier quoted context omitted.
It's actually a pretty interesting question why programming languages that work like that are a bad idea. From decades of experience, I know intuitively that they are, but I find myself unable to formulate a concise description of what exactly is wrong with this approach.
Too much ambiguity that needs a large amount of context to resolve.
In fact, given that this is how all the languages that humans are already familiar with work, it's hard to see why this wouldn't be the best approach for constructing a programming language.
Re: The English Programming Language
#33Earlier quoted context omitted.
I have no doubt English like syntax is a terrible idea but this seems like a surprisingly readable example.
Agreed, I rather like this line of code, but I must admit that the C-like version is perhaps better: sales_tax_amount = balance * state[42].tax_rate; (Assuming I've guessed the meaning of the Cobol correctly - perhaps that's the rub.) (ETA: Added semicolon.) (ETA2: Fixed critical indexing bug.)
Note the semicolon is significant. Barbaric, I know.
Re: The English Programming Language
#34Earlier quoted context omitted.
Before jumping in with both feet, please check out the ALTER statement. GOTO on steroids and more.
> The ALTER statement changes the transfer point specified in a GO TO statement. What could go wrong?
I am altering the data. Pray I do not alter it further.Re: The English Programming Language
#35> English is used on more than 1,456 million carbon-based devices The aliens are going to find this and use humans as their computers
Re: The English Programming Language
#36As someone who worked on a 35 million loc cobol and jcl system for several years in the late 90's, I don't find this to be funny at all. Cobol was purported to be readable with english language like syntax to make it more understandable. Giving gems such as: MULTIPLY TAX-RATE OF STATE(43) BY BALANCE GIVING SALES-TAX-AMOUNT. Note the period is sigificant.
The first pitfall of using english as a programming language that occurs to me (as a totally Cobol ignorant person):
* Human languages tend to be nebulous around the edges and fluid, often with single word taking up multiple meanings and same function done by multiple words. There are multiple ways to express the same concept. This allows for the language to change and evolve with the times.
* OTOH programming languages need to be specific and exact for the computer to be able to interpret it and ensure it functions as expected across devices and over time.
This means to make English function as a programming language, we will have to take the existing language, whittle down most of the senses and many words, assign one function to one word and use a very trimmed down and reduced version of English.
Now you will have to know two forms of English * The human one * The computer-compatible one
Worse, our human version of the language can often trip up our computer-compatible one. I imagine even debugging would be harder, because when you look into the code, the brain would see perfectly good english and not register any issue with punctuation or tokens as expected by the interpreter.
Consider the below version.
MULTIPLY TAXRATE FROM STATE(43) WITH BALANCE GIVING SALES-TAX-AMOUNT.
I have made 3 changes here, which might or might not work with COBOL (I am Cobol ignorant ;) ).
But if a person tries to find the changes or debug, it would difficult for the human brain to register what is wrong as this is perfectly good english.Re: The English Programming Language
#37Earlier quoted context omitted.
Too much ambiguity that needs a large amount of context to resolve.
But why is that a problem? That's literally how we speak every single day. In fact, given that this is how all the languages that humans are already familiar with work, it's hard to see why this wouldn't be the best approach for constructing a programming language.
- humans can ask back questions to clarify any ambiguity; computers don't have the capacity to understand ambiguity, let alone asking for clarification.
- computers are trusted to work w/o failure almost 100% of the time. humans err (to be human is to err, anyway), so we'd never put a human in charge of critical things we use computers for.
Re: The English Programming Language
#38As someone who worked on a 35 million loc cobol and jcl system for several years in the late 90's, I don't find this to be funny at all. Cobol was purported to be readable with english language like syntax to make it more understandable. Giving gems such as: MULTIPLY TAX-RATE OF STATE(43) BY BALANCE GIVING SALES-TAX-AMOUNT. Note the period is sigificant.
It's actually a pretty interesting question why programming languages that work like that are a bad idea. From decades of experience, I know intuitively that they are, but I find myself unable to formulate a concise description of what exactly is wrong with this approach.
Re: The English Programming Language
#39As someone who worked on a 35 million loc cobol and jcl system for several years in the late 90's, I don't find this to be funny at all. Cobol was purported to be readable with english language like syntax to make it more understandable. Giving gems such as: MULTIPLY TAX-RATE OF STATE(43) BY BALANCE GIVING SALES-TAX-AMOUNT. Note the period is sigificant.
It's actually a pretty interesting question why programming languages that work like that are a bad idea. From decades of experience, I know intuitively that they are, but I find myself unable to formulate a concise description of what exactly is wrong with this approach.