Sub Ubi

As usual, I wrote a post today, and saved it as a draft. I have two dozen or more of these. In some ways, it’s a self-edit. In others, it’s because the ideas aren’t there yet. I want to come back to the thoughts, but I think time and action will do where words will fail.

In the meantime…

James Gosling has a weblog.

From the Gosling blog, a sad story of the end of a grizzly-related research project in the wilds of Russia.

And via mamamusings, gangstories.com. A short-lived, powerful weblogging project.

I spent yesterday programming in Scheme; today, I’m hacking things together in Java. I was happier yesterday. Then again, I don’t know the Java APIs well enough to know where to start most of the time, which makes for a lot of tedium.

It is a long standing debate in Computer Science as to which programming language is the best for beginning programmers. In the early 60’s, students at Cornell were programming in CORC, a language designed as a pedagogic replacement for PL/1 in introductory courses. At the same time, DITRAN was being developed at the University of Wisconsin: a tool for running FORTRAN programs that (among other things) gave the programmer errors in terms of the code they wrote, not the assembly language produced by the tool; that was a big feature in 1965, one we take for granted today.

Both of these languages were developed for the sole purpose of teaching programming to novices. They were not for developing operating systems, writing device drivers, video games, word processors, or anything else. The languages were designed for teaching, because both the students and the instructors were new to the whole “programming a computer” thing. This was, for almost everyone involved, something they had never done before.

Today, we have thousands of languages. Literally. Thousands. If you believe even one ounce of the Sapir-Whorf Hypothesis, you’re going to have to believe that the choice of first programming language will affect how a novice programmer thinks about the programs the write and the way they express ideas in code. As a journeyman programmer in more than one language, I know the way I shape solutions to problems is definitely shaped by the language I’m using; to believe it is any different for a beginner is foolish.

But this isn’t debated in Computer Science circles today. It’s accepted. And I’m happy that it is. What bothers me is the languages we teach introductory programming with are not designed for novices. The tools that the students use are not designed for novices. Furthermore, even if you use a tool designed for a novice with a language that isn’t, it is difficult to patch all the leaky abstractions that will persist despite your best efforts.

My use of leaky abstractions is akin to what Joel Spolsky wrote on his weblog on November 11 of 2002.

A leaky abstraction is when something gets out from under the covers (oh my!). And from a pedagogical standpoint, leaky abstractions make for difficult questions at times that you’d really rather not deal with them. Consider two programming languages:

Language A	Language B

The relatively small size of those circles is actually a visual lie. Both languages are actually much, much bigger. These circles represent the size of language that a novice should encounter. These are the basic nouns, verbs, and phrases that a beginner learning Language A or Language B should know. I am, you are, we are, they are, he is, she is, … of course the English language is huge, but we start with conjugations of critical verbs and by learning simple phrases: Hello, my name is Matthew.

By analogy, that’s where I’d like to start. Unfortunately, we have a problem with Language A; A was designed for use in industry, writing huge pieces of enterprise software. It has an inconsistent syntax, and even though it aims to be self-consistent, but rules you learn early on have to be broken to write more expressively. Rules grammar change: English Traditional Replaced To Be New Syntax With. [The Onion] This becomes a problem for us when we want to start novices off with just a small part of the language.

Language A	Language B

In Language A, it turns out that you can’t say anything meaningful without reaching for other parts of the language. While we want to start off with simple bits of code, we must include bits and pieces of the full language to make even the simplest of sentences. Language B, however, is a complete core. We can do simple things simply to start, and if we want to say more complex things, we can. As we grow the language, we don’t have references out into parts of the language we don’t know; instead, we only have references back to the parts of the language we have already learned.

The inability to say simple things simply in Language A is a leaky abstraction. The inability to keep the complexity of the whole language under the covers kills us pedagogically (the blue arrow, below). What should we teach first? Where do we start to build a shared conceptual vocabulary that both the instructor and student can use? Where do we go next if we do manage to find a starting point?

Language A	Language B

In an ideal world, Language B would be ever expandable, so we could grow the language as we needed to. All our references would be back to things we have already learned: in learning a new verb, we don’t need to reference a verb tense we’ve never seen before, and once learned, it’s usage will never change. In time, we might even be able to develop a pedagogical ordering that makes clear to instructors what parts of the language (and the concepts they embody) should come first so as to scaffold the learning of larger and more complex ideas later.

As long as I’m dreaming, I might as well take this to completion. The important thing to remember is that the goal of a first course in computer science is to teach foundational concepts using a particular language, not to teach the language. Carpenters learn how to drive a nail before they learn the basic tenants of sound structure; pianists start with scales, not concerti. In either case, they aren’t learning about hammers and pianos, they’re learning about building and performing, using the tools of their trade.

Language B leads to Language A. Done right, it’s as simple as that. There isn’t anything wrong with Language A; it’s just not appropriate for a first course in computing. Language A was never designed for novices. It is the wrong tool for the task: instructors teaching a first course in programming are trying to teach students to drive nails and do scales, and inspire them to dream of skyscrapers and symphonies.

Language B exists to build a shared vocabulary between the instructor and the student. In learning it, a shared conceptual space is developed in which new ideas can be introduced, and a framework exists for discussing those ideas [Vygotsky]. As students explore Language A, there is a strong foundation (laid in the exploration of Language B) upon which the instructor can draw as they introduce and explain old and new ideas.

There are different methods to teaching a child how to play the piano: some involve reading, some involve listening, but they all start with the same instrument, a collection of ebonies and ivories grouped in twos and threes. The focus for a piano teacher is strictly one of methodology, as they have no option to build the tools they teach with in conjunction with their pedagogy. In computing, we are Gods of our domain; we can create any language to suit our needs, develop it carefully, over time, fully aware of it’s sole end use: to teach. Despite this simple fact, we insist on keeping up with industrial trends, and must constantly reinvent ourselves and the tools we use in the name of progress, as if the fundamental task has ever changed.

Unfortunately, this implies that we know what that task is, which we don’t. Hence the failing of a discipline that continues to turn a blind eye to the importance of high-quality educational research.

A must read:

• Growing a Language, by Guy Steele.
  I saw Guy give this talk at Indiana University; he spoke for 45 minutes on the importance of extensibility in programming languages, constraining himself to words of one syllable. He would only use words of more than one syllable if he had previously defined them using words of one syllable. To date the most riveting talk I’ve seen in Computer Science, and an absolute must read in my opinion.

Pedagogical environments:
Each of these links leads to a list of articles and papers related to the environment or project described.

• BlueJ, a pedagogical environment for Java.
  An excellent piece of software. To an certain extent, Java is rife with leaky abstractions (from a learning and teaching perspective); Java is, in my mind, Language A. While it is possible for BlueJ to patch many of those (which it does well, and continues to do better every day), there will always be leaky abstractions.
• DrScheme, a pedagogical environment for Scheme.
  Another excellent piece of software. The PLT group have generally managed to build Language B, made possible by the simplicity of Scheme’s nature.
• DrJava, a pedagogical environment for Java in the spirit of DrScheme.
  I have only seen one presentation of DrJava, and have never used it. I believe it is fair to say that DrJava does not help patch the leaky abstractions in Java, but instead takes a path of full disclosure: it provides an environment for students to explore the language, warts and all.
• Helium, an environment for learning Haskell.
  I’ve never seen it before, and just learned of it yesterday. Given the dates on the documents available, it is much younger than either BlueJ or DrScheme.
• The CS-1 Sandbox, a pedagogical environment for C.
  It is unlikely that this particular environment will be developed further; the study of it was the subject of Peter DePasquale’s PhD dissertation.

Sweeping criticism:
In the case of all of these projects, the same fundamental problem exists: none of these projects has been developed hand-in-hand with research. While they are excellent, and driven by smart people, none of them are explicitly (or even implicitly) driven by research. The blue arrows driving all of them are based on experiential suppositions, not research findings. Peter’s work represents the only environment that has been empirically studied, but my dream of such an environment being developed hand-in-hand with research still remains.

• Many other articles
  If you are interested in reading more in-depth about pedagogical languages, environments, and related issues, all of these articles dance around the topic to some degree.

By and large, I’m unimpressed with the quality of literature research that takes place in most papers in the area of CS education.

The papers I posted earlier are largely from Google searches and the ACM Digital Library. Neither was there any real search of the IEEE in my process, nor any stack crawling. In short, I looked up all the papers I could quickly and easily search and download, because I wanted information fast.

I found a great deal of interesting stuff regarding pedagogical programming languages, pedagogical programming environments, the quality of compiler error messages and the like. As I read through these papers from the 60’s, 70’s, and 80’s, I wonder why more of them haven’t been cited by papers written in the late 90’s and early 00’s? Given how easy it is to search on these topics, and how easy it is to download and print papers related to computing, why can’t authors at least do a half-assed literature review, instead of one where they fail to mention work that was exactly like theirs, published in the same forum, just 6 years previous?

Every new language that hits the scene (be it C, C++, Java, C#, …) has caused a shift in the first course in computing (CS1, as it is sometimes called). Pascal gave way to C and C++, which yielded (in a remarkably short time) to Java, and now people are looking at C# for a first course in OOP; speak to me not of the issue of “programming paradigm” even! Sadly, with every shift, we loose the tools and experience that scaffold the novice programmer. Years ago, there were some excellent tools for supporting students programming in Pascal; oops! Gone! Then, we built tools to make programming in C a better experience, interpreters and debuggers to support novices as they explored the language. *POOF* Gone.

The latest generation of tools don’t always provide adequate cover for the lessons learned of old. It’s as if every language is different, and every generation knows best; CS-ED really needs to get it’s act together. I’m glad industry is made up of brilliant professionals who can switch from one tool to another every 6 to 8 years, but it takes time to develop, test, and revise educational tools, not to mention materials to support learning, rubrics, and everything else that is necessary for the educational enterprise.

Later, or tomorrow, I’ll write about a conversation I had yesterday that does a nice job of coming at some of these issues from a more disciplined perspective, and provides some interesting food for thought, independent of whether or not everyone has done an adequate review of the literature.

I’m not typically prone to hysterics, but when I find a frickin’ huge M&M that looks like it’s been on growth hormones since it was just a wee bit o’ chocolate, I react.

I mean, dude! It’s the size of a £1 coin! And look at that nasty little runty one that came out of the bag at the same time with it. Elch. Does Mars expect me to eat that nasty little thing? And what about M&M-thra?

Wow. I don’t think I can post anything else today. Nor do I know if I want to eat any more M&Ms…

While at home in the States, I spent some time trying to figure out how to cut my parent’s combined telco costs. In particular, I wondered what I could do to improve the situation both at home and my father’s office; you’re looking at two landlines, dialup on both, and no mobile phone usage. Both have unreasonable long distance bills, and at the end of the day, the internet connectivity isn’t that great.

My wife’s father has it even worse: the monthly on his landline is higher in his neck of the woods, the lines are older and noisier, and neither DSL nor cable will ever make it to his house. I ran a lot of numbers while at home on my parent’s situation, and at the end of the day, the phone companies have everyone by the nuts: you can’t beat the system.

Let’s take a look at the second scenario, where you live too far away for broadband:

1. The local telco has a monopoly,
2. The local lines are so noisy you get very slow dial-up, and
3. Broadband will never reach outside the 3 mile “loop.”

On top of this, you want a mobile phone for emergency use. In the UK, you can get a Pay-As-You-Go phone: you buy the phone, and “charge” the phone by putting money onto it. Now, you could buy the phone used for as little as £5 or £10, and put £10 in credit on it. You’d end up with a phone that was usable for (depending on time of day, etc.) good for 20-40 minutes of usage before you ran out of cash.

The most important feature of this scenario is that you don’t pay for time you don’t use. Put another way, if you don’t use the phone, you’ll always have £10 worth of credit on the phone. Period. Six months go by without using it? You still have credit.

Now, in the US, you can’t get Pay-As-You-Go. Instead, you can get an impoverished phone that you pay $15 per month for, and you get a limited number of minutes (or your range is limited, or the numbers you can call is limited, etc.). If you don’t pay in a given month, well… you can’t. I mean, not without the collection agency coming to your door and asking where your monthly check to Sprint, Verizon, or whatever other TelCo is ripping you off.

Putting some numbers on this:

You’re out $85/month in telecommunications costs, and for what? A noisy dialup connection, expensive long distance, and a mobile phone you almost never use. (In the real world scenario I’m actually trying to solve this problem for, the long distance charges are slightly lower, but they aren’t unreasonable or unimaginable).

What can we do with that $85? How else could we use it that didn’t require us to pay a $35 tax just to have a landline, so we can use a lousy dialup service?

GPRS
The solution is ugly, but it might cut costs in several categories at once. GPRS stands for General Packet Radio Services, and a number of mobile phones in the states (and a number of providers) now use it for data transmission. If we know that

1. We want a (pair of) mobile phone(s),
2. We want to eliminate long distance charges,
3. We want access to the WWW, and
4. Our access speed already sucks

then having to suffer downloading webpages over a mobile phone might not be that bad. Again, I think the numbers are going to tell us if this makes a difference.

A combination of info from the FreeCellPhonesGuy and some Google searches has brought me to Nova Media, a German outfit that makes some nice software for OS X. For $100, you get a piece of software that will detect your mobile phone and handle all the setup, leaving you ready to surf the WWW in style. I don’t think this is necessary, but the fact that it exists means we can do it.

Because cables suck, I’ll look for a Bluetooth solution. Instead of having to plug the phone in, you just have to be nearby, and the computer talks to the phone using a wireless protocol (Bluetooth), and the phone talks to the WWW (using GPRS). In August of 2002, Wei-Meng Lee wrote about this at the O’Reilly Wireless DevCenter. Although he didn’t go into using the T68i as a modem, someone in the comments did. (I found another weblog entry about doing this on a Pay-As-You-Go mobile in the UK, which doesn’t help (directly), but is worth noting, and further verifies the running theory.)

Those comments save us $100. It doesn’t look like we actually need to shell out for software to do it for us. If we were globetrotting with our Powerbook, auto-configuration might be nice. If we’re sitting in one place in the world, it probably isn’t necessary.

Given what we know, let’s assume that the Sony Ericsson T68i is the phone we’ll be using. And, we’ll assume that we want to connect using Bluetooth (wireless), since we know it works.

Which Provider?
That’s tough; what is coverage like in central Ohio? According to coverage maps of unknown vintage, it looks like SprintPCS might cover the area I’m looking for; Verizon does as well.

[Matt calls Verizon customer service... talktalktalk]

I just had a very helpful conversation with a sales rep from Verizon. She even gave me a direct-dial number if we decide to purchase services from Verizon. Here’s what we’ve got:

Oy! Now, to be fair, that’s for unlimited data. For 20MB/month, I could pay $40, and pay $.002 per KB after that. So, depending on usage, I might be able to bring that down to $110/month.

Lets try SprintPCS. They have their own proprietary data network, but as it turns out, you can still hit the WWW via OS X when you’re subscribed to Sprint. Do we see any massive price savings with Sprint?

[Matt talks to a SprintPCS customer service rep., who doesn't give him a direct line if he later wants to purchase products... too bad. But, still friendly and helpful.]

Wow! With SprintPCS, data comes out of your minutes. The odd kicker for a second phone is because you pay $20 for the extra phone, and $7.⁵⁰ to enable that phone to surf the WWW as well. For another $15, we could kick that up to 800 anytime minutes; in either case, weekend and evening minutes are free (night starts at 9PM and ends at 7AM). And, truth told, it would probably be better to go to the 2000 minute plan:

The reason for going up a level is because the second phone gets cheaper by ten dollars, so going from a 500 minute plan to an 800 minute plan (from $88 to $103) isn’t a good idea; going from $88 to $118 for 2000 minutes makes more sense, as the per-minute charge when you run out of minutes sucks.

The bottom line
With a mobile phone only solution (with data connectivity) we’re eliminating a landline, ISP, and long distance charges. If our total usage during weekdays is less than 500 minutes, our cost is roughly $90/month, which is in keeping with our round-numbers estimate of current phone and ISP costs. As a side effect, we get weekends (which is when internet usage is probably highest, and the best time for calling family members around the country) for free, free caller ID, free voicemail, instant messaging, and other similar mobile-phone-type-things. The single largest downside is the loss of the existing home phone number, although it is certainly worth exploring whether than number can be transfered to the mobile phones.

If typical daytime usage of phones is more than 500 minutes a month, then we’re looking at kicking up into the $120 range for services, which is around $30 more than we’re currently spending per month.

So what to do?
Now, I email a few friends, and ask what they know about mobile service providers in the states. Is Sprint the way to go, or is there some reason we want to avoid them like the plague? Otherwise, it seems like we can gain quite a bit, given the existing use patterns, by switching to a wireless-only setup.

‘Nuff said.

I wonder if I’m a creature of habit?

This summer lacked rhythm. It was one long disruption to any kind of schedule. The whole trip home to the States was an exercise in motion: Seattle (WA), Portland (OR), Cleveland (OH), Madison (WI), Bloomington (IN), Mt. Vernon (OH), Cleveland (OH), Atlantic Highlands (NJ), Edinburgh (Scotland), London (England), and back to Canterbury.

While this was a long period of time where Carrie and I were together, it wasn’t stable time. When we arrived back, we had approximately a month together in C-town. Back in the States (a year ago; it always feels like another lifetime, as if there is a discontinuity between then-time and now-time) we had known we would be apart a lot during the next two years. The tacit assumption was that the time spent together would be easy. Status quo. Put another way, we thought it would be like life in Bloomington, where we had a relatively large apartment, an income, and a large, shared base of friends.

Instead, it’s a labour being apart, and a labour getting back together. Not a bad labour; perhaps it’s a labour of love. If you’ve ever up and moved your entire life to another country for some portion of time, or uprooted yourself from everything you know and all your normal support networks, you probably have some understanding of what I’m talking about.

All that said, today was my first truly productive day in weeks; or, perhaps it was the first productive day where I felt good about what I accomplished during the day. Or, the first day where I didn’t feel down for some significant portion of the day. Who knows what it is. Part of it, though, might be a return to a schedule. To normality. Doing things that were part of my routine before. It felt particularly good to hit the squash courts for the first time in months.

Dinner is a Thai curry, and I think a bunch of us are going to go out dancing tonight; it’s 80’s cheeze night at the campus club, and that’s always a laugh. More importantly, it’s music we (postgrads) remember growing up with; for the undergrads, it’s the music that was big when they were born.

Truth told, I should stay in and keep reading and writing tonight. But, hey–why spoil a good thing, right? I might not be able to carry this productivity streak through the whole evening, and then where would I be? Best to quit while you’re ahead, or… something about counting chickens. Either way, it was a good day.

There are more papers out there on the topic; this is mostly a survey of the ACM DL. I need to do a similar search of the IEEE, as well as go through references from a number of these papers. For now, I wanted to get this much in one place, so I have a handle on a first pass at some of this literature.

Pete DePasquale’s lit review and bibliography are going to be useful in this arena (I’ve already read his lit review).

[ DrScheme: A Pedagogic Programming Environment for Scheme ]

[ Declarative Programming Across the Undergraduate Curriculum ]

Schools using Scheme

[ An environment for logic programming ]

[ Ideal teaching machines—a solution to the pedagogic language problem ]

[ A survey of pedagogical programming languages ]

[ Design and implementation of a diagnostic compiler for PL/I ]

Hm. This led to a large spat of compiler-related articles that might be of interest.

[ Description of a high capacity fast turnaround university computing center ]

[ CORC—the Cornell computing language ]

[ Spelling correction in systems programs ]

[ The Turing programming language ]
Turing, a new general purpose programming language, is designed to have Basic’s clean interactive syntax, Pascal’s elegance, and C’s flexibility.

[ Designing computer system messages ]

[ DrJava : a lightweight pedagogic environment for Java ]

[ Pascal program development aids ]

[ A sequence of structured subsets of PL/I ]

[ Automatic program analysis and evaluation ]

[ Practical syntactic error recovery in compilers ]

[ The impact of language design on the production of reliable software ]

[ A syntax directed compiler for ALGOL 60 ]
Perhaps not directly related, but it’s historical, and I’m interested in reading it.

[ A minisystem programming language ]
Anticipated benefits include greater productivity in design and debug phases, and enhanced communication between programmers via simplified documentation procedures.

[ Actor semantics of PLANNER-73 ]
Again, just interested.

[ The role of programming in a Ph.D. computer science program ]
In this general paper the role of programming in advanced graduate training is discussed. Subject matter related to programming as well as programming per se is considered. The importance and application of formalism are considered and also the need for good empirical experimentation. A brief outline for a sequence of courses is included, and subject headings that have been obtained from an extensive bibliography are given. A bibliography of programming references is included.

[ A “curriculum-cycle” environment for teaching programming ]

[ Introducing undergraduates to object orientation using the Turing language ]

[ ICPL : an initial concurrent programming language ]

[ Programming in an Interactive Environment: the ``Lisp'' Experience ]

[ WATFOR—The University of Waterloo FORTRAN IV compiler ]

[ DITRAN—a compiler emphasizing diagnostics ]

[ Third generation compiler design ]

[ Error messages : the neglected area of the man/machine interface ]

[ Behavioral Aspects of Text Editors ]

[ Development of educational software using the DEC PDP-11 ]

[ Meeting the computational requirements of the university - the Brown University Interactive Language ]

[ An analysis of errors and their causes in system programs ]

[ CAP : an automated self-assessment tool to check Pascal programs for syntax, logic and style errors ]
Student programmers have difficulty finding and fixing syntax, logic and style errors in their programs. The Code Analyzer for Pascal (CAP) analyzes programs that use a subset of the Pascal language and provides user-friendly feedback on the errors that it finds. This paper describes CAP and reports its use in teaching introductory programming at the United States Air Force Academy.

[ A study of errors, error-proneness, and error diagnosis in Cobol ]
This paper provides data on Cobol error frequency for correction of errors in student-oriented compilers, improvement of teaching, and changes in programming language.

[ The design of a high-level, language-independent symbolic debugging system ]

[ Experimental evaluation of programming language features : Implications for introductory programming languages ]

[ Implementation of a debugging aid for logic errors in Pascal programs ]

[ Maxims for malfeasant designers, or how to design languages to make programming as difficult as possible ]

[ Thetis : an ANSI C programming environment designed for introductory use ]

[ The impact of structured editing on introductory computer science education: the results so far ]

[ A system for program visualization and problem-solving path assessment of novice programmers ]

[ Toolkits in first year computer science : a pedagogical imperative ]

[ Historical perspectives on the computing curriculum ]

[ Exploiting Smalltalk Modules In A Customizable Programming ... ]

Inside OS X application bundles are two files called scriptSuite and scriptTerminology. I’m starting to think understanding what these define will be critical to my Applescript-bridge.

MacTech Issue #7, Volume 16 contains an article called Adding AppleScript Support to Cocoa Apps. In it, the reader is walked through the building of a scriptSuite and scriptTerminology file for a sample application.

The scriptSuite defines what can be done (and the AppleEvents required to do it), while the scriptTerminology provides natural language descriptions that can be used by AppleScripters. The article goes on to build up a pair of these files for a simple drawing application, which gives the reader a clear picture of how an application is exposed for scripting in OS X.

The article contains a very useful example is the addition of an “open” method to the application (which, as of the writing of the article, you couldn’t get for free from the OS):

"Commands" = {
  "OpenFile" = {
  "CommandClass" = "NSScriptCommand";
  "Type" = "NSObjectReference";
    "ResultAppleEventCode" = "obj ";
  "Arguments" = {
   "FileName" = {
    "Type" = "NSString";
    "AppleEventCode" = "oFNe";
   };
  };
  "AppleEventClassCode" = "sktc";
  "AppleEventCode" = "opFi";
  };
 }; 

"Commands" = {
  "OpenFile" = {
    "Name" = "openfile";
    "Description" = "open a file";
    "Arguments" = {
     "FileName" = {
      "Name" = "at";
  "Description" =
   "The file to open should follow, quoted";
     };
    };
  };
 };

Put side-by-side, it’s possible to start seeing the correspondence between these two files. Indeed, it begins to look like, with a little bit of effort, I (me, person) could read a pair of these files, and send a raw AppleEvent to an application to achieve some effect.

Hm… [Matthew changes to the /Applications/iCal.app/Contents/Resources/ directory on his Powerbook...]

   <key>GetURL</key>
   <dict>
    <key>AppleEventClassCode</key>
    <string>GURL</string>
    <key>AppleEventCode</key>
    <string>GURL</string>
    <key>CommandClass</key>
    <string>CALScriptGetURLCommand</string>
    <key>Type</key>
    <string></string>
   </dict>

   <key>GetURL</key>
   <dict>
    <key>Description</key>
    <string>Open a webcal: or http:
        for a remote calendar</string>
    <key>IsVerb</key>
    <string>YES</string>
    <key>Name</key>
    <string>GetURL</string>
   </dict>

iCal’s event code is wrbt.

“GetURL” is AppleEvent class code is GURL, it’s AppleEvent code is the same, and as an argument takes one string. So, I need to go to iCal World and find a calendar. I’ll look under Apple Events, because that seems appropriate. Unfortunately, the Cleveland Apple Store isn’t open yet, so I’ll take the Columbus calendar instead.

I open iCal and DrScheme, and try

(require (lib "sendevent.ss"))
(send-event "wrbt" "GURL" "GURL"
      "webcal://ical.mac.com/ical/Easton32Town32Center.ics")

and…

It seems like all the information necessary to build a high-level scripting interface to an OS X application is contained within the scriptSuite and scriptTerminology files; both the AppleEvent descriptors and the natural language descriptions are there.

My intuition here is that I could pull apart the Suite and Terminology files for any given application, and from it dynamically define an introspectable RPC interface dynamically, on the fly. As long as the language I’m writing in supports the sending of AppleEvents, I have all the tools I need at my disposal.

Hm.

Time for a shower, breakfast, a trip into town, and a day of writing. I’ll come back to this in another few days.

Links to come back to tomorrow; might do some more digging.

[ Debugging by skilled and novice programmers ]

[ A Bug's Eye View Of Immediate Visual Feedback In Direct-Manipulation Programming Systems ]

[ CAITLIN: A Musical Program Auralisation Tool to Assist Novice Programmers with Debugging ]
[ Above, PDF ]

[ Studying Development and Debugging To Help Create a Better Programming Environment ]

Debugging Perl for Beginners

[ Towards a Debugging Tutor for Object-Oriented Environments ]

[ A Multiple-View Analysis Model of Debugging Processes ], via CiteSeer

Debugging in Chez Scheme, via Grinnel’s Spring 1998 Fundamentals of Computer Science course.

[ Usability Issues in the Design of Novice Programming Systems ]

[ Case-based evaluation of novice programs ] (not debugging)

[ A probabilistic student model in novice programming ] (not debugging, but what is it?)

[ Is There Any Difference in Novice Comprehension of a small program written in the Event-Driven and Object-Oriented Styles? ] (not debugging)

[ Experimental Designs: Testing a Debugging Oracle Assistant
] (a tool to play the role of the human in debugging)

[ SUGI 26: The SAS(r) Debugging Primer ]

[ Type Debugging in Functional Languages ]

[ A Code Restructuring Tool to help Scaffold Novice Programmers
]

[ Comparison of modeling practices of experts and novice learners ...
]