Recursion Part 3

I just read this by Brian Harvey, the author of berkeley Logo. I must confess that this is an eye opener of the ideas I had in my mind about the hierachy of computer abstractions. It turns out recursion is not abstract enough. Functions are more abstract. The idea is not the think what the machine is doing step by step but the have a vision of what you want to archive at top level. Functional programming as first announced by Backus in 1978 goes further than the recursion abstractions and uses APL ideas of dealing with arrays of data(or list) directly. Functions like map(called map-car in list), reduce, and filter are powerful tools in this functional approach. My next exercises will be to use recursion and try to convert the solutions into functional approach as much as I can.

I think this is good exercise in general. Many times we ask novices to practice programming exercises but we don't emphasize these programming abstractions and approaches that can help beginners solve many problems at a glance. Brian is a really a great teacher and so far I consider him a mentor with his use of Logo not only to teach but to do research.

Many people have the misconception that Logo is only good for children and not a mature language. This is mistaken view in my opinion. Brians books here are a testament to that. He truly shows you how to use Logo to do more. Besides Logo is a dilect of lisp, so technically anything that can be done in lisp can be written in Logo.

This is an exciting journey for me, as a lecturer and researcher I am interested in approaches that can enhance my teaching skills and my research skills as well. In logo we find this synthesis. And the programming paradigms can easily be explored from Logo especially since Logo is a lisp dilect. Lisp is easily ammendable to deal with objects. There are even some who ridicule oop in preference of functional approach.

I am not going to join the wars of computer paradigms, but I will use whatever helps me to solve a problems efficiently. I don't really even mind using assembly language especially if I want to optimise something. The key is knowing how to use a tool and abstracting away from that tool using ideas like Backus functional programming or even jackson structured programming ideas. I like jackson methods. And I think there not disimillar from maccarthy's list processing.

Comments

Post a Comment

Popular posts from this blog

Recursion Part 1

Recursion is art of making programs call themselves. It is my opinion, recursion is the main idea in computer programming. In fact early computer theorist where recursion theorist( eg. church, curry, ackermann,etc). Recursion theory inspired functional programming in the 70s. Functional programming is prefered by these mathematically oriented programmers not only by its elagence but by it suitability to be reasoned with mathematically. Lisp was invented by John Mccathy in 1958. It was also based in recursive theory paradigm. The language in my opinion possesess the beauty of the mathematics it inherited from. It has simple syntax(core language i mean). eg. only 5 primitive operations are defined: car,cdr,cons,eq, and null. Knowing these together with statements for creating functions(lamda or defun) and conditional statements(if, cond) one can derive everything else using the language. I am set to master lisp, not necessary to use as a language in my programming task, but you thi...
Read more

Back to programming competitons

I am coming back to programming competitions. and as preparation I am back at a study of recursion. I have bought books and read websites on this topics over the years. Only lately have I thought I made progress. Firstly I must thank God for getting to know lisp. And getting to understand its power. List makes you look at programs in a different way. I never knew a programming language could make a person see the programs different. Also the idea of list forces you to program using data. Very smart. And data is static. You generate output as the program progress. All you should be worried about the final list and the list you consume. It is highly recommended for anyone who wants to do serious programming. A key advantage of engaging in programming competitions is it will boost your programming skills. In my opinion, this is how far it can go. I don't think a good algorithms programmer automatically can make a good software developer. Development in my opinion is another skill,...
Read more

Debugging Part 3

I am debugging the following program, and I started realising the disadvatanges of blind debugging. I had solved the problem before. And I solved it through debugging. So now faced with the same problem I seem not to remember how I solved it. So here i is the disadvatanges of blind debugging. It is adhoc and prone to blind programming. The other way I like to say it, is it is "hacky". Not hack of breaking computers but that of prototyping something quickly without following principles. I am still in the process of solving the problem below. When I am done, I will let you know how I did it. ;P09 (**) Pack consecutive duplicates of list elements into sublists. ;If a list contains repeated elements they should be placed in separate sublists. ;Example: ;* (pack '(a a a a b c c a a d e e e e)) ;((A A A A) (B) (C C) (A A) (D) (E E E E)) to pack.run :list :item ifelse emptyp :list [output :list] [ifelse equalp first :list :item [output sentence first :list pa...
Read more