3 ms·

A language that can express algorithms in few lines that are very cryptic (read: hard to read) is not very useful. Part of Arc's design philosophy is to never

A language that can express algorithms in few lines that are very cryptic (read: hard to read) is not very useful. Part of Arc's design philosophy is to never inconvenience advanced users in order to serve novice ones. Long, descriptive names help people unfamiliar with a language's operators better understand what they do, but the length can become a burden once they do know. For example, when I first started learning Arc, it would have saved me some headache if afn had been named anaphoric-function. Now I would find that a real nuisance. I love being able to invoke such a powerful abstraction with just three keystrokes. Here's an interesting exercise. This is the given solution to the Arc Challenge [1]: (defop said req (aform [w/link (pr "you said: " (arg _ "foo")) (pr "click here")] (input "foo") (submit))) What would you prefer that it looked like? If you replaced all the abbreviated names with long descriptive ones, you'd have something like: (define-operator said request (html-anaphoric-form [html-with-link (print "you said: " (argument _ "foo")) (print "click here")] (html-input "foo") (html-submit))) --- [1] http://arclanguage.org/item?id=722 http://arclanguage.org/item?id=722

deleted 16y ago
[deleted]
hasenj 16y ago
I despite long names in JavaLibrariesAndFrameWorks but I don't appreciate tla aop (three letter acronyms all over the place). Your second code snippet is actually much more pleasant to read.
- evanrmurphy 16y ago
  Sure, it's subjective. :) I forgot to mention though that the idea is to use the shortest names possible for the core language operators. That's when they're the biggest win, since you'll learn those well enough not to need descriptive names, and they cut program length more substantially since they're used so often.
  - hasenj 16y ago
    Right, and I agree with that. I prefer = over define. The problem comes when everything is "inlined". (def color (r g b) (with (c (table) f (fn (x) (if (< x 0) 0 (> x 255) 255 x))) (= (c 'r) (f r) (c 'g) (f g) (c 'b) (f b)) c)) This is the first thing in html.arc I can't make sense of it, it's way too terse. This is probably why python doesn't have a proper lambda expression. EDIT: After some pondering, I see what it does .. An equally terse implementation in python: def limit(n, lower, upper): if n < lower: return lower if n > upper: return upper return n def color(*args): return dict(zip("rgb", [limit(c, 0, 255) for c in args])) >>> color(10, 20, 30) {'r': 10, 'b': 30, 'g': 20} This is a lot clearer, without sacrificing conciseness: def color(*args): rgb_values = [limit(c, 0, 255) for c in args] return dict(zip("rgb", rgb_values)) By simply getting the inlined list comprehension outside the dict expression, the whole thing becomes 10 times easier to read: "Ah, it's mapping 'rgb' characters to rgb values."

deleted 16y ago

[deleted]

hasenj 16y ago

I despite long names in JavaLibrariesAndFrameWorks but I don't appreciate tla aop (three letter acronyms all over the place). Your second code snippet is actually much more pleasant to read.

evanrmurphy 16y ago
Sure, it's subjective. :) I forgot to mention though that the idea is to use the shortest names possible for the core language operators. That's when they're the biggest win, since you'll learn those well enough not to need descriptive names, and they cut program length more substantially since they're used so often.
- hasenj 16y ago
  Right, and I agree with that. I prefer = over define. The problem comes when everything is "inlined". (def color (r g b) (with (c (table) f (fn (x) (if (< x 0) 0 (> x 255) 255 x))) (= (c 'r) (f r) (c 'g) (f g) (c 'b) (f b)) c)) This is the first thing in html.arc I can't make sense of it, it's way too terse. This is probably why python doesn't have a proper lambda expression. EDIT: After some pondering, I see what it does .. An equally terse implementation in python: def limit(n, lower, upper): if n < lower: return lower if n > upper: return upper return n def color(*args): return dict(zip("rgb", [limit(c, 0, 255) for c in args])) >>> color(10, 20, 30) {'r': 10, 'b': 30, 'g': 20} This is a lot clearer, without sacrificing conciseness: def color(*args): rgb_values = [limit(c, 0, 255) for c in args] return dict(zip("rgb", rgb_values)) By simply getting the inlined list comprehension outside the dict expression, the whole thing becomes 10 times easier to read: "Ah, it's mapping 'rgb' characters to rgb values."