Paul Graham has finally released Arc. After reading about it, I'm quite disappointed. I have a lot of respect for Paul Graham, so this surprised me. Here's a perfect example of why I'm disappointed:
Which is why, incidentally, Arc only supports Ascii. MzScheme, which the current version of Arc compiles to, has some more advanced plan for dealing with characters. But it would probably have taken me a couple days to figure out how to interact with it, and I don't want to spend even one day dealing with character sets. Character sets are a black hole. I realize that supporting only Ascii is uninternational to a point that's almost offensive, like calling Beijing Peking, or Roma Rome (hmm, wait a minute). But the kind of people who would be offended by that wouldn't like Arc anyway.
Not supporing Unicode? This is not merely a matter of being offended. It's a matter of "can I use this code or not?" The very next sentence reads "Arc embodies a similarly unPC attitude to HTML." ASCII-only isn't "unPC", it's stupid. It means, right off the bat, that many, if not most of the world's programmers can't use it for any serious work. By his own admission this project he's talked about for years would only have been delayed a couple of days. I'm flabbergasted.
So what is his "unPC attitude to HTML"?
The predefined libraries just do everything with tables. Why? Because Arc is tuned for exploratory programming, and the W3C-approved way of doing things represents the opposite spirit.
In other words, Arc is a toy and not to be used for real projects (to be fair, Graham himself describes Arc as for "exploratory programming", whatever that is). I assume we could write our own proper HTML libraries, but Graham seems to be encouraging developers to do the wrong thing
I can forgive the tables since one can presumably work around it, but failing to spend a couple of days resolving the ASCII-only issue is disappointing.
But what does Arc code look like? Maybe it's clean enough that we should forgive its sins.
(def firstn (n xs)
(if (and (> n 0) xs)
(cons (car xs) (firstn (- n 1) (cdr xs)))
nil))
Right. Now we have to try to explain to new Arc programmers that the origins of "car" and "cdr" are "Contents of Address of Register" and "Contents of Decrement of Register" respectively (which makes sense if you know the historical reasons). Why? Why not just call them "head" and "tail" and make it simple? This compiles down to Scheme and this could have been built-in up front. Instead, historical baggage which confuses new programmers has been left in. Here's what I would have liked to have seen:
(def first_n (n list)
(if (and (> n 0) list)
(concat (head list) (first_n (- n 1) (tail list)))
nil))
OK, switching "cons" to "concat" may not be that big of a deal, but with the above code, programmers who don't know the language have a much better chance of understanding it. Further, note that I've changed the variable name xs to list. Is see xs used all the time in languages like Prolog, Lisp and Haskell, but these point to mathematical underpinnings and to my mind, are mental speed-bumps. While this is certainly something a programmer can change, examples should be written to reduce the cognitive load so long as they don't sacrifice correctness.
I'm also not convinced about the lack of support for OO programming in Arc. He has a fascinating follow-up about confusion in the OO world, but his primary justification (first link in this paragraph) seems to be:
I personally have never needed object-oriented abstractions. Common Lisp has an enormously powerful object system and I've never used it once. I've done a lot of things (e.g. making hash tables full of closures) that would have required object-oriented techniques to do in wimpier languages, but I have never had to use CLOS.
If you read that carefully, that almost sounds like he's saying "OO programming isn't important because I don't use it." I have never done a lot of purely functional programming and after having read HOP (Higher Order Perl) and worked through the examples, I can sympathize with Paul Graham's position, but given what I've seen in Arc, I'm far less ready to agree with him.
Re:List nit
chromatic on 2008-01-31T19:20:36
That's why you have quoting... er... that's why function application only applies to the first element of a cons... er... that's why you have Lisp-2... er... sigils are ugly, darnit.
Re:List nit
jrockway on 2008-01-31T21:53:04
Incidentally, Lisp uses the @ sigil for list interpolation. Example:
(let ((foo '(1 and 2)))
`(this is a new list with,@foo in it))
That evaluates to (this is a new list with 1 and 2 in it). It amuses me anyway:) Re:List nit
jrockway on 2008-01-31T22:08:21
This isn't a problem. Symbols get their values from different "slots" depending on context. When you write (list 'foo 'bar), list is called as a function. When you write (setq list 42) and then (+ list list), you get 84. It's very clear.
The only problem is calling a function saved in the value slot of a symbol:(defun foo (a b) (- a b))
(let ((foo (lambda (a b) (+ a b)))) (foo 2 1) ; 1 (funcall foo 2 1)) ; 3
Oh well, you can't have everything.Re:List nit
jrockway on 2008-01-31T22:09:00
Ugh, apologies for the worthless formatting.Re:List nit
chromatic on 2008-01-31T22:38:54
This isn't a problem.... not for the compiler anyway. Some of the rest of us like to optimize for the slower parts of the process, often known as wetware.
Re:List nit
jrockway on 2008-02-01T02:32:36
FWIW, Perl suffers from this problem, sort of:
sub foo {}
my $foo = sub {};
foo();
$foo->();
my $foo = "hello";
$foo->(); # death
Anyway, lisp is what it is. It's straightforward to write a macro such that:
(with-sigils (&foo) (foo $foo))
expands to
(progn (funcall foo) (foo foo)))
If you really care I'll try it out and blog the code:) Re:List nit
runrig on 2008-01-31T23:13:40
Disclaimer: the last Lisp I used was AutoLisp...many years ago. I don't remember if it behaved the way you describe or not. I later (after posting) figured this wouldn't be a problem in this instance anyway because "list" was (dynamically?) scoped to the function. But I still don't think I'd call a variable "list" in the language (w/o sigils):-)
Re:ASCII, car/cdr
schwern on 2008-02-01T07:28:11
Was that reply a joke? I hope it was, but in case it wasn't...PHP, Ruby, Perl 5.6, etc., etc. don't support Unicode. Those saw plenty of use anyway.Perl 5.6 does support Unicode... badly, but it does support it. And what was one of the major things we put into 5.8 (begun in 2000) despite it causing vast amounts of internals grief? Unicode. Also keep in mind that 5.6 development started in 1998 when you could still fool yourself that ASCII was all you needed. Even so, the diverse array of Perl developers recognized it was necessary even if it was very painful.
It's not that Arc doesn't support Unicode, it's that Paul dismisses Unicode. Some sort of spurious feature like syntax highlighting. If Paul had said something like "the first release of Arc doesn't support Unicode yet" that would be something else entirely. It's obvious he just doesn't get it...PG mentions on his site that people wouldn't have complained about this if he hadn't brought it up. I agree; this is whining about the bikeshed color....and neither do you.
Of course you agree that ASCII is fine, YOU SPEAK ENGLISH!
Perhaps you're embedded so deep inside America that you haven't had to input or output anything but English in your programming, but how can you dismiss programmers in most of Europe, all of Asia and South America? Even English speaking programmers in the UK for example have to talk with the rest of Europe. Canadian programmers have to deal with French (sorry, fr-ca). And sometimes, yes, even Americans have to deal with something other than English.
How can this possibly be the 100 year language? You can't pretend the rest of the world doesn't use computers any more and you can't pretend they're all going to do it in English. They just won't use your language. And anyone who has to work with folks outside America won't use it either.Most LISP programmers I've talked to (including myself), prefer car and cdrWho cares what LISP programmers think, they're already trained to think in LISP! The 100 year language should not be thinking about the current generation or programmers but the next generation of programmers and the one after that and after that. Forget the 100 year language, any new language should be thinking about how to make sense to the programmer not already steeped in their culture.
And, I admit this is a low blow, but if your language's audience is existing LISP programmers... let's just you're fighting for a slice of an awfully small pie.
Ok, don't call it head/tail but call it something that's not an acronym for a function on a piece of hardware that's older than most programmers today and nobody's ever used. Might as well just make up random three character strings for all the use it is remembering what it does.
Re:ASCII, car/cdr
chromatic on 2008-02-01T08:23:23
Even English speaking programmers in the UK for example have to talk with the rest of Europe.English speaking programmers in the UK who want to get paid have to deal with the Euro symbol, which isn't in ASCII. They can't fall back on the pound symbol either.
Re:ASCII pedantry
grantm on 2008-02-01T20:13:28
Actually, programmers in the UK are more likely to be paid in British pounds. Of course the symbol for that (£) isn't ASCII either. Even Americans can't render the symbol for cents (¢) without venturing outside ASCII.Re:ASCII, car/cdr
Aristotle on 2008-02-01T11:20:13
Ruby, Perl and Python are all at least as old as Unicode itself. PHP is PHP. What excuse does Arc have to dismiss Unicode as “unimportant”?
And I agree entirely with what Schwern said: if Paul Graham had written that Unicode doesn’t concern him now, but he’ll get around to it before he starts telling people to use Arc for serious work, I wouldn’t have said a peep about it.
F.ex., who cares if he thinks using tables for layout is somehow more exploratory and agile. No one has to buy that crap. Lack of Unicode support is an entirely different category.
In many ways, it is perfectly analogous of saying “I don’t want to spend even one day to figure out how to support floating point maths.”
Re:Not for Everyone
Ovid on 2008-02-01T17:39:43
Good point. I disagree with him on that, but that's possibly due to my naive fantasy of wanting to help average developers become good developers. This might not be possible for many (most?) of them. I really don't know.
Re:Not for Everyone
Aristotle on 2008-02-01T18:49:22
Superstar programmers are born, not made. I don’t think there’s any way to change that. It takes a certain mental predisposition that does not appear to be teachable; either your mind works that way or it does not.
Nevertheless, if you look at spreadsheets, you’ll see that by reducing the minimum required ability for abstraction and increasing the amount of computation state that's tangibly visible, people with little programming skill can be empowered to harness computing machines for their own purposes.
Another point is the one that MJD made during his Program Repair Shop and Red Flags talk at YAPC::Asia 2k7. On a slide showing some awful copypaste, he commented “You don’t have to be smart to notice this. You don’t even have to be sober.” You don’t have to be extraordinarily skilled in order to write good code; you just need to get into the habit of going back and editing once you’re done writing – just like when you write an essay.
I don’t think there’s any cognitive dissonance in wanting skilled programmers to have powerful tools OT1H, and wanting to empower even ordinary people who have no knack for programming whatsoever to be able to extract some use out of their computers OTOH.
Re:Not for Everyone
schwern on 2008-02-15T04:38:30
As someone who didn't do programming until their 20s, I must call bullshit. It's sort of like the people who think that if you haven't written your first masterpiece at age 9 you can never learn to play the piano.Superstar programmers are born, not made. I don’t think there’s any way to change that.
It takes a certain mental predisposition that does not appear to be teachable; either your mind works that way or it does not.I think you have reversed the cause and effect. We teach algorithms and data structures, but we don't teach how to think like a programmer. We barely examine it, partially because we're bad at people. Partially because we have the idea that it can't be taught, so why bother trying?
This is why (currently) the best programmers are self-taught, they're self-selected for motivation and successfully having learned how to think like a programmer. If they didn't successfully learn, lacking a CS degree to fool people into thinking otherwise, they wouldn't be programmers.
Some evidence for this can be seen in just how much retraining one has to do of a fresh CS graduate when they get their first job. They have not been taught how machines work, but not how to think like a programmer.
Programming has also traditionally been very close to the metal calling for a very specialized set of skills and knowledge and a strong math background. As we slowly pull up and away from that and programming becomes less about how the machine works and more about conceptual translation. It's about generalizing and encoding real-world procedures down to a fixed set of steps with all the necessary extra work for when things go wrong. Those are two things which can and are taught, just not traditionally to programmers.:) Re:Not for Everyone
Aristotle on 2008-02-15T05:57:19
You have not contradicted a single thing I said.