Scheme - Part 1 - Wishful Thinking and Abstraction

Prologue¶

I started
learning
LISP
(actually a dialect of LISP
called
Scheme)
sometime back. The inspiration for learning Scheme was that it is
a completely new programming paradigm
i.e. functional programming language
and I wanted to learn a non-Object-Oriented programming
language. Anyway, so I looked
at
Haskell
as its a purely functional programming language, but I picked Scheme
because of the
book
Structure and Interpretation of Computer Programs (referred
to as SICP hereafter).

What is this ?¶

Even though I started about 1 year back I did not make much progress
and I realized that one of the main reasons was that I was not doing
the exercises with enough rigor. Thinking about a solution is very
different than writing an actual program. So I decided that I would do
the exercises and put them
on Gitlab and then write about
them. Furthermore during this course of learning Scheme I've come
across a lot of cool stuff that completely changed the way how I
approached computer science and programming in general. I want to
share those.

Lets start¶

Let us write a program

sum pic

(these are cropped screen-shots of Emacs)

This program takes three numbers and adds them. This is also how the
scheme syntax looks. Scheme syntax is
just S-expressions or
symbolic expressions.

Thinking about S-expressions is easy.
- Starting from the first "(" the first element is the operator
- Everything that comes after the first operator are the operands
- The end is the closing bracket ")"

How about a procedure (scheme word for functions)

In scheme we use the "define" keyword to define a procedure.

Its syntax is like this (define (<name> <formal parameters) (<body>))

Let us define a procedure

sumProcedure

This is how the procedure looks. The name of the procedure is "sum" and it takes in two numbers and produces their sum.

Let us write something a bit complicated

sumOfSquare

This procedure uses the previous "sum" procedure to compute the sum of
the square of two numbers. I this process you should see another
procedure that we have defined which is called "square". This is an
accessory procedure. We could have no used it and it wouldn't have
mattered too much.

NOW!! here is the kicker! :-P

Imagine for a second that you did
not know how addition, multiplication, division etc worked. You could
still define the procedure "sumOfSquares" knowing that you have
procedures called "sum" and "square" that will take care of the
internal operations for you.

What this enables you to do is do a top down design approach to
things. While designing apps (nothing too big) in C++ I found myself
being too worried about what were all the small parts the should make
up the program, But after starting to read this book apart from
learning scheme I also learned this model of thinking.

The writers call this "wishful thinking"; as in you wish that
something existed and then used it as if it existed. Then you tried to
figure out if it did exist in the first place or not. If it does exist
then fine; otherwise you design one.

Which means that if at any point while designing a software you are
un-sure about all sub-modules that will be required to make that
module work then you do not start designing the sub-modules and build
up from there. Instead you design the current module and then design
the sub-modules to match the requirement set up by the module. This is
top-down design approach.

For example when designing "sumOfSquares" you need not think about how
you will implement it. You can just write the code and then you can
sit down and figure out how "sum" and "square" would work. At the time
of writing the sumOfSquare you do not know if sum and square
exist. You just use them as if they did existed.

This also means that while wiring the sumOfSquare procedure you need
not bother about how sum and square will be implemented. You can
just use them as it is.

This brings me to my next point.

Abstraction¶

Every procedure is like a layer of abstraction that is telling you to
not worry about how it works and instead focus on the task at hand.
This idea is immensely helpful. Its so simple. If you don't know how
to do something; just write a procedure that does it; then worry about
the procedure later.

I didn't think much about this until recently when I started doing
the exercises in the book more seriously. Its great once you get the
hang of it.

Conclusion¶

This is not the I have more things to share. Hopefully I will be able
to write about them soon. :-P

Here is the Gitlab Repo where I will keep uploading my SICP exercises.