Edit: functional is a tool, declarative is a tool, imperative is a tool. There's nothing wrong with any of them, it's whether they're applied correctly that makes them good or bad. They're just tools. Imperative can be the right one sometimes.
Speak for yourself. I find declarative programming to be far more intuitive, as it lets me think about how I should go from the data I have to the data I want. Thinking about programs in terms of the steps they're taking to do something generally bogs people down with irrelevant implementation details.
Software developers who are taught imperative programming are used to translating their high-level, human thoughts into imperative instructions telling the computer exactly what to do to make the answer they want.
With functional programming, one is able to translate thoughts more directly. Non-programmers actually have an easier time with functional concepts like mapping than for loops, non-local mutation, etc.
At any rate, imperative languages have a legacy of frankly buggy, shitty software. As programs get larger and more concurrent, this problem is getting much, much worse. That's why functional(ish) libraries like Redux are so popular. They can help tame this complexity.
Imperative programming absolutely has its place in certain situations like systems or numerical programming, but it is a poor tool for most things people program. Rust, I think, is imperative programming done right. While it's a bit confusing with all the pointer types, it has the tools needed to safely mutate, etc.
The issue I see is that a . and a , are tiny little marks on the screen that are super easy to miss and, at a glance, the . , ; all can look the same. Maybe with practice you can spot the differences easier, but certainly as a newcomer to the language its a lot of extra cognitive load. && and || at least are super obvious.
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.
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.
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 write.
I understand that it's a core feature of the language, but its really awkward when using Picat imperatively. I've seen this dynamic of obeyibg to tradition in many languages. The vast majority of developers are used to imperative languages. If designers of functional, logic, etc languages want to hijack those developers to their own language they could try to be creative and bold and give those developers a syntax their are familiar with.
Elixir has a Ruby like syntax to Erlang and had some success at onboarding Ruby developers. But it wasn't bold. Example: they didn't have courage to turn GenServer into a Class with a CPU. It's still a bag of functions, partly called by clients, partly called by the server, with method names (if it was a class) hidden in arguments and explicit state management.
The Reia language was a bolder attempt but unfortunately its designer liked Elixir and killed his project. My guess: there would be many more Reia developers than Elixir ones by now.
The idea that typing commas is far more difficult than typing semicolons is common, but bizarre. I feel like you're using a lot of words here to rationalize being accustomed to semicolons or significant whitespace as a logical preference rather than an aesthetic one. Consider commas somewhere between a minimalist and maximalist aesthetic (" " < "," < ";"), but one that values consistency.
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;
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 look really redundant.
>> The end of line should be the and, or what the language understands to be the
end of a statement.
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.
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.
I'd say it's a general trend in industry, similar to that in the 80's with their fourth generation languages.
It happens when the current programming languages fail short of solving the most difficult problems the industry faces and programmers explore some paradigms that solve them nicely, but those paradigms haven't been integrated into a single coherent platform.
This shift is pretty much happening with reactive functional programming - which solves asynchronous calls in the web -, and to some extent with large-scale module composition, which still lacks a good widely known solution.
38 comments
[ 3.3 ms ] story [ 72.2 ms ] threadEdit: functional is a tool, declarative is a tool, imperative is a tool. There's nothing wrong with any of them, it's whether they're applied correctly that makes them good or bad. They're just tools. Imperative can be the right one sometimes.
With functional programming, one is able to translate thoughts more directly. Non-programmers actually have an easier time with functional concepts like mapping than for loops, non-local mutation, etc.
At any rate, imperative languages have a legacy of frankly buggy, shitty software. As programs get larger and more concurrent, this problem is getting much, much worse. That's why functional(ish) libraries like Redux are so popular. They can help tame this complexity.
Imperative programming absolutely has its place in certain situations like systems or numerical programming, but it is a poor tool for most things people program. Rust, I think, is imperative programming done right. While it's a bit confusing with all the pointer types, it has the tools needed to safely mutate, etc.
My only criticism is about dots and commas, and I know where they come from. Especially as
> Picat, as a scripting language, is as powerful as Python and Ruby.
But I'm not adding commas and dots to the end of each line, it's a little nightmare. I'm staying with Python and Ruby for scripting.
Is there really no way for logic programming languages to skip commas and dots or is it only a tradition?
one, two, three.
Is essentially compiled down to:
if (one && two && three) { return three; }
Whereas
one, two, three;
one, four.
compiles down to:
if (one && two && three) { return three; } else if (one && four) { return four; }
So yeah, it's not syntax.
, === &&
; === ||
. marks end of a condition, so } in C.
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.
You do need the Swi-Prolog IDE for that though.
I wrote a little Prolog some 30 years ago. Probably those commas and dots have the same function, logic and, as you write.
I understand that it's a core feature of the language, but its really awkward when using Picat imperatively. I've seen this dynamic of obeyibg to tradition in many languages. The vast majority of developers are used to imperative languages. If designers of functional, logic, etc languages want to hijack those developers to their own language they could try to be creative and bold and give those developers a syntax their are familiar with.
Elixir has a Ruby like syntax to Erlang and had some success at onboarding Ruby developers. But it wasn't bold. Example: they didn't have courage to turn GenServer into a Class with a CPU. It's still a bag of functions, partly called by clients, partly called by the server, with method names (if it was a class) hidden in arguments and explicit state management.
The Reia language was a bolder attempt but unfortunately its designer liked Elixir and killed his project. My guess: there would be many more Reia developers than Elixir ones by now.
http://reia-lang.org/
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.
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.
Not sure why the older posting wasn't picked up when I submitted the link.
It happens when the current programming languages fail short of solving the most difficult problems the industry faces and programmers explore some paradigms that solve them nicely, but those paradigms haven't been integrated into a single coherent platform.
This shift is pretty much happening with reactive functional programming - which solves asynchronous calls in the web -, and to some extent with large-scale module composition, which still lacks a good widely known solution.
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.