> Well, there are programming languages and then there are conventions. I think a programming language is more like an alphabet, and programming conventions are the real languages.
I like this. As a thought experiment, consider the idea of transforming a convention into another "letter" in the alphabet. A simple example would be the natural numbers. If our alphabet is "a", then we can represent 1 as "a", 2 as "aa", 3 as "aaa", and so on (unary). If we expand our alphabet with a "b", then we basically have binary. And in the case of "aaaaaaaa", "baaa" is a an improvement. But there will be a an optimal point somewhere, where the load of expanding the alphabet is greater than the benefit of the more compact representation. This explains to a small extent why we (programmers) use hex, and didn't really go to higher bases (digits + alpha could get us to base 36!)
The analogy starts to fall apart when we think about the ability to add to the alphabet, using the conventions. We can't invent new letters, but we can create/repurpose words that encapsulate a lot of meaning.
I'm not really sure where I was going with this anymore!
> I can scroll through code at high speed and understand it at a mere glance once I "get" both the language and the convention that was used.
The issue for me is that the boilerplate is noise. I don't want to see the similar parts, I want to see the parts that differ. Pseudo-C example:
x = [1,2,3,4,5]
product = 1
for (int i = 0; i < x.length; i += 1) {
product *= x[i]
}
sum = 0
for (int j = 0; j < x.length; j += 1) {
sum += x[j]
}
vs pseudo-Haskell:
x = [1,2,3,4,5]
product = fold (*) x
sum = fold (+) x
With the latter example, there are objectively less places for bugs to be present. Sure the definition of fold is somewhere else, but there's only one implementation, whereas the pseudo-C has two implementations. Of course, I'm sure modern Java is much better than this, but it's still a step down.
I'm pretty sure we could configure an editor to expand the second one into the first, but then we come back around to writing-vs-reading.
An interesting experiment would be to have your raw input, eg. msluyter's example of "cmd-J, fori, return" as the editable source file rather than the generated Java output.
Aye, I won't bother critiquing the example, I see what you mean with the boilerplate as noise and part of me agree with you.
One of the main points of programming is to reduce the noise to enable higher levels of code, while keeping an easy access to what's under the hood to fine tune or add new functionalities. A programming language is merely a list of things that will make you lose your temper while you do all that.
It's really cons lists that are harmful -- foldl and foldr are just ways to operate on them. GP's example would work fine with conc trees and a divide-and-conquer reduce instead.
I like this. As a thought experiment, consider the idea of transforming a convention into another "letter" in the alphabet. A simple example would be the natural numbers. If our alphabet is "a", then we can represent 1 as "a", 2 as "aa", 3 as "aaa", and so on (unary). If we expand our alphabet with a "b", then we basically have binary. And in the case of "aaaaaaaa", "baaa" is a an improvement. But there will be a an optimal point somewhere, where the load of expanding the alphabet is greater than the benefit of the more compact representation. This explains to a small extent why we (programmers) use hex, and didn't really go to higher bases (digits + alpha could get us to base 36!)
The analogy starts to fall apart when we think about the ability to add to the alphabet, using the conventions. We can't invent new letters, but we can create/repurpose words that encapsulate a lot of meaning.
I'm not really sure where I was going with this anymore!
> I can scroll through code at high speed and understand it at a mere glance once I "get" both the language and the convention that was used.
The issue for me is that the boilerplate is noise. I don't want to see the similar parts, I want to see the parts that differ. Pseudo-C example:
vs pseudo-Haskell: With the latter example, there are objectively less places for bugs to be present. Sure the definition of fold is somewhere else, but there's only one implementation, whereas the pseudo-C has two implementations. Of course, I'm sure modern Java is much better than this, but it's still a step down.I'm pretty sure we could configure an editor to expand the second one into the first, but then we come back around to writing-vs-reading.
An interesting experiment would be to have your raw input, eg. msluyter's example of "cmd-J, fori, return" as the editable source file rather than the generated Java output.