What's the Most Concise, Human-Understandable Practical Language?
-
Member 7989122 wrote:
Why do we have to announce in advance with a "try" that the block has an exception handler? The handler is there, that should be enough!
CallSomeMethod();
try
{
CallSomeOtherMethod();
}
catch (SomeFunkyException)
{
}Without the explicit
try, how would you indicate that the first method call wasn't covered by thecatchblock?
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
You could e.g. look at CHILL, aka Z.200: Any block may have a handler attached: If there is an ON-clause between the body of the block and the terminating semicolon, the block has a hanlder. If there is no ON-clause, it does not have a handler. THere is no need to pre-announce it. Note that in CHILL, as well as in most other sensible languages of the Algol class, a statement is a block; you don't need to enclose a single statement to make it one. So it would be like
CallSomeMethod();
CallSomeOtherMethod() -- note: no semicolon - block not yet complete
ON (SomeFunkyException):
LogThisException();
END; -- here is the semicolon terminating the blockUsually when you want to attch a handler to a group of statements, that group is e.g. a function body, a loop, an if/then/else etc. defining a block. If these two calls are looped, and you want to attach the handler to the loop - i.e. the it is invoked when the exception breaks out of this loop, you would write it as
DO
CallSomeMethod();
CallSomeOtherMethod();
OD -- note: no semicolon; loop still incomplete
ON (SomeFunkyException): -- handler for exception in the loop statement
LogThisException();
END;The DO-OD bracing of the loop body makes it a block, to which a handler may be attached without any further blocking. If you want to attach a handler to the two calls, not to the loop as such, you have to make them into block by bracing them:
DO WHILE ExceptionCount < 10;
SomeCallNotHanldedByTheOnClause();
BEGIN
CallSomeMethod();
CallSomeOtherMethod();
END -- no semicolon - handler follows
ON (SomeFunkyException): -- handler for exception in the loop statement
LogThisException();
Exceptioncount +:= 1;
END;
AnotherCallWithNoHandler();
OD;Now the handler for the two statements is processed within the loop, and unless another exception is caused, control stays within the loop. CHILL uses keywords rather than braces; that is not the point here. Braces might have saved a few keystrokes, but since keywords often come in pairs, they do their own bracketing, like DO-OD, ON-END, ... You need to indicate which kind of block (like DO), and adding a brace to indicate "I am serious - a block!" is redundant. You could of course save a keystroke by replacing the OD with a closing brace, but I'd find it strange for braces not to come in pairs. I rather have an OD terminating a loop body, a FI term
-
You could e.g. look at CHILL, aka Z.200: Any block may have a handler attached: If there is an ON-clause between the body of the block and the terminating semicolon, the block has a hanlder. If there is no ON-clause, it does not have a handler. THere is no need to pre-announce it. Note that in CHILL, as well as in most other sensible languages of the Algol class, a statement is a block; you don't need to enclose a single statement to make it one. So it would be like
CallSomeMethod();
CallSomeOtherMethod() -- note: no semicolon - block not yet complete
ON (SomeFunkyException):
LogThisException();
END; -- here is the semicolon terminating the blockUsually when you want to attch a handler to a group of statements, that group is e.g. a function body, a loop, an if/then/else etc. defining a block. If these two calls are looped, and you want to attach the handler to the loop - i.e. the it is invoked when the exception breaks out of this loop, you would write it as
DO
CallSomeMethod();
CallSomeOtherMethod();
OD -- note: no semicolon; loop still incomplete
ON (SomeFunkyException): -- handler for exception in the loop statement
LogThisException();
END;The DO-OD bracing of the loop body makes it a block, to which a handler may be attached without any further blocking. If you want to attach a handler to the two calls, not to the loop as such, you have to make them into block by bracing them:
DO WHILE ExceptionCount < 10;
SomeCallNotHanldedByTheOnClause();
BEGIN
CallSomeMethod();
CallSomeOtherMethod();
END -- no semicolon - handler follows
ON (SomeFunkyException): -- handler for exception in the loop statement
LogThisException();
Exceptioncount +:= 1;
END;
AnotherCallWithNoHandler();
OD;Now the handler for the two statements is processed within the loop, and unless another exception is caused, control stays within the loop. CHILL uses keywords rather than braces; that is not the point here. Braces might have saved a few keystrokes, but since keywords often come in pairs, they do their own bracketing, like DO-OD, ON-END, ... You need to indicate which kind of block (like DO), and adding a brace to indicate "I am serious - a block!" is redundant. You could of course save a keystroke by replacing the OD with a closing brace, but I'd find it strange for braces not to come in pairs. I rather have an OD terminating a loop body, a FI term
I must be missing something - with the exception (no pun intended!) of the single-statement / single-block case, why is:
BEGIN
...
END
ON (SomeFunkyException): ...
END;any better than:
try
{
...
}
catch (SomeFunkyException)
{
...
}Is it just the curly-braces you don't like? :confused:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Here's my fantasy rewrite of some Javascript. Which one do you find more understandable? Which one's function and structure is more instantly obvious? Be honest. JS
var home = {
cit : "Boston",
get City () {
return this.cit;
},
set City(val) {
this.cit = val;
}
};Fantasy Rewrite
home
City 'Boston'That's sort of what i'm looking for. Notice the lack of punctuation. Notice judicious use of whitespace as syntax. Notice how the getter, setter, variable, and default value are all encapsulated into two words. What language is like that?
What's "Human understandable"?
I mean, easy to understand at a glance. Here's Game of Life in APL. Extremely concise! And totally NOT human-understandable.
{≢⍸⍵}⌺3 3∊¨3+0,¨⊢
Here's the Whitespace language. Extremely concise, and totally NOT human-understandable. Seeking characters found on a normal keyboard.
By "human-understandable", i DON'T mean "natural language" or "sounds like spoken English". I mean, provided you have learned the special programming syntax, and that learning that syntax is no more challenging or time-consuming than learning, say, Python.
What's "Concise"?
Here's some COBOL. Very human understandable. But not concise:
ADD YEARS TO AGE.
MULTIPLY PRICE BY QUANTITY GIVING COST.
SUBTRACT DISCOUNT FROM COST GIVING FINAL-COST.What's "Practical"
By "practical" i mean, it's a wise choice for real-world programming. Ie, not just an academic experiment. It has community, tools, rich programming features.... things a language needs to be usable for real projects.
A couple questions: What is your audience? Non-technical average Joe? Technical (domain expert) but non-programmer? Software engineer? Firmware Engineer?, etc, etc, etc. What is the target program type? Web? Windows/Linux application? Embedded realtime?, etc, etc, etc I believe you're not going to find (or create) the 'perfect' language that's practical and concise that will handle all these user types and targets.
-
Here's my fantasy rewrite of some Javascript. Which one do you find more understandable? Which one's function and structure is more instantly obvious? Be honest. JS
var home = {
cit : "Boston",
get City () {
return this.cit;
},
set City(val) {
this.cit = val;
}
};Fantasy Rewrite
home
City 'Boston'That's sort of what i'm looking for. Notice the lack of punctuation. Notice judicious use of whitespace as syntax. Notice how the getter, setter, variable, and default value are all encapsulated into two words. What language is like that?
What's "Human understandable"?
I mean, easy to understand at a glance. Here's Game of Life in APL. Extremely concise! And totally NOT human-understandable.
{≢⍸⍵}⌺3 3∊¨3+0,¨⊢
Here's the Whitespace language. Extremely concise, and totally NOT human-understandable. Seeking characters found on a normal keyboard.
By "human-understandable", i DON'T mean "natural language" or "sounds like spoken English". I mean, provided you have learned the special programming syntax, and that learning that syntax is no more challenging or time-consuming than learning, say, Python.
What's "Concise"?
Here's some COBOL. Very human understandable. But not concise:
ADD YEARS TO AGE.
MULTIPLY PRICE BY QUANTITY GIVING COST.
SUBTRACT DISCOUNT FROM COST GIVING FINAL-COST.What's "Practical"
By "practical" i mean, it's a wise choice for real-world programming. Ie, not just an academic experiment. It has community, tools, rich programming features.... things a language needs to be usable for real projects.
Kotlin: maybe not best "human-understandable" but it takes Java and make it more concise. You don't have to write many things the Kotlin that you write in the Java. Red: it's still in the alpha version but you should keep an eye on it. You can write in different styles but you can write small & concise code. It has some "weird features". Ruby: It might be not fastest language but it's very readable. No "parenthesis hell" (same as in the Red) as in other languages.
-
Here's my fantasy rewrite of some Javascript. Which one do you find more understandable? Which one's function and structure is more instantly obvious? Be honest. JS
var home = {
cit : "Boston",
get City () {
return this.cit;
},
set City(val) {
this.cit = val;
}
};Fantasy Rewrite
home
City 'Boston'That's sort of what i'm looking for. Notice the lack of punctuation. Notice judicious use of whitespace as syntax. Notice how the getter, setter, variable, and default value are all encapsulated into two words. What language is like that?
What's "Human understandable"?
I mean, easy to understand at a glance. Here's Game of Life in APL. Extremely concise! And totally NOT human-understandable.
{≢⍸⍵}⌺3 3∊¨3+0,¨⊢
Here's the Whitespace language. Extremely concise, and totally NOT human-understandable. Seeking characters found on a normal keyboard.
By "human-understandable", i DON'T mean "natural language" or "sounds like spoken English". I mean, provided you have learned the special programming syntax, and that learning that syntax is no more challenging or time-consuming than learning, say, Python.
What's "Concise"?
Here's some COBOL. Very human understandable. But not concise:
ADD YEARS TO AGE.
MULTIPLY PRICE BY QUANTITY GIVING COST.
SUBTRACT DISCOUNT FROM COST GIVING FINAL-COST.What's "Practical"
By "practical" i mean, it's a wise choice for real-world programming. Ie, not just an academic experiment. It has community, tools, rich programming features.... things a language needs to be usable for real projects.
No one has mentioned Python?!? That's interesting.
-
Here's my fantasy rewrite of some Javascript. Which one do you find more understandable? Which one's function and structure is more instantly obvious? Be honest. JS
var home = {
cit : "Boston",
get City () {
return this.cit;
},
set City(val) {
this.cit = val;
}
};Fantasy Rewrite
home
City 'Boston'That's sort of what i'm looking for. Notice the lack of punctuation. Notice judicious use of whitespace as syntax. Notice how the getter, setter, variable, and default value are all encapsulated into two words. What language is like that?
What's "Human understandable"?
I mean, easy to understand at a glance. Here's Game of Life in APL. Extremely concise! And totally NOT human-understandable.
{≢⍸⍵}⌺3 3∊¨3+0,¨⊢
Here's the Whitespace language. Extremely concise, and totally NOT human-understandable. Seeking characters found on a normal keyboard.
By "human-understandable", i DON'T mean "natural language" or "sounds like spoken English". I mean, provided you have learned the special programming syntax, and that learning that syntax is no more challenging or time-consuming than learning, say, Python.
What's "Concise"?
Here's some COBOL. Very human understandable. But not concise:
ADD YEARS TO AGE.
MULTIPLY PRICE BY QUANTITY GIVING COST.
SUBTRACT DISCOUNT FROM COST GIVING FINAL-COST.What's "Practical"
By "practical" i mean, it's a wise choice for real-world programming. Ie, not just an academic experiment. It has community, tools, rich programming features.... things a language needs to be usable for real projects.
Why? Why optimize for concise? To save YOU time typing? I write code in a pseudo code format for the first pass, then have to translate it to one of many languages depending on the target. Most concepts are clear enough. What about R? (Functional languages?) But again... I prefer a language that has the libraries/components/tools that I need. If I gave you your "perfectly" concise language, without a bunch of caveats, like no libraries, no classes, no protocol support. Would you want to use it? If you had to implement AES, SMTP, HTTP, etc all by hand? == The most important thing I ever learned... Once you know how to write the program properly. The language is not usually what is holding you back. Especially with UDFs. == For me. C was the most elegant language and always my favorite. It was PDP Macro Assembler as a language with indentation and code blocks, UDFs, etc. etc. And probably a bit too concise, LOL!
-
I must be missing something - with the exception (no pun intended!) of the single-statement / single-block case, why is:
BEGIN
...
END
ON (SomeFunkyException): ...
END;any better than:
try
{
...
}
catch (SomeFunkyException)
{
...
}Is it just the curly-braces you don't like? :confused:
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Yes, you are missing something. The BEGIN-END really has nothing to do with the exception handling - it does NOT announce the ON. It just creates a block out of smaller ones. It has multiple uses; you could e.g. label the block, and skip out of it if some test is not satisfied, like
ManySteps:
BEGIN
Step1();
IF PreparationWentWrong THEN EXIT ManySteps;
Step2();
IF Specialcondition THEN EXIT ManySteps;
Step3();
END ManySteps;This is just a way to make a block that is not a loop, not a conditional statement, not a function body, but just a sequence of smaller blocks put togeteher for some purpose (such as here: For leaving, when conditions are right). Actually, I sometimes do something similar in C#, using a "do { ... } while (false);" to allow me many exits from the statement sequence without cdreating a deep nest of if-statements - but the C family allows just exiting the innermost block; in CHILL you can exit directly from any labeled surrounding block. Whatever might be: The BEGIN-END has nothing to do with the try {...}. You may say that in CHILL, any block "implies a try {}". I do not like redundant markup, whether extra keywords, braces, parentheses or whatever. If you say "Here come a DO-block" by using a DO keyword, then you should not need to add neither BEGIN nor a brace to say that "this is the block". Of course it is - you said so already! When you say "Here comes a conditional block" by using an IF keyword, you should not need to use an open parenthesis to say that "here comes the condition". Of course - how often do you see an if keyword not followed by a condition? So why do you have to announce it by opening a parentheses pair? In prose text, you never need to write the condition part of a question in parentheses, why do you have to in C? If you want to treat two smaller blocks as one unit, whether for exception handling, exiting or whatever, one way or another you must identify which blocks you are talking about. THat markup is not redundant, whether it is done with keywords, braces or indentation alone. When you are comparing the try{} with the BEGIN-END, you are comparing apples with oranges, redundant with non-redundant markup. In C-style languages, the braces are there for the try (alone):
try {
SingleStatement();
}
catch ...Well, you could argue that in C languages, the parentheses are not redundant, as a single statement is not considered a block, so the braces are required to created o
-
Yes, you are missing something. The BEGIN-END really has nothing to do with the exception handling - it does NOT announce the ON. It just creates a block out of smaller ones. It has multiple uses; you could e.g. label the block, and skip out of it if some test is not satisfied, like
ManySteps:
BEGIN
Step1();
IF PreparationWentWrong THEN EXIT ManySteps;
Step2();
IF Specialcondition THEN EXIT ManySteps;
Step3();
END ManySteps;This is just a way to make a block that is not a loop, not a conditional statement, not a function body, but just a sequence of smaller blocks put togeteher for some purpose (such as here: For leaving, when conditions are right). Actually, I sometimes do something similar in C#, using a "do { ... } while (false);" to allow me many exits from the statement sequence without cdreating a deep nest of if-statements - but the C family allows just exiting the innermost block; in CHILL you can exit directly from any labeled surrounding block. Whatever might be: The BEGIN-END has nothing to do with the try {...}. You may say that in CHILL, any block "implies a try {}". I do not like redundant markup, whether extra keywords, braces, parentheses or whatever. If you say "Here come a DO-block" by using a DO keyword, then you should not need to add neither BEGIN nor a brace to say that "this is the block". Of course it is - you said so already! When you say "Here comes a conditional block" by using an IF keyword, you should not need to use an open parenthesis to say that "here comes the condition". Of course - how often do you see an if keyword not followed by a condition? So why do you have to announce it by opening a parentheses pair? In prose text, you never need to write the condition part of a question in parentheses, why do you have to in C? If you want to treat two smaller blocks as one unit, whether for exception handling, exiting or whatever, one way or another you must identify which blocks you are talking about. THat markup is not redundant, whether it is done with keywords, braces or indentation alone. When you are comparing the try{} with the BEGIN-END, you are comparing apples with oranges, redundant with non-redundant markup. In C-style languages, the braces are there for the try (alone):
try {
SingleStatement();
}
catch ...Well, you could argue that in C languages, the parentheses are not redundant, as a single statement is not considered a block, so the braces are required to created o
Member 7989122 wrote:
This is just a way to make a block that is not a loop, not a conditional statement, not a function body, but just a sequence of smaller blocks put togeteher for some purpose
You can create a similar block in C# using braces. And if you're particularly masochistic, you can mimic the
EXITwith a goto[^]. :)ManySteps:
BEGIN
Step1();
IF PreparationWentWrong THEN EXIT ManySteps;
Step2();
IF Specialcondition THEN EXIT ManySteps;
Step3();
END ManySteps;{
Step1();
if (PreparationWentWrong) goto ExitManySteps;
Step2();
if (Specialcondition) goto ExitManySteps;
Step3();
}
ExitManySteps:But this example would probably be better handled with SEH - if something went wrong, you don't want to depend on the caller checking a return value, or some unrelated property.
Member 7989122 wrote:
When you say "Here comes a conditional block" by using an IF keyword, you should not need to use an open parenthesis to say that "here comes the condition".
That could potentially lead to ambiguity - which statement(s) are part of the condition, and which are part of the branch? Even if it's always obvious to the compiler, it may not always be obvious to the person reading the code. And the main point of any code is to be read and understood by a person.
Member 7989122 wrote:
That is a major flaw in the language "design".
No, it's a major difference in the language design. (And yes, the language was designed. No need for the sarcisti-quotes.) English doesn't have accents on any letters; you're just supposed to know how to pronounce them. Does that makes the accents in other languages a flaw? Or is English the flawed language for not having them? Just because something is different doesn't mean that it's flawed.
Member 7989122 wrote:
At the end of a deep nest, in C languages there may be a lisp-like sequence of closing parentheses, and you may have a hard time seeing which one closes the outermost loop, the while, the function, the class...
-
Here's my fantasy rewrite of some Javascript. Which one do you find more understandable? Which one's function and structure is more instantly obvious? Be honest. JS
var home = {
cit : "Boston",
get City () {
return this.cit;
},
set City(val) {
this.cit = val;
}
};Fantasy Rewrite
home
City 'Boston'That's sort of what i'm looking for. Notice the lack of punctuation. Notice judicious use of whitespace as syntax. Notice how the getter, setter, variable, and default value are all encapsulated into two words. What language is like that?
What's "Human understandable"?
I mean, easy to understand at a glance. Here's Game of Life in APL. Extremely concise! And totally NOT human-understandable.
{≢⍸⍵}⌺3 3∊¨3+0,¨⊢
Here's the Whitespace language. Extremely concise, and totally NOT human-understandable. Seeking characters found on a normal keyboard.
By "human-understandable", i DON'T mean "natural language" or "sounds like spoken English". I mean, provided you have learned the special programming syntax, and that learning that syntax is no more challenging or time-consuming than learning, say, Python.
What's "Concise"?
Here's some COBOL. Very human understandable. But not concise:
ADD YEARS TO AGE.
MULTIPLY PRICE BY QUANTITY GIVING COST.
SUBTRACT DISCOUNT FROM COST GIVING FINAL-COST.What's "Practical"
By "practical" i mean, it's a wise choice for real-world programming. Ie, not just an academic experiment. It has community, tools, rich programming features.... things a language needs to be usable for real projects.
johnywhy wrote:
Here's some COBOL. Very human understandable. But not concise:
ADD YEARS TO AGE.
MULTIPLY PRICE BY QUANTITY GIVING COST.
SUBTRACT DISCOUNT FROM COST GIVING FINAL-COST.The boilerplate required in COBOL in order to encapsulate those three lines is going to be around another 300 lines of code, code which is not particularly human-readable ;P
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Why? Why optimize for concise? To save YOU time typing? I write code in a pseudo code format for the first pass, then have to translate it to one of many languages depending on the target. Most concepts are clear enough. What about R? (Functional languages?) But again... I prefer a language that has the libraries/components/tools that I need. If I gave you your "perfectly" concise language, without a bunch of caveats, like no libraries, no classes, no protocol support. Would you want to use it? If you had to implement AES, SMTP, HTTP, etc all by hand? == The most important thing I ever learned... Once you know how to write the program properly. The language is not usually what is holding you back. Especially with UDFs. == For me. C was the most elegant language and always my favorite. It was PDP Macro Assembler as a language with indentation and code blocks, UDFs, etc. etc. And probably a bit too concise, LOL!
> Why optimize for concise? To save YOU time typing? I don't think typing is a problem when you have IDEs with autocompletion. The problem is reading. Sure, your IDE will colour this and that but you still have, for example, whole line just saying " is the name of the function".
-
Why? Why optimize for concise? To save YOU time typing? I write code in a pseudo code format for the first pass, then have to translate it to one of many languages depending on the target. Most concepts are clear enough. What about R? (Functional languages?) But again... I prefer a language that has the libraries/components/tools that I need. If I gave you your "perfectly" concise language, without a bunch of caveats, like no libraries, no classes, no protocol support. Would you want to use it? If you had to implement AES, SMTP, HTTP, etc all by hand? == The most important thing I ever learned... Once you know how to write the program properly. The language is not usually what is holding you back. Especially with UDFs. == For me. C was the most elegant language and always my favorite. It was PDP Macro Assembler as a language with indentation and code blocks, UDFs, etc. etc. And probably a bit too concise, LOL!
I think of it more at a concept level rather than saving typing. Avoid reduncancy. Avoid tokens that serve no purpose. Remove clutter. As I argued earlier in the thread: A language such as CHILL allows any block to have an exception handler attached. Putting "try{...}" around the block before the handler is redundant: If the handler is present, then the block has a handler - no need to pre-announce it! Removing the need for that pre-announcement simplifies the code. (The real reason for the C/C++ try{} is purely historic: C didn't have any such thing, while several other languages did. So to "compete", a macro-based solution was devised, that required no extension to the underlaying compiler. When adopted into the C/C++ language, it could have been given a cleaner syntax, but to be backwards compatible with all the code that had been written for the macro-based implementation, the syntax was kept unchanged.) In Pascal (or CHILL), you write a condtion without enclosing parethes like in prose text: If it is raining, then you better wear a raincoat. You need not clutter up that sentence with parentheses markup. You remove the conceptually informationless tokens.
var matching = new List();
rather than
List matching = new List();
removes redundancy, risk of inconsistency, and the reader has fewer tokens to interpret. I do not see what we gain by repeating the type information when it can be infered. (var has other uses as well unrelated to this.) A language recognizing a statement as a block avoids redundant bracketing: At the spur of the moment, I cannot think of a single case where single-statement block and a single statement are both valid but with different semantics. So I see no reason why some languages insist on adding these extra tokens that carry no semantic information. The idea is that non-information-carrying elements (that you nevertheless have to relate to) are bad. The fewer elements you need to process mentally, the better. This is, of course, assuming that the programmer/reader easily relates to the concepts repersented by the tokens. E.g. to a matehmatician, matrix inversion is such a basic and common concept that giving it a separate symbol (analogous to multiply and divide) as it done in APL (created as a mathematical notation, not as a programming languge) is perfectly fine even though non-mathmaticians says "Huh?". For those who are "only engineers", powers are essential, so languages with that user
-
Member 7989122 wrote:
This is just a way to make a block that is not a loop, not a conditional statement, not a function body, but just a sequence of smaller blocks put togeteher for some purpose
You can create a similar block in C# using braces. And if you're particularly masochistic, you can mimic the
EXITwith a goto[^]. :)ManySteps:
BEGIN
Step1();
IF PreparationWentWrong THEN EXIT ManySteps;
Step2();
IF Specialcondition THEN EXIT ManySteps;
Step3();
END ManySteps;{
Step1();
if (PreparationWentWrong) goto ExitManySteps;
Step2();
if (Specialcondition) goto ExitManySteps;
Step3();
}
ExitManySteps:But this example would probably be better handled with SEH - if something went wrong, you don't want to depend on the caller checking a return value, or some unrelated property.
Member 7989122 wrote:
When you say "Here comes a conditional block" by using an IF keyword, you should not need to use an open parenthesis to say that "here comes the condition".
That could potentially lead to ambiguity - which statement(s) are part of the condition, and which are part of the branch? Even if it's always obvious to the compiler, it may not always be obvious to the person reading the code. And the main point of any code is to be read and understood by a person.
Member 7989122 wrote:
That is a major flaw in the language "design".
No, it's a major difference in the language design. (And yes, the language was designed. No need for the sarcisti-quotes.) English doesn't have accents on any letters; you're just supposed to know how to pronounce them. Does that makes the accents in other languages a flaw? Or is English the flawed language for not having them? Just because something is different doesn't mean that it's flawed.
Member 7989122 wrote:
At the end of a deep nest, in C languages there may be a lisp-like sequence of closing parentheses, and you may have a hard time seeing which one closes the outermost loop, the while, the function, the class...
Richard Deeming wrote:
And yes, the language was designed.
I'd certainly like to see those design documents. Which alternatives were considered, the rationale behind each, the arguments for the selected solution. I have never ever heard even the tiniest little suggestion that any such thing exists. What was the rationale for not having a proper argument list in the function header, in the initial K&R, but listing the arguments below the header? What was the arguments when the language was redesigned for changing it to how other Algol-class languages did it? What was the rationale for not defining a statement to be a block, as in most other Algol-class languages? What was the rationale for defining the syntax of conditional statements like while-loops and if-statements so that parentheses are required around the condition - it is not in languages like Pascal, CHILL, Algol? What was the rationale for using the equals sign for assignment, so that an equals condition must be represented by two equals signs? What was the rational for deviating from the ISO standard interpretation of the CR, LF and NUL character codes? What was the rationale for not including enumeration types, as a first class type, in the language? For Algol-60, you can find discussions of it in the design douments, but lack of resources prevented them from implementing it time for the deadline, so it was omitted from the specificatin - but Pascal implemented it a few years later. Why didn't C? This thread has said a lot about exception handling. The first generation of C/C++ execption handling was not part of the language definition, but a cludge realized by macros and longjmp so that programmers could pretend that C had the same facilites as (some) other languages. Was there a design document for this? Was there a design document specifying how to incorporate this cludge in the language itself? Writing a book a couple of years after the implementation, to tell: See what we have implemented! - that is not a language design process. Algol was through a design process. CHILL was through a design process, where several competing proposals were analyzed, and after critical evaluation of each feature, a choice was made to how it ws to be defined in the final specification. Starting with Fortran 77, Fortran has been further developed in a similar way, but of course with strong dependencies on earlier language versions. SUN tried to make ISO accept Ja
-
Richard Deeming wrote:
And yes, the language was designed.
I'd certainly like to see those design documents. Which alternatives were considered, the rationale behind each, the arguments for the selected solution. I have never ever heard even the tiniest little suggestion that any such thing exists. What was the rationale for not having a proper argument list in the function header, in the initial K&R, but listing the arguments below the header? What was the arguments when the language was redesigned for changing it to how other Algol-class languages did it? What was the rationale for not defining a statement to be a block, as in most other Algol-class languages? What was the rationale for defining the syntax of conditional statements like while-loops and if-statements so that parentheses are required around the condition - it is not in languages like Pascal, CHILL, Algol? What was the rationale for using the equals sign for assignment, so that an equals condition must be represented by two equals signs? What was the rational for deviating from the ISO standard interpretation of the CR, LF and NUL character codes? What was the rationale for not including enumeration types, as a first class type, in the language? For Algol-60, you can find discussions of it in the design douments, but lack of resources prevented them from implementing it time for the deadline, so it was omitted from the specificatin - but Pascal implemented it a few years later. Why didn't C? This thread has said a lot about exception handling. The first generation of C/C++ execption handling was not part of the language definition, but a cludge realized by macros and longjmp so that programmers could pretend that C had the same facilites as (some) other languages. Was there a design document for this? Was there a design document specifying how to incorporate this cludge in the language itself? Writing a book a couple of years after the implementation, to tell: See what we have implemented! - that is not a language design process. Algol was through a design process. CHILL was through a design process, where several competing proposals were analyzed, and after critical evaluation of each feature, a choice was made to how it ws to be defined in the final specification. Starting with Fortran 77, Fortran has been further developed in a similar way, but of course with strong dependencies on earlier language versions. SUN tried to make ISO accept Ja
Going back to Kate's message that started this branch[^], we were talking about C#. Since 2013, all C# design discussions have been public on GitHub: GitHub - dotnet/csharplang: The official repo for the design of the C# programming language[^] Earlier discussions were not made public, but some information was available on various MSDN blogs. The language was originally designed by a team lead by Anders Hejlsberg. As for C/C++, the details of those decisions are likely lost in the murky depths of the dim and distant past of 1972, unless Dennis Ritchie kept some notes somewhere. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I wold go with some Lisp dialect. It looks weird until you get used to it, then all other languages look hard to understand. The reason I found it easy is because the grammer is so simple there's really not much to learn.
Smalltalk has similar properties - the syntax literally fits on an index card.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
BASIC. The only problem with any of the modern BASIC variants is the the name. It should have been changed years ago to something that sounds better. BASIC is the direction that programming languages should have been taking for decades. A programming language is a tool. A tool is something that makes work easier. C, Java and the like make simple jobs complicated, and complicated jobs - well, we won't go there. Unfortunately BASIC has been all but killed off because it scared the crap out of the C guys. VB was arguably one of Microsoft's biggest successes - suddenly anyone smarter than a manager or an accountant could write useful programs. They weren't always fast, or efficient, but they solved real world problems, then and there. And here lies one of the less understood issues with software - many, many programs are written as quick one offs to answer a question, or extract some data. They do not need the .NET framework or the latest C++ or Java support libs, or some horrendously expensive and complicated Studio Suite to create them BASIC was able to do this AND produce high quality complicated full fledged applications. And it still can. My favourite is PowerBasic - PowerBASIC[^] There are a few others. It seems to me that all the 'new' languages we see are based on C syntax. A whole bunch of cryptic punctuation marks interspersed with some unreadable, unintuitive bits of code. It's time to move on. C was never meant to last this long. It was an interim replacement to FORTRAN, until the 'new' languages came along. Sadly they never did.
I concur. Before I was retired from my last paying job:java:, "mangle-ment" dictated that all applications be written in VB, ostensibly "so the auditors can read it." It worked: very seldom did I have to explain my VB code. :) If I had to explain code, it was usually my SQL code. :zzz:
__________________ Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now. © 2009, Rex Hammock
-
Here's my fantasy rewrite of some Javascript. Which one do you find more understandable? Which one's function and structure is more instantly obvious? Be honest. JS
var home = {
cit : "Boston",
get City () {
return this.cit;
},
set City(val) {
this.cit = val;
}
};Fantasy Rewrite
home
City 'Boston'That's sort of what i'm looking for. Notice the lack of punctuation. Notice judicious use of whitespace as syntax. Notice how the getter, setter, variable, and default value are all encapsulated into two words. What language is like that?
What's "Human understandable"?
I mean, easy to understand at a glance. Here's Game of Life in APL. Extremely concise! And totally NOT human-understandable.
{≢⍸⍵}⌺3 3∊¨3+0,¨⊢
Here's the Whitespace language. Extremely concise, and totally NOT human-understandable. Seeking characters found on a normal keyboard.
By "human-understandable", i DON'T mean "natural language" or "sounds like spoken English". I mean, provided you have learned the special programming syntax, and that learning that syntax is no more challenging or time-consuming than learning, say, Python.
What's "Concise"?
Here's some COBOL. Very human understandable. But not concise:
ADD YEARS TO AGE.
MULTIPLY PRICE BY QUANTITY GIVING COST.
SUBTRACT DISCOUNT FROM COST GIVING FINAL-COST.What's "Practical"
By "practical" i mean, it's a wise choice for real-world programming. Ie, not just an academic experiment. It has community, tools, rich programming features.... things a language needs to be usable for real projects.
I would say you rewrite fails the "Human understandable" test, as because my understanding of your code is quite different than what the original javascript does. I'd assume it was closer to:
var home =
{
get City ()
{
return "Boston"
}
};Truth, James
-
No one has mentioned Python?!? That's interesting.
That was exactly my thought, and I had to scroll down way too much to find this :)
Cheers, विक्रम "We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread :doh:
-
The major problem with your idea is "Human understandable" you didn't define the audience, and saying "everybody" is not the answer. my old mother trying to use a DVD player - one with not that many buttons:
"how do I make it go"
"press the 'Play' button."
"you mean this one '|> Play', with a triangle on it."
"yes."
"what does the triangle mean?"and that's not even adding in complications of her first language being English. Let's look at your concise [anti] example
ADD YEARS TO AGE.
MULTIPLY PRICE BY QUANTITY GIVING COST.
SUBTRACT DISCOUNT FROM COST GIVING FINAL-COST.ahh the layman says, I see. but then the accountant
it's all wrong, you've mixed up terms, "'cost' is purchasing, 'price' is selling." "price times quantity is selling price, not even 'nett cost' let alone 'cost'"
understandable to some, an abject failure to others, even the programmer and his audience spoke a different language - probably should fire the project manager for that stuffup. Consider the image they placed on the Voyager space probe: the guy/gal in a circle with arms and legs stretched out in a circle - supposedly according to experts 'understandable' by anything that finds it. There's people on Earth, the very concept it's meant to represent that look at that and scratch their heads. Early explorers would encounter 'natives [perhaps chanting] and shaking their spears' - in some cases it meant 'go away, this is our [special] place, any closer we will attack' - in others 'welcome strangers [yes we have weapons but we are choosing not to use them so be nice]' Sorry, but "Human Understandable" is not possible, not without defining/limiting the audience and even the language.' Does say a Lithuanian farm hand that's never gone outside know what 'city' means? Even pictures don't help, how long were Egyptian hieroglyphs - pretty plain to the people of the time of writing - undecipherable before the Rosetta stone was found? short answer is: it's impossible
pestilence [ pes-tl-uh ns ] noun 1. a deadly or virulent epidemic disease. especially bubonic plague. 2. something that is considered harmful, destructive, or evil. Synonyms: pest, plague, CCP
Quote:
The major problem with your idea is "Human understandable" you didn't define the audience
But i did define it:
Quote:
By "human-understandable", i DON'T mean "natural language" or "sounds like spoken English". I mean, provided you have learned the special programming syntax, and that learning that syntax is no more challenging or time-consuming than learning, say, Python.
The audience is people who have learned the special programming syntax.
-
Here's my fantasy rewrite of some Javascript. Which one do you find more understandable? Which one's function and structure is more instantly obvious? Be honest. JS
var home = {
cit : "Boston",
get City () {
return this.cit;
},
set City(val) {
this.cit = val;
}
};Fantasy Rewrite
home
City 'Boston'That's sort of what i'm looking for. Notice the lack of punctuation. Notice judicious use of whitespace as syntax. Notice how the getter, setter, variable, and default value are all encapsulated into two words. What language is like that?
What's "Human understandable"?
I mean, easy to understand at a glance. Here's Game of Life in APL. Extremely concise! And totally NOT human-understandable.
{≢⍸⍵}⌺3 3∊¨3+0,¨⊢
Here's the Whitespace language. Extremely concise, and totally NOT human-understandable. Seeking characters found on a normal keyboard.
By "human-understandable", i DON'T mean "natural language" or "sounds like spoken English". I mean, provided you have learned the special programming syntax, and that learning that syntax is no more challenging or time-consuming than learning, say, Python.
What's "Concise"?
Here's some COBOL. Very human understandable. But not concise:
ADD YEARS TO AGE.
MULTIPLY PRICE BY QUANTITY GIVING COST.
SUBTRACT DISCOUNT FROM COST GIVING FINAL-COST.What's "Practical"
By "practical" i mean, it's a wise choice for real-world programming. Ie, not just an academic experiment. It has community, tools, rich programming features.... things a language needs to be usable for real projects.
For anyone interested, i created a git project with more description of the fantasy language, and several examples of how the hypothetical language would look. If you like it, please join the project! Homepage: https://github.com/contextual-project/contextual.js More examples: https://github.com/contextual-project/contextual.js/wiki
-
I would say you rewrite fails the "Human understandable" test, as because my understanding of your code is quite different than what the original javascript does. I'd assume it was closer to:
var home =
{
get City ()
{
return "Boston"
}
};Truth, James
James Curran wrote:
I would say you rewrite fails the "Human understandable" test, as because my understanding of your code is quite different than what the original javascript does.
You're interpreting "human readable" to mean "js-programmer readable". That's not what i mean. My rewrite throws out much js syntax, and can't be interpreted through a js lens. It's a different language.
