Wasn't McCarthy working on a model that's more elegant than Turing machines?
As far as axioms go, you can't get simpler than the Turing machine: it doesn't even have a notion of a variable, let alone types or strings.
I don't know about the history of Lisp other from what I've read from you, but it seems what McCarthy was working on was a more elegant model, rather than an "axiomatically pure" model.
Arc on the other hand, is trying to compete with Ruby and Python.
I believe his goal was a formal model of computation that was also good for expressing algorithms. Plus eval probably seemed like a neat trick. We take it for granted, but imagine how pleasing that must have been to think of.
I'm not trying to compete with Ruby and Python. If I were I'd be recruiting armies of people to write libraries.
I meant "compete" in terms of expressiveness. And actually that's not the only thing.
A language that can express algorithms in few lines that are very cryptic (read: hard to read) is not very useful.
I think were python hit the mark spot on is the adoption of the idea that "programs should be written for people to read, and only incidentally for machines to execute".
And where ruby hit it spot on is "optimizing for happiness", I particularly like Matz's his idea about "harmony"[1].
Matz> I believe consistency and orthogonality are tools of design, not the primary goal in design.
If the language forces you to carry the compiler in your brain as you try to read code, it's a bad idea.
One of the things that annoy me about lisp as a beginner, and maybe this only because I'm a beginner, is that I always have to manually compile code into the syntax tree.
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]:
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.
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."
Lambda calculus is actually simpler than Turing machines. There are only two primitives: function definition and application. You can use that to express any computable function, including booleans, conditionals, integers, arithmetic, strings, etc.
Comments
Wasn't McCarthy working on a model that's more elegant than Turing machines?
As far as axioms go, you can't get simpler than the Turing machine: it doesn't even have a notion of a variable, let alone types or strings.
I don't know about the history of Lisp other from what I've read from you, but it seems what McCarthy was working on was a more elegant model, rather than an "axiomatically pure" model.
Arc on the other hand, is trying to compete with Ruby and Python.
I believe his goal was a formal model of computation that was also good for expressing algorithms. Plus eval probably seemed like a neat trick. We take it for granted, but imagine how pleasing that must have been to think of.
I'm not trying to compete with Ruby and Python. If I were I'd be recruiting armies of people to write libraries.
I meant "compete" in terms of expressiveness. And actually that's not the only thing.
A language that can express algorithms in few lines that are very cryptic (read: hard to read) is not very useful.
I think were python hit the mark spot on is the adoption of the idea that "programs should be written for people to read, and only incidentally for machines to execute".
And where ruby hit it spot on is "optimizing for happiness", I particularly like Matz's his idea about "harmony"[1].
If the language forces you to carry the compiler in your brain as you try to read code, it's a bad idea.One of the things that annoy me about lisp as a beginner, and maybe this only because I'm a beginner, is that I always have to manually compile code into the syntax tree.
[1]: http://www.artima.com/intv/ruby2.html
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]:
What would you prefer that it looked like? If you replaced all the abbreviated names with long descriptive ones, you'd have something like: ---[1] http://arclanguage.org/item?id=722
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.
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.
Right, and I agree with that. I prefer = over define.
The problem comes when everything is "inlined".
This is the first thing in html.arcI 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:
This is a lot clearer, without sacrificing conciseness: 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."Lambda calculus is actually simpler than Turing machines. There are only two primitives: function definition and application. You can use that to express any computable function, including booleans, conditionals, integers, arithmetic, strings, etc.