Welcome, Guest. Please Login
 
  HomeHelpSearchLogin FAQ Radified Ghost.Classic Ghost.New Bootable CD Blog  
 
Pages: 1 2 
Send Topic Print
How to Design Programs (HtDP) & SICP (Read 22259 times)
Rad
Radministrator
*****
Offline


Sufferin' succotash

Posts: 4090
Newport Beach, California


Back to top
Re: How to Design Programs (HtDP) & SICP
Reply #15 - Aug 8th, 2009 at 12:40am
 
'one of the things every sorcerer will tell you .. is that if you have the name of a spirit, you have power over it.'  Smiley
 
WWW  
IP Logged
 

Rad
Radministrator
*****
Offline


Sufferin' succotash

Posts: 4090
Newport Beach, California


Back to top
Re: How to Design Programs (HtDP)
Reply #16 - Aug 8th, 2009 at 12:47am
 
i am not familiar with math terms increment / decrement. piano .. something. resitic.

seems increment = add 1

decrement means subtract 1.

simple enough.
 
WWW  
IP Logged
 
MrMagoo
Übermensch
*****
Offline


Resident Linux Guru

Posts: 1026
Phoenix, AZ (USA)


Back to top
Re: How to Design Programs (HtDP)
Reply #17 - Aug 8th, 2009 at 2:49am
 
Rad wrote on Aug 7th, 2009 at 1:57pm:
In the video, Abelson says, "We're going to conjure our spirits in a magical language called Lisp..."

Right.  Scheme is a version of Lisp.

Rad wrote on Aug 7th, 2009 at 8:06pm:
Also is Scheme a compiled language?

I think it's interpreted, but I'm not sure. 

Later in SICP, they show how to write a Lisp interpreter in Lisp.
 
WWW  
IP Logged
 
Rad
Radministrator
*****
Offline


Sufferin' succotash

Posts: 4090
Newport Beach, California


Back to top
Re: How to Design Programs (HtDP)
Reply #18 - Aug 8th, 2009 at 9:23am
 
Quote:
*** first they define "area-of-disk" with variable "r" but then they apply "area-of-disk" to the "area-of-ring" example, which subtracts inner from outer, and uses outer and inner as variables.

Ah. HtDP doesn't explain things like this from first principles. I'll try and write up a really fundamental set of examples to explain what is going on here, but it'll take me a little while to get through; I should finish it tomorrow, and when I do I'll share the Google Docs document with you.

*** Also is Scheme a compiled language?

Well, it can be, but it doesn't *have* to be. More importantly is that it is intended to be an *interactive* environment, similar to the way you interact with the UNIX shell. So, implementations have to be prepared to allow you to enter program fragments (and test them by hand) in whatever order you like, and to provide new definitions if your hand testing doesn't produce the result you want.

As it happens, PLT Scheme is sitting on a very highly engineered Scheme environment that can compile everything you type to native code for the x86 CPU. However, the fact that it can do that isn't really observable in any respect other than the code runs fast; if the Scheme program instead worked a simpler way, as an interpreter, it would be slower but it would still do the same things.

So, it's not a hard distinction between compiled and non-compiled languages. The difference is really that some languages are *only* intended to be compiled, which means they are non-interactive. For those languages, the compiler is something you point at a file and then it will spit out an executable program that you then run, and the language is designed to take advantage of the fact that you have to supply it a complete program which cannot be changed later on.

The difference between styles - interactive environments versus compiled ones - has been blurred a little in modern times by fancy editors that give you a keystroke to save the file you are editing and run the compiler on it, but that only affects the way you work in an editor. There are all kinds of subtle differences in the design of the languages that reflect the difference in the designers intent between interactive and non-interactive (compiled-only) languages; you'll get to appreciate that distinction in due course.

- Nigel
 
WWW  
IP Logged
 
Rad
Radministrator
*****
Offline


Sufferin' succotash

Posts: 4090
Newport Beach, California


Back to top
Re: How to Design Programs (HtDP)
Reply #19 - Aug 8th, 2009 at 12:39pm
 
SICP.1b > Procedures & Processes: Substitution Model

Job of a programmer is to design processes that accomplish a particular goal. He does this by contructing "spells".

These "spells" are constructed out of procedures & expressions, and they somehow direct a process ('spirit') to accomplish the goal intended by the programmer.

In order for the programmer to do this effectively, he needs to understand the relationship between the particular things he writes (the spells) and the behavior of the process (spirits) he's attempting to control.

This lecture > establish that connection clearly as possible.

In particular > how particular patterns of procedures & expressions ('spells') causes particular patterns of execution, particular behaviors from the process ('spirits').

Mapping from mechanisms of the procedure .. into the way in which these processes behave.

"Substition model" is a semi-formal mechanical model. Only an enginering model. It's "approximately" true. (Not really true.) True for most purposes. Model will break down later. Simplest model we have.

"Substition model" .. accurate for most things we will deal with in next few days.

But eventually it will become impossible to sustain the illusion that's the way the machine works.

More-detailed models later.

Kinds of Expressions:

• Numbers
• Symbols ( * , + , - , etc.)
• Lambda expressions
• Definitions (define)
• Conditionals (if, then, else)
• Combinations (+)
 
WWW  
IP Logged
 
Rad
Radministrator
*****
Offline


Sufferin' succotash

Posts: 4090
Newport Beach, California


Back to top
Re: How to Design Programs (HtDP)
Reply #20 - Aug 8th, 2009 at 1:48pm
 
SICP.1a

CS is about formalizing 'how-to' knowledge. The real problems in CS come when we try to build very large systems (programs). There are techniques for controlling the complexity of large systems. CS, in a sense, is really about learning the techniques for controlling complexity.

Three main topics of course = 3 methods for controlling complexity:

1. BLACK-BOX ABSTRACTION (to supress detail .. so we can build bigger boxes)
     A. Primitive objects
           1. all programming languages consist of primitive data & primitive procedures

     B. Methods of Combination
           1. how do we take primitive things and make more-complicated things .. via procedure composition
           2. putting together primitive procedures to create more-complicated procedures
           3. putting together primitive data to create compound data via data data construction.
     
     C. Methods of Abstraction
           1. having made compound things, we'll look at methods to abstract them
           2. how to put black boxes around them so we can use them as components in more complex things.
           3. Done by defining procedures & a technique for dealing with compound data called data abstraction.
     
     D Capturing Common Patterns
           1. going from the rules to how an expert works.
           2. high-order procedures (procedures whose inputs and outputs are themselves procedures
           3. data as procedures
           4. line between what we consider data and procedures will blur.

2. CONVENTIONAL INTERFACES
     A. Agreed-upon ways of plugging things together.
     B. Generic Operations
     C. Large-scale Structure & Modularity
           1. Object-oriented Programming (think of your system as a society, consisting of little things that interact by sending info between them
           2 Operations on Aggregates (called streams)

3a. MAKING NEW LANGUAGES (most magical part of the course)

3b. When you become overwhelmed by complexity .. the way you control that complexity .. is to create or pick a new design language .. to highlight different aspects of the system .. to supress certain details & emphasize others.
Most magical part of course.
We will look at the technology for building new computer langauges.
First thing .. we will build in LISP the process of interpretiing LISP itself .. two processes > apply & eval (mystical symbol) .. self circular 
We'll see lots of magical things.

3c. Metalingistic Abstraction
How to construct new languages.
Looking at the process of interpretation .. look at apply/eval loop .. and build LISP.
Use same technology to build a very diferent kind of language .. logic programming langauge .. don't talk about procedures
How you implement these things very concretely on the simplest kind of machine.
 
WWW  
IP Logged
 
Pages: 1 2 
Send Topic Print