Computer Power and Human Reason

I read "Computer Power and Human Reason" 25 years ago, just as the AI boom was getting underway. The author wrote the book at least partly as a result of observing people using his ELIZA program.

In 1962, he published a comparatively simple program called ELIZA which demonstrated natural language processing by engaging humans into a conversation resembling that with an empathic psychologist. The program applied pattern matching rules to the human's statements to figure out its replies. (Programs like this are now called chatterbots.) It is considered the forerunner of thinking machines. Weizenbaum was shocked that his program was taken seriously by many users, who would open their hearts to it. He started to think philosophically about the implications of Artificial Intelligence and later became one of its leading critics.

Joseph Weizenbaum died on March 5 of this year. As a Lisp programmer doing some AI programming, but not really being an "AI guy", his book and ELIZA helped me understand not only AI, but AI researchers!

Clojure

Christophe Grand pointed to the Clojure programming language in a comment on my recent Erlang post.

I'd heard the name but never investigated. My loss. Clojure is a mostly-functional, concurrent Lisp dialect for the JVM. That definitely warrants an in-depth look for me.

Here's some more information I quickly found.

Erlang Criticism Not Unwarranted

Eric's post on the recent Erlang criticism and his take on the subsequent trail of mail list discussions is fairly accurate in my opinion. I posted a long response on his blog and midway realized it's a blog post of its own. Here.

I'm not going to argue too strongly for "sequential Erlang" because it's really "concurrent Erlang" that stands out. The Erlang syntax is ok by me, but then I still prefer Lisp syntax to anything else I've seen anywhere. Simple.

And I can say nothing for the erlang list, except I've been skimming it too, with not so different reactions as yours.

Anyway...

"in development, the behavior of that existing function often changes thereby affecting all the calling functions"

As with all dynamic languages (especially those unlike Lisp and Smalltalk that do no have good refactoring editors), you need good unit test coverage. Which you are doing, right?

"defining dozens of one-line functions has made flow control difficult to follow in some circumstances."

This is pretty much the same for all functional languages, and even Smalltalk, which tends to have many small methods, where other OO language programmers tend to write overlong methods.

Good tools, which again Lisp and Smalltalk tend to have, and others don't, are indispensable. Otherwise the only thing that tends to help IMHE are again many good tests to read, "Oh, so this is the thing to call, and how to call it."

I still think that's better than really long methods Java or other languages that tend not to be reusable without a good deal of pain. (For one thing, they tend not to be really well tested.)

"It shouldn't take a committee to help you write good file handling code."

I don't disagree completely except that Wide Finder pushed Erlang and its community into a new I/O situation. So most of what happened by the end of it was a core Erlang member adding some new core capabilities to the language. Then also what happened was the exposure of a development process for how to evolve concurrent algorithms generally in Erlang or maybe any concurrent system. I would think both, especially the new core I/O capabilities, will help down the road without requirement the full committee.

"the language is a DSL for networking gear."

Which essentially what it is. CouchDB, Yaws, ErlyWeb, etc. will help, but mostly Erlang and its surrounding code is not much more than what the telecom programmers were using in the mid-1990's. that is its upside and its downside.

"I can write a Scala function to make an HTTP POST in four lines of code and have it run screamingly fast"

Two points:

• Yeah, *but* then you also have to deal with all of Scala's type system. "Oh, you need an existential type here because a mere parameterized type gets the type system all confused, even though it's fairly obvious what you are trying to do."
• Yeah, *and* what the rest of the world should learn from Erlang is "concurrent Erlang" and how to apply *those* lessons in a distributed, multi-language way. You shouldn't need to use Erlang to get the benefits of things like OTP. OTP and basic message passing with pattern matching is missing from pretty much every system but Erlang. Scala and Java do not have an OTP although Scala addresses the latter.

(And now you see why I thought so highly of Jini and Javaspaces, because it also attempts to bring these to Java. It's the closest thing Java has to Erlang/OTP. But now, where did that go again? Dang it.)

Like you wrote...

"actors are so important, it will be amazing when the programming public realizes why we all need to do this"

You could also try Gambit Scheme, which I think is better as a sequential language (Lisp) but also has pretty much Erlang-scale thread/mailbox performance on a single CPU. Not much in the way of distributed or multi-core support yet. You get more of those, "shared nothing" threads, and functional data structures if you use the Termite package on top of Gambit. Multi-core is bubbling to the top of Gambit now that a decent package system has been released.

Buyer Beware: Corrosion Alert

Asus predicts their new Windows XP-based Eee PC will outsell their current Linux-based PC. But buyer beware.

First, it's XP. Will the typical Eee PC consumer understand this is not "Vista" and will likely not continue running newer and newer versions of Windows software for long?

Linux on the other hand will do the job the Eee PC was intended to do, very well. Probably XP does the same job just as well. Until it doesn't.

I have simply found after years of running Linux and all kinds of Windows systems (except Vista, thank you!) that Linux systems tend to just run for years with little corrosion and little maintenance.

I am forever "managing" the rest of my family's Windows-based PCs, currently Windows 2000 and Windows XP. As the Eee PC's XP begins to decay (usually within six months), what then?

Is the Err PC intended to be a simple computer that "just runs" or will the consumer understand that they'll need a Windows technician to clean up the registry, uninstall software correctly, and continually ghost and/or rebuild the OS completely every year?

Thanks

Can I just say if there is any kind of a supreme being in need of thanking for spring emerging in Oregon these days...

Consider yourself thanked. Well done you.

gas and heartburn

Joe Gregorio on the price of gas...

A doubling or tripling of the relative price of gas is inevitable, and is probably the best long-term thing that could happen to the country, fully realizing that in the short term it's going to be painful.

Carter set a goal in the 70s of importing no more foreign oil than the levels at that time. He was belittled, and then we got Reagan. Reagan took Carter's solar panels down from the White House. No oil company bag man could be seen with those.

Now here we are 30 years later, *subsidizing* the oil companies while they "earn" record profits.

I don't know all that much about Carter, but now I think as a president there are a few things he's under-appreciated for. I voted for John Anderson in 1980, my first presidential election. I was the typical Anderson voter -- a socially left-leaning college student, from a fiscally right-leaning family.

Had America the leadership with the foresight and fortitude back then, and since then, we may have been able to have gradually increased the tax on oil to fund strategies toward Carter's vision of more, cleaner, energy self-sufficiency. Ultimately there are many powerful, near-sighted, self-centered forces that interfere with that kind of grand vision and strategies.

Maybe the only way to get to such a future is to stumble into it. "When the student is ready, the teacher appears."

Concurrency Summit

Tim Bray reports on the 2008 O'Reilly Concurrency Summit a bit. Hopefully there will be more from Tim or others. The summit looks like an "open space" conference, scheduled on the spot by the attendees. Apparently the topics included REST and Erlang, and so the discussion must have branched out into distributed systems, not just concurrency per se.

Anyhow, two subjects that came up were REST (which is concurrent at the largest possible scale), and, unsurprisingly, Erlang. And it struck me that they’re kind of like each other.

Well, in REST, a message sender has to know the receiver’s address, there’s no global data, the receiver has to be waiting for the message, and the receiver will typically dispatch on its contents. Just like Erlang.

Yeah, I think it's helpful to compare and contrast the two (HTTP and Erlang's own message passing). Also comparing and contrasting XMPP and Erlang's message passing is useful. They are three different, but related, points in the spectrum. (I wonder if XMPP came up at the summit? Is it bright enough on the radar yet?)

e.g. XMPP's "presence" capability is similar to Erlang's node linking, but more rich.

Neither HTTP nor XMPP have the selective, pattern-matching, message receive capability of Erlang. But they both would support multiple "channels", which can be used for similar purposes.