It's Like Déjà Vu All Over Again
"You could probably waste an entire day on the preceding links alone. But why take chances? We also give you Paul Snively..." — John Wiseman, lemonodor
Hey, David McCusker says he'd hack Scheme with me! I keep forgetting that David likes Scheme. Hmmm. I wonder what would be an interesting-enough project to do?
11:41:35 PM
Gah. XML and XQuery make my teeth hurt. There's no distinction between data and metadata in XML, so it's hard to come up with an effective model along the lines of the relational algebra or what have you for XML.
The more I work with XML, the more I realize that RDF really is the right thing, and RQL is the right query language. Highly recommended.
10:37:59 PM
Ted Nelson: "Today's nightmarish new world is controlled by 'webmasters', tekkies unlikely to understand the niceties of text issues and preoccupied with the Web's exploding alphabet soup of embedded formats." [Scripting News]
I continue to wonder if there isn't some low-hanging fruit here. I'd love a pointer to a short list of features of Ted's ideal environment. I know transclusion will be one of them. What are the other, say, four or five gotta-haves? And then what's the simplest thing we could do to implement those features that could possibly work? It's important to think in terms of gluing together existing infrastructure, otherwise we'll never get off the ground. Off the cuff, potentially applicable stuff sounds to me like:
I'm now convinced that one can architect a system in accordance to the principles of REST and then implement that system using RPC style, HTTP transport, POST binding, SOAP. [Sam Ruby]
This really opened my eyes to look for what REST is really about. If I understand it correctly a RESTful RPC system has a small API. What really happens depends on the parameters, ideally some kind of (global) id. In most cases the API is something like: read, create, change and delete in one form or another. Translated to programming terms it is like having a huge set of global variables (the state of the program) which are read and written directly. Sounds like REST violates a lot of rules of both functional and object oriented programming.
REST offers no such violation, at least of functional programming. On the contrary, REST's insistence on the primacy of URIs helps to ensure its relationship to the functional paradigm: if a URI maps uniquely to a resource, as is intended by the URI specification, then either HTTP GET or HTTP POST are "function calls" in the sense that, given a "function name" (the URL itself) and collection of parameters (URL parameters or form fields), the "function" returns a single "result" (the HTTP response). This would make HTTP PUT the equivalent of binding a lambda expression to a name.
To continue the analogy, when Paul Prescod points out that one of the benefits of REST is cachability, he's being a functional programmer whether he realizes it or not (and I hasten to add that he's probably well aware of the fact). In functional programming, caching often goes by the more exotic-sounding name of "memoization," and it's a given in functional programming circles that "memoization" is a very useful optimization technique that only works in the absence of side-effects—exactly the same argument that Paul makes for REST!
It's hard for me to understand, then, how Sam's claim can be correct: if you develop an RPC interface that only exposes read(), create(), change(), and delete(), then you have indeed create the situation that you describe, because these interfaces lose the namespace-uniqueness property that the URI imposes, and then you do have the global-soup problem, in violation of some OO and, especially, functional principles. If, however, you can find another way to overcome that, you can get back to REST principles. But by that time your RPC is probably looking pretty weird, and you may just wish to use your favorite HTTP library and URI-to-code mapping system (CGI, JSP, ASP, EIEIO...) and get it over with.
10:14:59 PM
Dave comments about REST as a programming style. If there's something left of the AppleScript discussion online, I'd like to read it. I'm in the REST camp because I think it's less work. Reducing the number of verbs in the Manila-RPC interface, with the advancedPrefs API, was a big improvement IMHO.
My recollection of this is a bit different from Dave's, but that may just be a historical accident: I don't recall any explicit debate over nouns vs. verbs in AppleScript. As I recall, the few-verbs/several-nouns phenomenon was a side-effect of a strong desire to support the AppleEvent Object Model, with everything that that implies. One of the implications is that developers and users could expect polymorphism: the one verb "print" would do something reasonable regardless of what it was applied to, whether that was the current selection, page 3 of document "foo," or whatever. When Dave asks "who wants lots of nouns?" relative to AppleScript and AppleEvents, it strikes me as misguided, because the work of thousands of developers ensured that there would be lots of nouns! So the question was "how can we avoid a combinatorial explosion, where N nouns times X verbs equals Y combinations for developers and users to contend with, given that N will be a large number?" The obvious answer is to make X a small number, and attempting to leverage polymorphism was—and I still believe is—an excellent means to achieve that goal.
9:57:41 PM
An adaptive computation maintains the relationship between its input and output as the input changes. This allows for efficient recomputation, when input changes. Only the relevant parts of the program have to be executed again.
This presentation explains the motivation and basic approach. Formal semantics and the relation to modal type systems are presented.
You may also want to check out the paper Adaptive Functional Programming by Umut Acar, Guy Blelloch, and Robert Harper (ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, Portland, January 2002).
Fascinating stuff! This almost sounds like a kind of real-time, online partial evaluation process (and I suspect, just from the name, that the connection to "modal type systems" treats that similarity somewhat explicitly).
Hmmm. I also suspect that there's a rather protracted rant here in connection to the REST vs. RPC debate. I'd already started thinking that I could demonstrate to Paul Prescod that he is, in fact, a functional programmer in OO clothing due to his promotion of REST. But I need to gather my arguments further before presenting them. This paper (from IU, my alma mater) will likely figure into the discussion.
9:35:28 PM
A book draft, based on lecture notes Robert Harper used at CMU, and Andrew Appel used at Princeton University.
The book covers all the usual topics (inductive defintions, concrete and abstract syntax, substitution, type systems, continuations, etc.) Of interest may be the discussion of cost semantics, strict semantics in lazy languages, and the detailed discussion of subtyping.
Most of the book talks about pure languages, and uses MinML.
The presentation is a bit more formal than in most introductory textbooks, and many important ideas are presented and proved as theorems.
This sounds like another excellent introductory text. Given my own personal bent, I imagine I'd like the rigorous treatment—I think the "why" of programming language constructs is at least as important as the "how" of them. Still, it could end up being too dry, although The Little Schemer isn't the least bit dry, but that doesn't stop it from having the reader derive the applicative-order Y combinator along the way.
9:21:58 PM
Still more great material from the estimable Paul Prescod:
Based on my admittedly limited experience, it is a myth that type inferencing has similar characteristics to dynamic typing in terms of ease of learning, productivity, fun etc. I haven't used the newer type inferencing languages but programming in ML was, in my experience, exactly as type-constraining as programming in Java except that it had better generic programming facilities. Except that in Java when I got error messages they had real type-names in them (because Java forced me to make up types) whereas ML would use synthesized names in the messages. I don't think there is a free lunch. Type-inferred languages may look like they combine the advantages of dynamic typing and static typing but I think that it is more accurate to say that they have their own, distinct advantages and disadvantages.
I haven't spent nearly as much time with Standard ML as I should (having been seduced by Objective Caml and Oz), but I wasn't aware that ML synthesized types. Again, the only time I even had to think about them was when I had inadvertently written something that was ambiguous. Regardless, I continue to maintain that type inference does indeed combine the advantages of dynamic typing (lack of declarations and bookkeeping on the programmers' part) and static typing (stronger proof statements possible by applying category theory, efficient compilation on stock hardware).
It is nevertheless true that someone who is accustomed to a language doing what amounts to implicit type-casts for them will find the ML family not as "type forgiving" as they are accustomed to. Reasonable people can, and do, reasonably disagree as to whether this is a good thing or a bad thing.
Second, I think that we all tend to live on a spectrum. If you only care about being mainstream and sharing code with other programmers then you use C or Java (in the open source world, maybe VB or COBOL in some environments). If you only care about using a language with the most recent advances in computer science, you use something like Oz or E. When I am programming something small, for fun, I may experiment with different languages. When I am programming something large, I am more interested in popularity, and in a kind of egalitarianism that says that if I code in a readable style in a well-known language then maybe a high school student will pick up my code and learn from it or extend it. Java or C will give me the popularity but not the egalitarian vibe, so I prefer Python. (at least it is not my personal opinion that either C or Java are acceptable first languages, no matter what some job-oriented teachers may think...I also to think that a good first language should use primary school math notation for primary school math, so that excludes Scheme. ) I understand that other people will have different goals for their code.
I'm inclined to think that we're in vehement agreement here, although I don't find the argument regarding prefix vs. infix notation at all compelling. Briefly, there's more to programming than math, and consistency of expression, particularly in a first language, seems more important to me than familiarity of the mathematical subset of the language.
All of this ignores an important point that Paul Graham made, however, which is the continued presumption that you can develop the same things in any language, not as a theoretical matter (Turing equivalence, and all that), but very definitely as a pragmatic matter. If the problem you're trying to solve can be solved equally well in Perl, TCL, Python, Scheme, Haskell, Oz, E... then by all means, make your tool selection based on criteria other than fitness to the task. But a large, complex, secure system will benefit tremendously from E. A telephone switching system will benefit tremendously from Erlang. And so on.
So anyhow, I live at the point on the spectrum where I prefer not to sacrifice much power for mainstream usage nor abandon the possibility of being in the mainstream. In particular, I would like Python to be a language that mainstream bosses and programmers can both be happy with. We're making slow but steady progress. [YACCS Comments for It's Like Déjà Vu All Over Again]
Wholeheartedly agreed. Once again, as a matter of personal taste, in descending order of preference, I would list the following scripting languages: Lua, Ruby, Python, TCL, and Perl. So you can see that I hold Python in higher regard that either of its most popular competitors, and that, true to form, the only languages I like better seem a bit more theoretically-based, appealing to the Computer Science student in me, vs. the practicing programmer. And I have the impression that you understand and appreciate that tension and just prioritize differently than I do at this particular moment. Still, once again, I appreciate the opportunity to have the discussion, as it helps me to clarify my own thinking on the subject a great deal, and I've seen several posts now that indicate that others are finding the discussion helpful as well, so thanks for that!
9:09:54 PM
