31–39 of 39 posts
I won't know who Hakan Kjellerstrand is, but if you quote him you should either put [sic] following "suites" or put [suits] instead of it. Gives a bad impression straight off the bat. You could argue language is different from programming but to my subconscious mind it speaks of a lack of attention to detail and excellence.
Is it just me, or is there an uptick in boutique programming language posts on HN lately? Not complaining, just curious if anyone else has noticed.
Someone posts something on x obscure subject and people find it interesting and then research x on their own and post about x a lot.
Earlier quoted context omitted.
I don't write Picat, but when I write Prolog the color scheme for Emacs gives those operators a bright color so they stand out.
Right. As someone who uses raindbow parentheses, I should have immediately thought that it would be solved by the editor. Still, I don't like if readability relies on the editor too much, since you often want to paste or read code elsewhere (on HN, stackoverflow, github, random websites, etc) that may not know about your non-mainstream language.
Earlier quoted context omitted.
The script is import util. input_data(Tri) => Lines = read_file_lines("triangle.txt"), Tri = new_array(Lines.length), I = 1, foreach(Line in Lines) Tri[I] = Line.split().map(to_integer).to_array(), I := I+1 end. In the mind of an imperative scripting developer those commas are (useless) semicolons. I wrote a little Prolog some 30 years ago. Probably those commas and dots have the same function, logic and, as you writ…
I think most designers of alternative paradigm languages also prefer the alternative syntaxes.
Earlier quoted context omitted.
The script is import util. input_data(Tri) => Lines = read_file_lines("triangle.txt"), Tri = new_array(Lines.length), I = 1, foreach(Line in Lines) Tri[I] = Line.split().map(to_integer).to_array(), I := I+1 end. In the mind of an imperative scripting developer those commas are (useless) semicolons. I wrote a little Prolog some 30 years ago. Probably those commas and dots have the same function, logic and, as you writ…
I changed all the commas to "and"'s" and the dots to ";"'s (except in a.b statements): import util; input_data(Tri) => Lines = read_file_lines("triangle.txt") and Tri = new_array(Lines.length) and I = 1 and foreach(Line in Lines) Tri[I] = Line.split().map(to_integer).to_array() and I := I+1 end; Is that better?
The script should do without the ands, the commas and the colons. The end of line should be the and, or what the language understands to be the end of a statement.
By the way, the dot or the semicolon after the end look really redundant.
Earlier quoted context omitted.
I changed all the commas to "and"'s" and the dots to ";"'s (except in a.b statements): import util; input_data(Tri) => Lines = read_file_lines("triangle.txt") and Tri = new_array(Lines.length) and I = 1 and foreach(Line in Lines) Tri[I] = Line.split().map(to_integer).to_array() and I := I+1 end; Is that better?
No. My point is that language designers should try to implement different paradigms with mainstream syntax. This if they are interested in making their languages mainstream, which might not be their goal. The script should do without the ands, the commas and the colons. The end of line should be the and, or what the language understands to be the end of a statement. By the way, the dot or the semicolon after the end…
Earlier quoted context omitted.
Right. As someone who uses raindbow parentheses, I should have immediately thought that it would be solved by the editor. Still, I don't like if readability relies on the editor too much, since you often want to paste or read code elsewhere (on HN, stackoverflow, github, random websites, etc) that may not know about your non-mainstream language.
if making your editor compensate for the language syntax is the only way to make the language syntax easily readable then the language designer has failed.
Earlier quoted context omitted.
I changed all the commas to "and"'s" and the dots to ";"'s (except in a.b statements): import util; input_data(Tri) => Lines = read_file_lines("triangle.txt") and Tri = new_array(Lines.length) and I = 1 and foreach(Line in Lines) Tri[I] = Line.split().map(to_integer).to_array() and I := I+1 end; Is that better?
No. My point is that language designers should try to implement different paradigms with mainstream syntax. This if they are interested in making their languages mainstream, which might not be their goal. The script should do without the ands, the commas and the colons. The end of line should be the and, or what the language understands to be the end of a statement. By the way, the dot or the semicolon after the end…
The problem with that is that the "," is there not to separate statements ("literals") but to declare a relation between them, specifically, conjunction.
Conjunction is one relation that you may way to declare between literals. There is also disjunction and implication. So you do need something to separate "A and B" from "A or B" and "A if B".
You say- "use whitespace for the and". OK. But then, what about the "or" and the "if"? And if we use special symbols for the "or" and the "if" then what's the point of not using one for the "and" also?
As to "block" delimiters, like "." or ";" etc. As far as I can tell the only languages that do not have "block" delimiters are the kind you can find on https://esolangs.org/wiki/, and that is for reasons of a) readability, actually and b) convenience in compiler writing.
Earlier quoted context omitted.
if making your editor compensate for the language syntax is the only way to make the language syntax easily readable then the language designer has failed.
The comma and dot are natural ways to separate and end statements in natural language. Why are they a problem in a programming language, where you have to be extremely careful about your syntax anyway?
First, its a trend. Other languages have trained us to not see them so much (as pard68 said), to put much more weight on other things. Its not complete though, many programming languages do use them: to separate elements in a list, to separate parameters, as method.calls, and in numbers 1.0, so that's probably a very minor reason over all.
Second, programming languages are very symbol heavy: we use all kinds of operators and special->symbols and (various [brackets]), it just kinda drowns out small symbols that are at the bottom of the line like a , or . and they're just not as obvious as keywords or ink-heavy symbols.
But overall, I guess I'm just not used to seeing them in that context and I'd get over it really quickly, just like I very quickly got over Python's significant whitespace or Lisps parentheses. It seems like a big deal until one day suddenly its not anymore.