Building a new proper left-to-right executing programming language
-
Most of spoken languages are written LtR (Left-to-Right) but Maths, the number language, is actually written RtL because the decimal numbers are Arabic numerals. (I know, most will get surprised, but it's true about Maths RtL direction.) But somehow the RtL and LtR languages got mixed up. Instead of writing
x = a + 12
how about changing it to
a + 12 = x
So, what are your views on creating a new programming language which follows proper LtR execution? Is there already such language? (Please, just don't remind me that there are already lots of programming languages (I know already) and I must not (try to) create one more. :) )
-
Most of spoken languages are written LtR (Left-to-Right) but Maths, the number language, is actually written RtL because the decimal numbers are Arabic numerals. (I know, most will get surprised, but it's true about Maths RtL direction.) But somehow the RtL and LtR languages got mixed up. Instead of writing
x = a + 12
how about changing it to
a + 12 = x
So, what are your views on creating a new programming language which follows proper LtR execution? Is there already such language? (Please, just don't remind me that there are already lots of programming languages (I know already) and I must not (try to) create one more. :) )
throw new InvalidPremiseException ( "ADD a AND 12 YIELDING x -- COBOL." ) ;
-
throw new InvalidPremiseException ( "ADD a AND 12 YIELDING x -- COBOL." ) ;
I just threw up in my mouth, a little. X|
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
Most of spoken languages are written LtR (Left-to-Right) but Maths, the number language, is actually written RtL because the decimal numbers are Arabic numerals. (I know, most will get surprised, but it's true about Maths RtL direction.) But somehow the RtL and LtR languages got mixed up. Instead of writing
x = a + 12
how about changing it to
a + 12 = x
So, what are your views on creating a new programming language which follows proper LtR execution? Is there already such language? (Please, just don't remind me that there are already lots of programming languages (I know already) and I must not (try to) create one more. :) )
It depends on who you are trying to communicate with. A computer or a programmer. From a computers perspective, if you want to model the execution steps, there is already a better language for this representation, reverse polish notation. (a 12 +) From a programmers perspective, you want the code to be easy to read and I don't see how your proposal assists this. - When reading code the variable being set is the most important. - If I'm trying to understand code, I'll want to understand where a var is set, this is easier to do by scanning a block where the variables are aligned. It is easier for my eyes to find the line x=..... rather than .....= x. - Following the logic of the algorithm would involve understanding where variables are mutated as much as what they are set to. - For complex expressions, I'll probably only read and understand them once, while I'll explore the looping logic and structure of the flow of the code more. 60 years ago, there was an economic value in a programmer spending significant time making things easier for the computer. Now, the value is in making things easier for the programmer, even if significantly more complex for the computer. I've always wanted languages to adopt a true assignment operator x <- a + 12. But it would need to be a single character and exist as an easily usable key on my keyboard. Interestingly, Visual Studio allows unicode variable names, so I've written software using genuine alpha and beta glyphs.
-
I just threw up in my mouth, a little. X|
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Because of the syntax error? :laugh:
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
-
It depends on who you are trying to communicate with. A computer or a programmer. From a computers perspective, if you want to model the execution steps, there is already a better language for this representation, reverse polish notation. (a 12 +) From a programmers perspective, you want the code to be easy to read and I don't see how your proposal assists this. - When reading code the variable being set is the most important. - If I'm trying to understand code, I'll want to understand where a var is set, this is easier to do by scanning a block where the variables are aligned. It is easier for my eyes to find the line x=..... rather than .....= x. - Following the logic of the algorithm would involve understanding where variables are mutated as much as what they are set to. - For complex expressions, I'll probably only read and understand them once, while I'll explore the looping logic and structure of the flow of the code more. 60 years ago, there was an economic value in a programmer spending significant time making things easier for the computer. Now, the value is in making things easier for the programmer, even if significantly more complex for the computer. I've always wanted languages to adopt a true assignment operator x <- a + 12. But it would need to be a single character and exist as an easily usable key on my keyboard. Interestingly, Visual Studio allows unicode variable names, so I've written software using genuine alpha and beta glyphs.
If you really want to program in RPN there is Forth. In my brief encounter with it I deemed it a write-only language. At least, there was Forth. I have not heard much of it many years.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
Most of spoken languages are written LtR (Left-to-Right) but Maths, the number language, is actually written RtL because the decimal numbers are Arabic numerals. (I know, most will get surprised, but it's true about Maths RtL direction.) But somehow the RtL and LtR languages got mixed up. Instead of writing
x = a + 12
how about changing it to
a + 12 = x
So, what are your views on creating a new programming language which follows proper LtR execution? Is there already such language? (Please, just don't remind me that there are already lots of programming languages (I know already) and I must not (try to) create one more. :) )
-
It depends on who you are trying to communicate with. A computer or a programmer. From a computers perspective, if you want to model the execution steps, there is already a better language for this representation, reverse polish notation. (a 12 +) From a programmers perspective, you want the code to be easy to read and I don't see how your proposal assists this. - When reading code the variable being set is the most important. - If I'm trying to understand code, I'll want to understand where a var is set, this is easier to do by scanning a block where the variables are aligned. It is easier for my eyes to find the line x=..... rather than .....= x. - Following the logic of the algorithm would involve understanding where variables are mutated as much as what they are set to. - For complex expressions, I'll probably only read and understand them once, while I'll explore the looping logic and structure of the flow of the code more. 60 years ago, there was an economic value in a programmer spending significant time making things easier for the computer. Now, the value is in making things easier for the programmer, even if significantly more complex for the computer. I've always wanted languages to adopt a true assignment operator x <- a + 12. But it would need to be a single character and exist as an easily usable key on my keyboard. Interestingly, Visual Studio allows unicode variable names, so I've written software using genuine alpha and beta glyphs.
Algol58 / 60 / 68 had an assignment operator which was (in the spec) a left facing arrow, but usually represent as := in implementations. We referred to it as the 'becomes' operator. The '=' was an equality operator. I do not know why K&R etc decided to use '=' as an assignment operator in C (a source of errors ever since, even in Yoda mode) even though C is ultimately derived from Algol; unless they wanted compatibility with FORTRAN (which uses .EQ. as its equality operator, so no ambiguity).
-
Most of spoken languages are written LtR (Left-to-Right) but Maths, the number language, is actually written RtL because the decimal numbers are Arabic numerals. (I know, most will get surprised, but it's true about Maths RtL direction.) But somehow the RtL and LtR languages got mixed up. Instead of writing
x = a + 12
how about changing it to
a + 12 = x
So, what are your views on creating a new programming language which follows proper LtR execution? Is there already such language? (Please, just don't remind me that there are already lots of programming languages (I know already) and I must not (try to) create one more. :) )
With the "programming" aspect of your post aside...
Nikunj_Bhatt wrote:
decimal numbers are Arabic numeral
I'm confused... what does this mean? How is a number (decimal or otherwise) specifically Arabic? (and therefore specifically RtL)
Nikunj_Bhatt wrote:
Maths, the number language, is actually written RtL
What do you mean by this? If I write a sum on a piece of paper, I would write:
1 + 2 = 3
-
With the "programming" aspect of your post aside...
Nikunj_Bhatt wrote:
decimal numbers are Arabic numeral
I'm confused... what does this mean? How is a number (decimal or otherwise) specifically Arabic? (and therefore specifically RtL)
Nikunj_Bhatt wrote:
Maths, the number language, is actually written RtL
What do you mean by this? If I write a sum on a piece of paper, I would write:
1 + 2 = 3
The numbers that we are using is the decimal numbers a.k.a. Arabic numerals. Here is the history of the numbers: Arabic numerals - Wikipedia[^]. The decimal numbers are called Arabic numbers because they were invented by Arabs (however Zero was invented in India, it is also part of Arabic numbers). So,
1 + 2 = 3
is a correct way in LtR while
3 = 1 + 2
is correct way according to RtL (Arabic, Hebew, etc. RtL languages, however this is now not used because of international Mathematics influence.)
-
It depends on who you are trying to communicate with. A computer or a programmer. From a computers perspective, if you want to model the execution steps, there is already a better language for this representation, reverse polish notation. (a 12 +) From a programmers perspective, you want the code to be easy to read and I don't see how your proposal assists this. - When reading code the variable being set is the most important. - If I'm trying to understand code, I'll want to understand where a var is set, this is easier to do by scanning a block where the variables are aligned. It is easier for my eyes to find the line x=..... rather than .....= x. - Following the logic of the algorithm would involve understanding where variables are mutated as much as what they are set to. - For complex expressions, I'll probably only read and understand them once, while I'll explore the looping logic and structure of the flow of the code more. 60 years ago, there was an economic value in a programmer spending significant time making things easier for the computer. Now, the value is in making things easier for the programmer, even if significantly more complex for the computer. I've always wanted languages to adopt a true assignment operator x <- a + 12. But it would need to be a single character and exist as an easily usable key on my keyboard. Interestingly, Visual Studio allows unicode variable names, so I've written software using genuine alpha and beta glyphs.
For the new language, I am thinking from programmers' perspective. The Reverse Polish Notation is good for computer but confusing for humans. Writing
a + 12 = xand finding where thevaris set - is looking confusing but we may find some solution(s), I haven't yet thought much about it yet. We may also find some unique way of defining variables which is not used in any programming language yet. The new proper LtR programming language idea came to mind to reduce code, faster parsing/compiling/execution, less code traversal. We may get used to the syntax if we practice more. -
Most of spoken languages are written LtR (Left-to-Right) but Maths, the number language, is actually written RtL because the decimal numbers are Arabic numerals. (I know, most will get surprised, but it's true about Maths RtL direction.) But somehow the RtL and LtR languages got mixed up. Instead of writing
x = a + 12
how about changing it to
a + 12 = x
So, what are your views on creating a new programming language which follows proper LtR execution? Is there already such language? (Please, just don't remind me that there are already lots of programming languages (I know already) and I must not (try to) create one more. :) )
I spent a few years programming in Planc - Programming LAnguage for Norsk data Computers. Fairly Pascal-like (plus a number of system programming features), but assignments were LtR, like: I + J =: K; (It also had the very useful swap assignment - if you wrote: newI =: I =: oldI; the newI would be assigned to both I and oldI, but if you rather used newI :=: I =: oldI; the assignment to I would carry the old value of I over to following assignment. So A :=: B =: A; is a full swap.) You could say that APL is strictly RtL: it has no operator priorities; you have to control all out-of-sequential-order calculations with parentheses. There are two ways to conceptualize this: If you like to work bottom-up, collect the small pieces into larger structures, finally being assigned to a variable, then you start at the right end and read to the left. The alternative is to do it top down, reading from left to right. All the special APL characters makes it difficult to give a true example, but to write it in a Pascal-like way: TotalCost := FixedCost + UnitCost * Amount1 + Amount2; TotalCost is assigned a new value, that's the top level. The value is a sum of a FixedCost and something else, what ever the details of the "something else" is. If you want those details, you read on to see a UnitCost multiplied by something, presumably a number of units. To see the details of how the number of units are calculated, you read to see that two amounts are added. The more details you want, the further you read. If you turn it the other way around, in a LtR language (Amount2 + Amount1) * UnitCost + FixedCost =: TotalCost; you start with two out-of-context amounts added together, but you really don't know for which purpose. You multiply it by a value, but there is still no indication of why. You add a FixedCost, but only at the very end of the statement do you realize what you are doing all this for! Top-Down design has been accepted in systems design, and even in code design, since the 1970s, but when we get down to real programming, we still insist on assembling small pieces without knowing the purpose of it. :-) I liked the Planc LtR style. But I also like the APL top-down-approach when reading it LtR. I agree that the current mainstream languages makes your attention jump back and forth; I would rather have the APL or Planc philosophy.
-
With the "programming" aspect of your post aside...
Nikunj_Bhatt wrote:
decimal numbers are Arabic numeral
I'm confused... what does this mean? How is a number (decimal or otherwise) specifically Arabic? (and therefore specifically RtL)
Nikunj_Bhatt wrote:
Maths, the number language, is actually written RtL
What do you mean by this? If I write a sum on a piece of paper, I would write:
1 + 2 = 3
musefan wrote:
I'm confused... what does this mean? How is a number (decimal or otherwise) specifically Arabic? (and therefore specifically RtL)
Our numbering system (and the number 0) are arabic inventions. Romans use a different system, and do not have a sign for nothing. Doesn't make the number itself an Arabic thing, only our current defacto way of encoding these.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Most of spoken languages are written LtR (Left-to-Right) but Maths, the number language, is actually written RtL because the decimal numbers are Arabic numerals. (I know, most will get surprised, but it's true about Maths RtL direction.) But somehow the RtL and LtR languages got mixed up. Instead of writing
x = a + 12
how about changing it to
a + 12 = x
So, what are your views on creating a new programming language which follows proper LtR execution? Is there already such language? (Please, just don't remind me that there are already lots of programming languages (I know already) and I must not (try to) create one more. :) )
Sure, do it. By the way TI-BASIC has an `->` operator for assignment, of course working left to right. And Smalltalk has left-to-right evaluation of operations instead of relying on operator precedence (which is initially confusing, but you don't have to remember the relative precedences of uncommon combinations of operators).
-
I spent a few years programming in Planc - Programming LAnguage for Norsk data Computers. Fairly Pascal-like (plus a number of system programming features), but assignments were LtR, like: I + J =: K; (It also had the very useful swap assignment - if you wrote: newI =: I =: oldI; the newI would be assigned to both I and oldI, but if you rather used newI :=: I =: oldI; the assignment to I would carry the old value of I over to following assignment. So A :=: B =: A; is a full swap.) You could say that APL is strictly RtL: it has no operator priorities; you have to control all out-of-sequential-order calculations with parentheses. There are two ways to conceptualize this: If you like to work bottom-up, collect the small pieces into larger structures, finally being assigned to a variable, then you start at the right end and read to the left. The alternative is to do it top down, reading from left to right. All the special APL characters makes it difficult to give a true example, but to write it in a Pascal-like way: TotalCost := FixedCost + UnitCost * Amount1 + Amount2; TotalCost is assigned a new value, that's the top level. The value is a sum of a FixedCost and something else, what ever the details of the "something else" is. If you want those details, you read on to see a UnitCost multiplied by something, presumably a number of units. To see the details of how the number of units are calculated, you read to see that two amounts are added. The more details you want, the further you read. If you turn it the other way around, in a LtR language (Amount2 + Amount1) * UnitCost + FixedCost =: TotalCost; you start with two out-of-context amounts added together, but you really don't know for which purpose. You multiply it by a value, but there is still no indication of why. You add a FixedCost, but only at the very end of the statement do you realize what you are doing all this for! Top-Down design has been accepted in systems design, and even in code design, since the 1970s, but when we get down to real programming, we still insist on assembling small pieces without knowing the purpose of it. :-) I liked the Planc LtR style. But I also like the APL top-down-approach when reading it LtR. I agree that the current mainstream languages makes your attention jump back and forth; I would rather have the APL or Planc philosophy.
Member 7989122 wrote:
Top-Down design has been accepted in systems design
Did that happen on the same day a single religion has been accepted, a single government form has been decided and a single indentation pattern was agreed upon for the whole world?
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
Member 7989122 wrote:
Top-Down design has been accepted in systems design
Did that happen on the same day a single religion has been accepted, a single government form has been decided and a single indentation pattern was agreed upon for the whole world?
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
:-) Maybe I should have been more precise: It is accepted as one of several options in systems design. Not everyone is following the "agile" apporach to extremes, the one where you do, like: "Oh, so you have a problem? Let's start with 'int main(int argc, char** argv) { return 0;}'. There! Now we are going at it. So what is your problem?" I know that "waterfall" is one of the baddest swear words you can use in today's software development world. But when you go through our company's process description from a customer requirement spec to the product delivery, it looks awfully close to a waterfall. Each individual step is managed according to agile principles (this is stressed a lot internally), and if I had made even slight side remarks about the process having strong resemblande to the waterfall model, I would have been fired the same day. So I don't. I believe this is far more common than up-to-date programmers want to know of. They want to enforce a pure agile strategy at their step of the waterfall, believing that that is everything there is. But in a large, established product oriented company that still maintenance on products developed ten years ago, and considers what the market will want five years into the future, you very easily end up with something very much like a waterfall. We just call it by different names, and avoid the swear words.
-
musefan wrote:
I'm confused... what does this mean? How is a number (decimal or otherwise) specifically Arabic? (and therefore specifically RtL)
Our numbering system (and the number 0) are arabic inventions. Romans use a different system, and do not have a sign for nothing. Doesn't make the number itself an Arabic thing, only our current defacto way of encoding these.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
It is interesting to notice that numbers are written the same way in LtR and RtL languages, with the most significant digit to the left. Also notice that in a number of languages, including old English, it was common to read (and write as words) e.g. four-and-twenty, as if read RtL, rather than twentyfour. In German, you still read numbers RtL, at least up to one hundred. Norwegian was similar until a reform in the 1950s. (If you try to bake twentyfour blackbirds in a pie, the rythm will be screwed up...)
-
The numbers that we are using is the decimal numbers a.k.a. Arabic numerals. Here is the history of the numbers: Arabic numerals - Wikipedia[^]. The decimal numbers are called Arabic numbers because they were invented by Arabs (however Zero was invented in India, it is also part of Arabic numbers). So,
1 + 2 = 3
is a correct way in LtR while
3 = 1 + 2
is correct way according to RtL (Arabic, Hebew, etc. RtL languages, however this is now not used because of international Mathematics influence.)
Just because they may have originated in another language does not mean they are still that language. It depends on the context used. Otherwise you could easily argue a lot of English is not actually English because it originated in another language... it doesn't matter where it came from it's only how it's used that matters. If your argument is that Maths is it's own language, then it can also defined it's own read order (i.e. LtR), it doesn't matter where the numbers original came from and how they were originally read. My point is, there is no reason to why they have to be read RtL just because they are decimal numbers.
-
musefan wrote:
I'm confused... what does this mean? How is a number (decimal or otherwise) specifically Arabic? (and therefore specifically RtL)
Our numbering system (and the number 0) are arabic inventions. Romans use a different system, and do not have a sign for nothing. Doesn't make the number itself an Arabic thing, only our current defacto way of encoding these.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Most of spoken languages are written LtR (Left-to-Right) but Maths, the number language, is actually written RtL because the decimal numbers are Arabic numerals. (I know, most will get surprised, but it's true about Maths RtL direction.) But somehow the RtL and LtR languages got mixed up. Instead of writing
x = a + 12
how about changing it to
a + 12 = x
So, what are your views on creating a new programming language which follows proper LtR execution? Is there already such language? (Please, just don't remind me that there are already lots of programming languages (I know already) and I must not (try to) create one more. :) )
Nikunj_Bhatt wrote:
So, what are your views on creating a new programming language which follows proper LtR execution?
What "problem" would that solve? Yeah, I didn't think so. There's plenty of languages to know already, I don't think anybody wants another one that only "fixes" this.
