the Design Experience Weblog Archive

Email enhanced collaboration? [www.mindthis.net]

Lars Ploughman follows up to his 10-to-1 email rules post. Basically email is never ideal as the only collaboration tool, but should be part of an overall collaboration toolset.

OpenACS is a collaboration tool that offers some good email integration while preserving the benefits of a collaboration toolset. For example, the discussion forums can be email enabled to send out new posts by email and to accept replies to those emails. This way, someone can refer later to a post by URL and all the email is archived in one place, and indexed for full text search. Other collaboration tools in the OpenACS platform can be enabled in the same way. Almost every applicaiton supports notification of new items and changes by email.

Another tool that is becoming more common is RSS syndication. In this way the user chooses to be notified in a news reader instead of by email. To reply from there they can just click on a link and go to the collaboration web site within their browser.

A collaboration toolset like OpenACS gives users the option to work with email, rss, or any combination. Of course, new communication mediums such as SMS can also be integrated with the right code.

A mix of tools that fit each users work style while preseving a searchable centralized history and current status of the collaboration is a good solution taking advantage of the technology we have now.

10:14 PM, 26 Nov 2006 by dave bauer Permalink | Comments (0)
categories: OpenACS , Technology and Education

I had a very hard time imagining the difference between a recursive process and an interative process. I had to dive into an article on Wikipedia about the subject of Tail Recursion, the process that a compiler uses to make a recursive function into an interation. This happens if the recursive function call is the last thing to happen in a function.

I wish this had been more clearly explained, I would have gotten it right away!

Recursive Procedure that results in a recursive process

(define (factorial n)
(if (= n 1)
1
(* n (factorial (-n 1)))))
In this first example the last thing that happens is a call to the * function, so it results in a recursive process.

Recursive Procedure that results in an iterative process

(define (factorial n)
(define inter product counter)
(if (> counter n)
product
(iter (* counter product)
(+ counter 1))))
(iter 1 1))

The second example has the recursive procedure defined inside the factorial procedure.

09:05 PM, 26 Nov 2006 by dave bauer Permalink | Comments (0)
categories: Learning , Programming , Learning Portfolio

I found a couple of scheme interpreters implemented in Javscript. This makes it possible to show and run example scheme code from SICP right my my weblog. It should be fun. I can complete the exercises from SICP, and post examples with a Scheme interpreter built right into the post.

Scheme Implementation in Javascript by Chris Double and Little Scheme by Douglas Crockford who also wrote The Little JavaScripter a version of The Little Schemer focused on the same concepts implemented in Javascript.

Little Scheme

Input Box:

Output Box:

The Little JavaScri pter

07:24 PM, 26 Nov 2006 by dave bauer Permalink | Comments (1)
categories: Scheme Code

The Roots of Lisp [paulgraham.com]

Paul Graham's The Roots of Lisp should be required reading for anyone attempting to understand programming in a functional language, or anyone interested in the amazing, simple ideas that make programming languages powerful.

I am quite surpised I have never seen a link to this article. I must have missed it. It really explains the power and the simplicity of the math behind Lisp. Basically the entire language of Lisp is written in itself using a few primitives and a few more functions.

I found this article poking around Paul Graham's site looking for the online version of On Lisp, which I thought I would read to expand my learning. I think this short paper gave me enough to think about for a while.

03:09 PM, 25 Nov 2006 by dave bauer Permalink | Comments (0)
categories: Learning , Programming , Computer Science

Ramon Leon comments on a post called Smalltalk - Language of the gods by saying this
"Languages like Smalltalk and Lisp (always got to give Lisp its props) are amplifiers. They make you more of whatever it is that you already are. If you're a bad programmer, they're going to make you worse, they'll let you shoot your foot off in more interesting ways than you can imagine."

This ties into the maze of twisty abstractions idea. It is definitely the case that some of the historical design issues of ACS 4 (the predecessor to OpenACS 4 and 5) were due to a dangerous amount of a little knowledge. Powerful tools can be used effectively or ineffectively, just like any tools. I guess the more power, the more effective or ineffectively they can be used.

07:18 PM, 19 Nov 2006 by dave bauer Permalink | Comments (0)
categories: Programming , Computer Science

I just wanted to share my favortie phrase to describe over-engineered systems. The title says it all, of course. The term "architecture astronauts" is usually used to describe the folks who build such things. I think my phrase describes the feeling you get when you get lost in that kind of code.

TODO: Find some real-world code to talk about?

11:12 PM, 16 Nov 2006 by dave bauer Permalink | Comments (0)
categories: Programming , Computer Science

XML

Notifications

You may
request notification for the Design Experience Weblog.

Syndication Feed

XML