Here is some code I borrowed to make emacs work nicely with scheme.

First I installed some stuff
apt-get install mzscheme
apt-get install quack-el

Then I added this to .emacs

;; Start up Scheme

(add-to-list 'load-path "/usr/share/emacs/site-lisp/quack-el")

(setq scheme-program "mzscheme")

(global-set-key [(f5)]

		'(lambda ()

		   (interactive)

		   (require 'quack)

		   (run-scheme scheme-program)))

The code fragment borrowed from http://jeffcjensen.net/scheme/_emacs

That link has quite a bit for scheme customization for emacs but I am not sure I will need it that much yet.

I picked mzscheme because I can apt-get install it and the .emacs I borrowed from seems to have some support for it.

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.

Functional Programming for the Rest of Us is an very clear exlanation of what functional programming is, and how it is different from imperative programming.

This arcticle is the first time I have understood what a function is. That's pretty important in doing functional programming. Without understanding the nature of functions (as defined in functional languages) you will never "get it". Now I have it.

The basic idea is this, a function always returns the same return value for the same arguments. It can't do anything else, or its not a function. Simple, and elegant. The article goes on to explain how you can possibly accomplish anything built on this simple foundation. Its good. Go read it.

I remember now that the Berkeley computer science lectures I linked to also explain a function in this way. That is, its always returns the same thing when given the same arguments with no side effects. This was buried inside the rest of a lecture, and I did not understand it in the whole context of what was going on. I am glad I found this article. I found it in a thread asking about the explanation of continuations on a Squeak mailing list.

My good friend and fellow OpenACS hacker Vinod pointed me to a set of videos/podcasts of a recent course following Structure and Interpretation of Computer Programs.

Signifigantly, they approach the material in a little different way, and order than the classic lectures available online http://www.swiss.ai.mit.edu/classes/6.001/abelson-sussman-lectures/

It seems like the lectures given by the authors in 1986 follow the development of the book itself pretty closely. I was getting stuck on one part of the book, and not surprisingly they skip that part and come back to it, in the Berkeley lectures.

The push up first-order functions much earlier in the course, and I was able to "get" it right away. I am sure there is much more to understand, and I will keep listening and learning.

Comparing SICP to HTDP we find one book focused on learning how to solve problems, and think in new ways, while the other focuses on building computer software systems.

SICP is for training computer scientists, while HTDP is for training good programmers.

So if you just want to implmenet new versions of the software we already have, in a new lanaguage HTDP will help you produce better, easier to maintain code. If you want to change the world, and create something new, you need SICP.

I found a post on Lambda, The Ultimate that links to a few articles discussing what should go into a first programming course, and how it should be taught. I originally looked at SICP and I think it teaches some really interesting fundamentals of how programs work. This critique by Felleisen, et al,[pdf] auhtor's of How to Design Programs advocates a different approach. The critique says that SICP shows how to do the main parts of programming, but does not teach when or why to choose a certain technique. It seems that SICP expects 1) the instructor to add this value, or 2) the student will learn this by applying the priciples to example programs, and be able to transfer this to their future programming projects.

I have just started SICP and I agree with this critique. Probably most of all what I need to learn is when to apply a certain technique and how to anaylyze a program structure to know what techniques are being used and how to improve it.

Another critique of SICP is the specific domain knowledge required to understand the programs, especially mathematical concepts. One of the first examples, and exercises focuses on testing is a number is prime. The forumla and algorithm for this is introduced, but it seems it is assumed the reader understands this from prior math courses. This can make the learning frustrating as you end up focusing on understanding the math instead of the program.

It probably is important for a programmer to understand this math, but its hard to aquire it in this context. The critique shows a table of the concepts taught and the examples used to teach them comparing SICP to HTDP and its striking how the examples in SICP are of interest only to the most dedicated computer scientist who wishes to understand the deepest concepts of the art, where HTDP examples seem much more fun, and approachable.

I still will stick with SICP, but I am also going to look at HTDP in parallel. I am intersted in the funadmentals of programming langauges and how they are built, even if it isn't directly applicable to my programming work. I also am interested in learning about learning, and the different ways the programming fundamentals can be learned.

I have decided that even though I don't have time to formally pursue a degree in Computer Science, I am going to attempt to learn the content of a Computer science/Software Engineering program on my own.

I am using this weblog category to document this process in case I ever decide to take what I have learned and apply it toward a degree. There are schools like Empire State College that grant credit for documented learning. Documenting the learning process should also help me reflect and learn what I have learned.

I feel that I have quite a bit of computer science type knowledge already through my open source volunteer programming, and consulting projects. The idea is to figure out what parts I have learned and where I can learn more.