At Euston there was a display, put on by Railtrack, showing some of the track relaying work going on. Not only did this video loop show off the smart yellow machine that lifts the old track, removes old ties, lays new ballast, new ties and new track (while a bunch of platelayers stand around leaning on their shovels watching it) but the video was speeded up. In the video, the machine whizzed along. To see Railtrack showing off this technology did nothing to improve the mood of those travellers who had been delayed by works.
Why are you talking about trains?
I was reminded of this when I came to Don Box's exposition of "code==data " in the new C# He shows some C# along with allegedly equivalent Scheme, like this. Here's the C#Expression<Func<int, int>> e = a => a + 1;
and the Scheme
(define e (quote (lambda (a) (+ a 1))))
Well, people who like this sort of thing will find that this is the sort of thing that they like.
Don't you especially love the way that C#'s type system, being at the "sour spot" for such things, requires the programmer to tell the compiler that the code she's writing implements a mapping from int to int? When in fact the implementation given would work for a range of types. It's a bit of a puzzle why this should be required. The way to avoid programmers having to do this is well known, and some of the leaders in that style of working even already work for Microsoft.
The syntax is (to me at least) ugly, verbose and unclear. So, I somehow doubt that putting these pieces of code next to one another is going to make anyone fall in love with the expressive power of C# Added to which, this just is not in general what anyone who knows Lisp means by "code==data ". They mean macros.
4 comments:
Keith,
Thanks for the comments. I'll scrub my examples for paren matching.
I do wonder if you've quite groked that a C# programmer doesn't need to make ANY explicit calls to get a quoted expression.
My demonstration of the explicit call technique in Line 3 was to illustrate what was happening implicitly in Line 2.
If you think I have a weak argument, I'd love nothing more than for you to just state it so I can form an adequate reply (or perhaps even a retraction).
Honestly, this blog entry makes it hard for me to tell if there's an honest technical disagreement or just a miscommunication between the writer (me) and the reader (you). You're paragraph beginning with "But that gives the game away" seems like it may be the latter.
DB
Hi Don,
I went back and read your posting (and its predecessor on this topic) again, and it looks as if it is the latter. I do find your exposition unclear. Not to mention the language facility, as I now understnad it, weak and verbose.
I've edited my post accordingly. Good catch.
Keith
Keith,
Thanks for the clarification.
You can safely remove the "allegedly" from the 2nd sentence of the third paragraph, but since you don't know me from Adam, there's no reason for you to believe me ;-)
I may do one more follow up to make the exposition even clearer.
As to the actual thrust of your piece, I too wish C# didn't require you to name types in such a verbose manner. It's ironic that C# 3.0 is getting ML-like type inference but that it doesn't work for this particular scenario. Sigh...
DB
Hi Don,
I see you point about the "allegedly", but until type inferencing works here, I think it can stay--there is nothing equivalent to the type declaration in the Scheme, after all.
That C# should gain inferencing (which is way cool) but that it should not work in this sort of case strikes me as more than ironic. If I were a n at all regular or frequent C# programmer I'd be hopping mad about it.
Keith
Post a Comment