[kragen]

SICP is fundamentally about the notion that programs are primarily a means of communication between people, being written by people for other people to read, and only secondarily a thing for computers to execute. And it really opened my eyes to the landscape of programming paradigms that exist—indeed, it continues to do so!

But your comment is completely off-base.

In Circuits and Electronics, as I understand it, the "structures" being discussed are circuit schematics, things like this keyboard I designed last month https://tinyurl.com/23tdsm4c. While SICP does talk about circuit schematics, I don't think anyone would claim that S-expressions are a reasonable alternative way for people to read and write such things.

You're completely confused about Signals and Systems, because you said "functionality", a word which refers to the kind of "functional" a machine might be. In that context, saying that something is "functional" means that it works. But the "functional" that describes Signals and Systems is the mathematical idea of a "function", which is a not-necessarily-computable relation of each possible input to one (possibly not distinct) output. The kinds of "functions" we're talking in S&S are the kinds of functions where you can take the Laplace transform or plot the frequency and phase response. It isn't about functionality at all!

While S-expressions are perfectly capable of expressing ideas like these, and indeed SICM investigates those possibilities in much more detail, SICM hadn't been written yet, and SICP and 6.001 touch on them only briefly. Following SICM I think even its authors were doubtful about whether Scheme was a good medium for working with those ideas.

I don't know anything about Computation Structures, so I can't really say anything about it. Maybe you're right that it would fit perfectly well into 6.001. Apparently it survived the purge; https://ocw.mit.edu/courses/6-004-computation-structures-spr... says:

> This course introduces architecture of digital systems, emphasizing structural principles common to a wide range of technologies. It covers the topics including multilevel implementation strategies, definition of new primitives (e.g., gates, instructions, procedures, processes) and their mechanization using lower-level elements. It also includes analysis of potential concurrency, precedence constraints and performance measures, pipelined and multidimensional systems, instruction set design issues and architectural support for contemporary software structures.

[swannodette]

> Following SICM I think even its authors were doubtful about whether Scheme was a good medium for working with those ideas.

Hrm https://mitp-content-server.mit.edu/books/content/sectbyfn/b...

[kragen]

This looks awesome! Maybe they were joking.

[so-cal-schemer]

> SICP is fundamentally about the notion that programs are primarily a means of communication between people, being written by people for other people to read, and only secondarily a thing for computers to execute.

Kragen, I think you hit the nail on the head with this.

From the 1e Preface:

"Our design of this introductory computer-science subject reflects two major concerns. First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute."

And also,

"Second, we believe that the essential material to be addressed by a subject at this level is not the syntax of particular programming-language constructs, nor clever algorithms for computing particular functions efficiently, nor even the mathematical analysis of algorithms and the foundations of computing, but rather the techniques used to control the intellectual complexity of large software systems."

6.001 germinated in 1978! There were far fewer languages to choose from then.[0] As elegant, and expressive, and powerful as Scheme is (being an attempt to strip a language down to the essentials), perhaps there just are more legible languages these days. A good exercise would be to go to Rosetta Code[1], pick a program, and compare the aesthetics of the code. What solutions are the cleanest and easiest to understand?

[0]: https://en.wikipedia.org/wiki/Timeline_of_programming_langua...

[1]: https://rosettacode.org/wiki/FizzBuzz#

[so-cal-schemer]

Some notable examples:

(pulled from https://rosettacode.org/)

  --------------------------------
  [[ Scheme ]]
  
  (do ((i 1 (+ i 1)))
      ((> i 100))
      (display
        (cond ((= 0 (modulo i 15)) "FizzBuzz")
              ((= 0 (modulo i 3))  "Fizz")
              ((= 0 (modulo i 5))  "Buzz")
              (else                 i)))
      (newline))
  
  --------------------------------
  [[ Python ]]
  
  for i in range(1, 101):
      if i % 15 == 0:
          print("FizzBuzz")
      elif i % 3 == 0:
          print("Fizz")
      elif i % 5 == 0:
          print("Buzz")
      else:
          print(i)
  
  --------------------------------
  [[ Logo ]]
  
  to fizzbuzz :n
    output cond [ [[equal? 0 modulo :n 15] "FizzBuzz]
                  [[equal? 0 modulo :n  5] "Buzz]
                  [[equal? 0 modulo :n  3] "Fizz]
                  [else :n] ]
  end
  
  repeat 100 [print fizzbuzz #]
  
  --------------------------------
  [[ Racket ]]
  
  (for ([n (in-range 1 101)]) 
    (displayln 
      (match (gcd n 15) 
        [15 "fizzbuzz"] 
        [ 3 "fizz"] 
        [ 5 "buzz"] 
        [ _  n])))
  
  --------------------------------
  [[ Arc ]]
  
  (for n 1 100 
       (prn:check (string (when (multiple n 3) 'Fizz) 
                          (when (multiple n 5) 'Buzz)) 
                  ~empty n)) ; check created string not empty, else return n

  --------------------------------
  [[ Rust ]]
  
  fn main() {
      for i in 1..=100 {
          match (i % 3, i % 5) {
              (0, 0) => println!("fizzbuzz"),
              (0, _) => println!("fizz"),
              (_, 0) => println!("buzz"),
              (_, _) => println!("{}", i),
          }
      }
  }
  
  --------------------------------
  [[ Julia ]]
  
  for i in 1:100
      if i % 15 == 0
          println("FizzBuzz")
      elseif i % 3 == 0
          println("Fizz")
      elseif i % 5 == 0
          println("Buzz")
      else
          println(i)
      end
  end
  
  --------------------------------
  [[ Hy ]]
  
  (for [i (range 1 101)] (print (cond
    [(not (% i 15)) "FizzBuzz"]
    [(not (% i  5)) "Buzz"]
    [(not (% i  3)) "Fizz"]
    [True            i])))

  --------------------------------
  [[ Crystal ]]
  
  1.upto(100) do |v|
    p fizz_buzz(v)
  end

  def fizz_buzz(value)
    word = ""
    word += "fizz" if value % 3 == 0
    word += "buzz" if value % 5 == 0
    word += value.to_s if word.empty?
    word
  end
  
  --------------------------------
  [[ Perl ]]
  
  for my $i (1..100) {
      say $i % 15 == 0 ? "FizzBuzz"
        : $i %  3 == 0 ? "Fizz"
        : $i %  5 == 0 ? "Buzz"
        : $i;
  }
  
  --------------------------------
  [[ Ruby ]]
  
  1.upto(100) do |n|
    print "Fizz" if a = (n % 3).zero?
    print "Buzz" if b = (n % 5).zero?
    print n unless (a || b)
    puts
  end
  
  --------------------------------
  [[ Prolog ]]
  
  fizzbuzz(X) :- X mod 15 =:= 0, !, write('FizzBuzz').
  fizzbuzz(X) :- X mod  3 =:= 0, !, write('Fizz').
  fizzbuzz(X) :- X mod  5 =:= 0, !, write('Buzz').
  fizzbuzz(X) :- write(X).

  dofizzbuzz :-between(1, 100, X), fizzbuzz(X), nl, fail.
  dofizzbuzz.
  
  --------------------------------
  [[ Haskell ]]
  
  fizzbuzz :: Int -> String
  fizzbuzz x
    | f 15 = "FizzBuzz"
    | f  3 = "Fizz"
    | f  5 = "Buzz"
    | otherwise = show x
    where
      f = (0 ==) . rem x
  
  main :: IO ()
  main = mapM_ (putStrLn . fizzbuzz) [1 .. 100]
    
  --------------------------------
  [[ OCaml ]]
  
  let fizzbuzz i =
    match i mod 3, i mod 5 with
      0, 0 -> "FizzBuzz"
    | 0, _ -> "Fizz"
    | _, 0 -> "Buzz"
    | _    -> string_of_int i
   
  let _ =
    for i = 1 to 100 do print_endline (fizzbuzz i) done
    
  --------------------------------
  [[ Nix ]]
  
  let
    fizzbuzz = { x ? 1 }:
      ''
        ${if (mod x 15 == 0) then
          "FizzBuzz"
        else if (mod x 3 == 0) then
          "Fizz"
        else if (mod x 5 == 0) then
          "Buzz"
        else
          (toString x)}
      '' + (if (x < 100) then
        fizzbuzz { x = x + 1; } else "");
  in
  fizzbuzz { }
  
  --------------------------------
  [[ Elixir ]]
  
  1..100 |> Enum.map(fn i ->
    cond do
      rem(i,3\*5) == 0 -> "FizzBuzz"
      rem(i,3) == 0    -> "Fizz"
      rem(i,5) == 0    -> "Buzz"
      true             ->  i
    end
  end) |> Enum.each(fn i -> IO.puts i end)
  
  --------------------------------
  [[ J ]]
  
  (":[^:(0=#@])Fizz`Buzz;@#~0=3 5&|)"0>:i.100
  
  --------------------------------
  [[ Forth ]]
  
  : .fizzbuzz ( n -- )
    0 pad c!
    dup 3 mod 0= if s" Fizz" pad  place then
    dup 5 mod 0= if s" Buzz" pad +place then
    pad c@ if drop pad count type else . then ;
  
  : zz ( n -- )
    1+ 1 do i .fizzbuzz cr loop ;
  100 zz
  
  --------------------------------
  [[ Go ]]
  
  func main() {
      for i := 1; i <= 100; i++ {
          switch {
          case i%15==0:
              fmt.Println("FizzBuzz")
          case i%3==0:
              fmt.Println("Fizz")
          case i%5==0:
              fmt.Println("Buzz")
          default: 
              fmt.Println(i)
          }
      }
  }
  
  --------------------------------
  [[ C ]]
  
  int main (void)
  {
      int i;
      for (i = 1; i <= 100; i++)
      {
          if (!(i % 15))
              printf ("FizzBuzz");
          else if (!(i % 3))
              printf ("Fizz");
          else if (!(i % 5))
              printf ("Buzz");
          else
              printf ("%d", i);
  
          printf("\n");
      }
      return 0;
  }
  
  --------------------------------
  [[ Java ]]
  
  public class FizzBuzz {
      public static void main(String[] args) {
          for (int number = 1; number <= 100; number++) {
              if (number % 15 == 0) {
                  System.out.println("FizzBuzz");
              } else if (number % 3 == 0) {
                  System.out.println("Fizz");
              } else if (number % 5 == 0) {
                  System.out.println("Buzz");
              } else {
                  System.out.println(number);
              }
          }
      }
  }
  
  --------------------------------
  [[ Scala ]]
  
  object FizzBuzz extends App {
    1 to 100 foreach { n =>
      println((n % 3, n % 5) match {
        case (0, 0) => "FizzBuzz"
        case (0, _) => "Fizz"
        case (_, 0) => "Buzz"
        case  _     =>  n
      })
    }
  }

[zahlman]

> But your comment is completely off-base.

I think it is rather your reply that is off-base; or else I have not made myself sufficiently clear.

My point was simply that the words used to describe the other courses are better fits for what SICP teaches than "procedural", which is a poor fit for describing Lisp-family languages and would make more sense applied to other contemporary languages like COBOL and FORTRAN (and of course typical Algol-family languages).

I understand perfectly well what "functional" means in the context of signals and systems. I took such a course in undergrad, 20+ years ago. But I was using abstract nouns there, rather than adjectives (and writing "function" rather than "functionality" would not really have resolved the issue).

The material in SICP deeply explores the functional programming idiom. A big part of the point of using a Lisp dialect is that functions are first-class (I've watched the OCW lectures; there's a whole section discussing what that means and entails) objects, which enables higher-order functions.

Nothing in my comment is about modelling anything to do with electronics in software.

[Jtsummers]

You may want to take your issue with the use of the word "procedural" up with the authors of SICP:

> Underlying our approach to this subject is our conviction that “computer science” is not a science and that its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology—the study of the structure of knowledge from an imperative point of view, as opposed to the more declarative point of view taken by classical mathematical subjects. Mathematics provides a framework for dealing precisely with notions of “what is.” Computation provides a framework for dealing precisely with notions of “how to.” [Emphasis in original]

-- Preface to the First Edition

[zahlman]

That does explain the use of the term. They are reasoning about the systems in terms of what will happen (its procedure), but still describing systems as compositions of parts (as nodes in an AST, effectively) rather than as lists of instructions. And they teach how to analyze problems in order to design systems that way. And, of course, writing the program is inherently a self-directed imperative; you can't simply learn how to write programs and have programs exist as a result — you have to take that initiative.

[kragen]

Your comments are clear enough; they're just mistaken.

Lisp dialects generally do not support mathematical functions, despite supporting the functional-programming idiom, which is inspired by mathematical functions. Rather, they support procedures, which in most Lisps are called "functions". In Scheme, however, the Lisp they chose for the course, they are called "procedures", an intentional choice to avoid creating precisely the kind of confusion you are experiencing. Lisp "functions", like procedures in most other languages, can fail to terminate, can raise an error, can have side effects, and can depend on mutable state.

Mathematical functions cannot do any of these things. If they could, it wouldn't make much sense to take their Laplace transforms!

The five chapters of SICP (I recommend http://sarabander.github.io/sicp/html/index.xhtml) are:

- 1 Building Abstractions with Procedures

- 2 Building Abstractions with Data

- 3 Modularity, Objects, and State

- 4 Metalinguistic Abstraction

- 5 Computing with Register Machines

— ⁂ —

You said:

> Nothing in my comment is about modelling anything to do with electronics in software.

You are mistaken about that. The part of your comment that is about modelling something to do with electronics in software is the part where you replied to a comment saying:

> ... four "deep dives" into the four "languages of engineering." There were four 15-unit courses, each about one of these "languages":

> - 6.001: Structure and Interpretation of Computer Programs (the "procedural" language, led by Abelson and Sussman)

> - 6.002: Circuits and Electronics ("structural" language)

> - 6.003: Signals and Systems ("functional" language)

> - 6.004: Computation Structures ("architectural" language)

Your comment in reply said:

> Lisp (...) can hardly be called "procedural". The core material of SICP revolves around (...) concepts that (...) have far more to do with "structure", "architecture" and "functionality" [sic] than with "procedure".

That is, you were explicitly asserting that the core material of SICP was concerned with "structure", "architecture", and "functions" in the sense of the core material of those courses, rather than only or even primarily procedural abstraction. However, two of those four courses—specifically, 6.002 and 6.004—were concerned almost exclusively with modeling electronics. (An awful lot of the "systems" in 6.003 are also electronic, but that's beside the point.) However, as you know, 6.001, SICP, and Lisp are concerned exclusively with modeling things in software.

Modeling electronics in software is a reasonable thing to do, and Lisp is a reasonable medium to do it in, but you need to understand the structural, architectural, and (at least for analog electronics) functional angles on the electronics in order to do that. None of that is part of SICP or 6.001, and Lisp is not a reasonable medium for describing electronic systems from at least the structural and functional angles. You need schematics, pole-zero diagrams, and Bode plots. If you remembered what you studied in that course 20+ years ago this would be obvious to you.

[zahlman]

> The five chapters of SICP (I recommend http://sarabander.github.io/sicp/html/index.xhtml) are:

> - 1 Building Abstractions with Procedures

Where Abelson, Sussman & Sussman use the word "procedures" here, they mean what we would typically call "functions" today. Today, "procedural programming" basically means "imperative programming", and that is not the idiom they are teaching. (Where the exact term "procedure" is used nowadays — though it's less common now — it generally refers specifically to a function which does not return a usable value, which is called specifically for its side effects. SICP instead generally describes what we would now call "functional programming".)

> That is, you were explicitly asserting that the core material of SICP was concerned with "structure", "architecture", and "functions" in the sense of the core material of those courses

By "SICP" I clearly meant 6.001 and only 6.001, since that's the course titled as such ("SICP" stands for "Structure and Interpretation of Computer Programs").

I was not asserting that SICP was concerned with any term in the sense of the core material of any other course, which is why I didn't mention the other courses in that sentence. I was asserting that SICP was concerned with those concepts as they are commonly understood.

I wrote the comment knowing nothing of the content of the other courses, because nothing about the content of the other courses was relevant to the point I was making.

Please do not try to tell me what I meant by my own words.