3 ms·

The number of bytes isn’t really significant. It’s the conceptual distance between what we want to achieve and the concrete steps in the code. Lisp may be an i

The number of bytes isn’t really significant. It’s the conceptual distance between what we want to achieve and the concrete steps in the code. Lisp may be an improvement.

tgv 4y ago
But now you're already heading into much vaguer territory. Readability is also important. Very important, I would say. That requires easily identifiable markers for loops, conditions, functions, etc., something Lisp lacks. This might be a place where keyword coloring could be useful, but then we're relying on external help. Another issue is consistency. Take C, Javascript, or Go. Many loops are of the form for (var i = 0; i < n; i++) { ... } You could argue that "for i < n" provides the same information, but then you'd have to find a way to start the loop at a different offset, use a different end condition, or different "increment".
- pharmakom 4y ago
  > But now you're already heading into much vaguer territory. Yes programming language design is a social science (imo)
- nradov 4y ago
  But that's exactly the issue. In most cases with that for loop we just want to apply the same operation to every item in a collection and shouldn't need to explicitly code a loop for that. So it should be possible to take advantage of higher level language constructs to express that, or define our own constructs through some form of meta programming. Is there a way to accomplish that while still retaining readable code?
  - tgv 4y ago
    Meta programming can make things worse. It can be useful for constructing/representing rule-like objects or functions, but when you start overloading basic syntactic elements, people will loose track. It was the staple trick for the obfuscated C contest, so much that it's been forbidden now, IIRC. It's really difficult to come up with something both terse, readable (and unambiguous). But the situation is not that bad, is it? A few characters too many, so be it. I find reusability a much larger problem.

The number of bytes isn’t really significant. It’s the conceptual distance between what we want to achieve and the concrete steps in the code. Lisp may be an improvement.

tgv 4y ago

But now you're already heading into much vaguer territory. Readability is also important. Very important, I would say. That requires easily identifiable markers for loops, conditions, functions, etc., something Lisp lacks. This might be a place where keyword coloring could be useful, but then we're relying on external help. Another issue is consistency. Take C, Javascript, or Go. Many loops are of the form for (var i = 0; i < n; i++) { ... } You could argue that "for i < n" provides the same information, but then you'd have to find a way to start the loop at a different offset, use a different end condition, or different "increment".

pharmakom 4y ago
> But now you're already heading into much vaguer territory. Yes programming language design is a social science (imo)
nradov 4y ago
But that's exactly the issue. In most cases with that for loop we just want to apply the same operation to every item in a collection and shouldn't need to explicitly code a loop for that. So it should be possible to take advantage of higher level language constructs to express that, or define our own constructs through some form of meta programming. Is there a way to accomplish that while still retaining readable code?
- tgv 4y ago
  Meta programming can make things worse. It can be useful for constructing/representing rule-like objects or functions, but when you start overloading basic syntactic elements, people will loose track. It was the staple trick for the obfuscated C contest, so much that it's been forbidden now, IIRC. It's really difficult to come up with something both terse, readable (and unambiguous). But the situation is not that bad, is it? A few characters too many, so be it. I find reusability a much larger problem.