All the Perl that's Practical to Extract and Report
use Perl Log In
Ovid (2709)
(email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)
Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.
Arc is Released - So What?
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.
--Larry Wall in cons.c from the perl source code
List nit (Score:1)
Re: (Score:1)
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: (Score:1)
(let ((foo '(1 and 2)))
`(this is a new list with
That evaluates to (this is a new list with 1 and 2 in it). It amuses me anyway
Re: (Score:1)
(defun foo (a b) (- a b)) (let ((foo (lambda (a b) (+ a b)))) (foo 2 1) ; 1 (funcall foo 2 1)) ; 3Oh well, you can't have everything.Re: (Score:1)
Re: (Score:1)
... 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: (Score:1)
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: (Score:1)
ASCII, car/cdr (Score:1)
Next, car and cdr. Most LISP programmers I've talked to (including myself), prefer car and cdr to head and tail or first and rest. First, head/tail and first/rest don't make much sense when applied to an improper list (i.e. (cons 1 2)). car/c
Re: (Score:2)
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 s
Re: (Score:1)
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 (Score:2)
Re: (Score:1)
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
Not for Everyone (Score:2)
Re: (Score:2)
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: (Score:1)
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 th
Re: (Score:2)
Superstar programmers are born, not made. I don’t think there’s any way to change that.
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.
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
Re: (Score:1)
You have not contradicted a single thing I said.