What "A Normal Form" is short for
"A Normal Form" is short for "Administrative Normal Form"
« February 2007 | Main | May 2007 »
"A Normal Form" is short for "Administrative Normal Form"
There is a long list of reasons why the Eclipse IDE is bad news; I want to mention just one of them right now.
Eclipse is extremely bad for learning to program. Our first-year students are learning Java with the "aid" of Eclipse (moreso with the obstruction of Eclipse). A first problem is that the GUI offers a trillion commands, all minute variations of one another, all of which the students shouldn't need to think about (though I'm fairly sure that professional programmers don't need this, either). But that's just a drag, not the essential problem.
Rather, the squiggly-red-underline thing that Eclipse does is actively destructive to the development of problem-solving skills. Students start writing a simple function, and before they're done, something is underlined in red; then they get worried and start hunting around, trying to figure out what's making the squiggly-red-underline happen. They know that the program won't run as long as that squiggly-red-underline is there, so they feel they have to fight it until it's gone. Instead of thinking about their data structure, or the techniques they'll have to use to write the algorithm, they get derailed on syntax. Learning to program is a matter of thinking about your function, about what it needs to do and what components are available for doing it. Learning to program should not be a guessing-game of syntax.
A list of thinks pronounced "links" that relate to either the web or programming:
Herewith I'm making available the slides from the lunchtime talk I gave at Amazon's Edinburgh office last week (16 March 2007). Thanks again to Andrew Birkett for inviting me.
It might be hard to gather much information from these slides without the accompanying performance, but you might enjoy looking at the drawings or trying to run the code samples.
So yesterday I went down to Amazon's development office in Edinburgh, and gave a talk on Links, at the invitation of Andrew Birkett. The talk went well and I was quite pleased with the response and the sharp questions.
One of the biggest concerns that the Amazon people had, which we haven't tried to address in Links, is failure: how the language allows them to handle failure. In Amazon's systems, there are loads of interdependent services that depend on each other to display a single page, and any of them might go wrong; the developers described to me a wide variety of alternate responses that they might want to give, depending on the situations. For example, in some instances, a page feature might collapse down to nothing (disappearing from the page) when it fails. Other times, if a service doesn't respond, the front-end web software might use cached data to display a feature.
This came up in regard to Links because of the way we're making client-server (Ajax) calls simple RPC calls. The question there is, what happens if the remote call doesn't finish successfully, either because the server code couldn't get the right data, or because the network mechanisms themselves failed; how in Links can we handle that anomaly? Part of the answer might be an ordinary exception mechanism, which we can support fairly easily, but we should think more about how Links programmers deal with exceptional situations.
The crowd was very friendly and engaged with the talk quite deeply, I think. They fed me plenty of questions on particular points. Many of these had to do with various kinds of possible failure, as I mentioned; another theme was metaprogramming, prompted because they noticed a certain amount of repetition in my slides (e.g. (foo=foo, bar=bar) when constructing records; I do hope we can improve on that).
I gather they [present-day Amazon developers] do most of their work in Java, but they weren't thrown off when I started talking about continuations or any of the functional-programming idioms that we use in Links. There were a few self-confessed language afficionados in the crowd, but they weren't the only ones who didn't miss a beat at the functional idioms, the tuple types, or the unusual kinds of variable binding we use for our "formlets" (oh, reader—you don't know about our formlets—I'll have to post about that soon).
Between the talk itself and chatting with developers outside of it, I had a quite nice time. Thanks to Andrew and all of the others for listening so well & treating me nicely, even though I'm an academic!
UPDATE: Slides from the talk are available.
Interesting: Joe Armstrong is writing a new book about Erlang.
This is good because the old one was short on helpful material for beginners. I had the same problem when I started learning Erlang as I had with Perl: I was dead in the water trying to get a simple program to run, for hours or days—until, with Perl, I found Learning Perl. With Erlang it was just a tremendous amount of banging my head against the wall. The first hours of learning a new language, for me, are often spent with trivial frustrations, like figuring out what "main" is called, or how to include the standard library. Maybe that's because I usually don't start with examples, the way many people do. Rob Sayre says the book is good.