Just what does “code as data” mean anyway? (2014)

    int f(void) {
        int x = 1;
        return x * 2;
    }

You get nested expressions whenever you use if or a loop or call a function. C programs might be flatter on average than Lisp programs, but there's still plenty of structural editing you could do. Another example is moving an expression out of or into a loop, without concern for how many lines it takes up, whether it's a function call or a loop or anything.

The difficulty that C syntax creates for editing operations like this isn't C not having the need for Paredit-style editing, it's C not having good support for it.

That's just _your_ rationalization. I don't think it's commonly claimed that all was set in stone from the beginning. The history is there for everyone to read.

Another possible explanation is that C is so minimal (in spirit) and doesn't get in the way, people are able to pull of impressive things, which makes them love C.

And now why exactly isn't (the gist of) C sensible design? I fail to see your argument. By the way, please enjoy this cool video: https://www.youtube.com/watch?v=khmFGThc5TI

> Rather than thinking in letters, words, lines, or paragraphs, editor modes like paredit let you edit in terms of the structure of your code

So. My question is: which modern programmer thinks in terms of thinks about code in terms of letters, words, lines, or paragraphs?

The truly antiquated tools (like vi and emacs) may still handle code as if it was just text. The actual code editing tools have long been able to deal with the structure of the code. And in ways that paredit may only dream of.

> If you've ever used the XML structure view in eclipse, its the Design tab, you get a better idea.

Erm. The only "think semantically" that paredit pretends it does happens only because Lisp has a rather regular syntax. It doesn't take much thinking or work to move parts of code in and out of parenthesis, or to be able to close a matching bracket.

Actual modern tools know the structure of the code and offer much greater editing and code handling capabilities than that.

Edit:

As a trivial example. Here's IntelliJ and PHP code (yes, PHP). It understands the code, it's structure, and offers context based editing help based code structure and semantics: https://dmitriid.com/i/gm2tmnztha4tenjq.png

Speaking of semantics. Unlike the dumb "move things in out of brackets" the actual tools understand semantics of code. Once again, this is PHP (!), and the tool knows about the semantics of code: https://dmitriid.com/i/gm2tmnbtga4tanjs.png

Editing capabilities available to some other languages would blow your mind.

I have found that to be true in dynamically or duck typed languages.

I have found it to be not true in strongly typed languages with good tooling. Example: refactoring large java program in, say, Eclipse.

> Breaking up programs into more powerful little pieces is never a clean separation

I would tend to disagree, to some extent.

In Lisp(s), there are lots of small, sometimes obviously correct functions that do powerful operations on abstract data structures. Part of the reason for this is that unlike OOP (and I write Java daily) which has lots of data structures, Lisp has very few. In OOP you model your domain with new classes. In Lisp you model your domain with combinations of a few basic structures. (In Clojure...) List, Set, Array, Map.

Maybe you have layers of separation. With one layer being between primitives that manipulate your domain objects, and another layer being the logic that decides how and when to do the manipulations. I want to solve a puzzle. The puzzle board has various states, pieces, and operations that transform a board into a new board state. Then the logic layer is an algorithm or algorithms written using the layer of primitive manipulations. That logic layer may, in fact, use canned algorithms, because the data structures are common primitives. Say, sort, search, A* search, depth first, breadth first, reduce, map fn over a sequence, etc.

You can end up with a large program. But it can be a lot easier to reason about than, say, a large Java program. It seems to take more deliberate effort to keep a large java program easy to reason about.

Can you substantiate this claim? One of the reasons Lisp was used in the past was because it was particularly suited to complex, big projects... Like autopilot for spaceship, wind tunnel simulation, CAD/CAM systems, etc.

Lisp (as 'Common Lisp', the traditional dialect) has this concept of "packages" and "systems".

You can divide your code in "packages", each package contains separate namespaces for classes, function names, variable names, symbol names, keyword names and others. Thus each package doesn't collide with another package and names don't collide at all.

Many packages are combined into a "system" (by defining, for example, the required order for compilation, etc).

Thus you cleanly separate your code in packages and systems. The 100,000 line program becomes a combination of many shorter programs.

Of course this is nothing new, this is just standard practice for keeping big programs manageable.

>Breaking up programs into more powerful little pieces is never a clean separation

Care to explain? Well, i'll continue with my post. And we'll assume that what you say is true, so i'll list other advantages to keep complex systems at check.

Now, here is a big plus for complex systems: In such a Lisp, the system is hot-patchable. You can redefine functions while your program is running. Without stopping the program. We're talking about doing this even on a production environment, if necessary.

You can also redefine classes while your program is running. Without stopping the program.

Another big plus is the condition-restart system, which very few languages implement. Lisp has not only the notion of "catching exceptions", but also after catching the exception, provide alternate ways of recovering of this exception, including being able to resume operation at the point where the problem was found.

This is another big plus for building reliable systems -- and complex systems benefit from being composed of reliable parts.

I could go on with other big pluses as well. For example, multi-paradigm. Some parts are more readable (and thus easier to understand, maintenable) if written in the functional style. Others map better to the OOP style. Others would map better to the imperative/procedural style. Other would better be expressed as logic programming (think Prolog.)

Lisp allows you to use all these paradigms. So the code stays clear. I say this is very good for complex systems.

Because most people understand OO as some kind of namespace scheme. Basically to bunch together functionality under a name(class).

When people talk of OO, most of them, are actually talking about modularizing code.

rename a function

Refactoring in software development is not the same as refactoring in IDEs. Refactoring in software development is changing existing code. Specially the architectural parts.

And I agree that things are different nowadays. My main point is that this seems pretty compelling evidence to me. But, what it isn't, is a testable hypothesis. (Is it?)

Are you sure?

Reading a file in Go

    func read(f) {
        
        var text string
        var scanner *bufio.Scanner
        var err error
 
        file, err := os.Open(f)
        if err != nil {
            log.Fatal(err)
        }
        scanner = bufio.NewScanner(file)
        for scanner.Scan() {
            text += scanner.Text()
        }
        err = scanner.Err()
        if err != nil {
            log.Fatal(err)
        }
        fmt.Println(text)
    }
    

    (defun read (filename) 
        (with-open-file (input filename)
           (loop for line = (read-line input nil)
              while line do (print line))))
              

Granted, the bike shedding that goes on in our industry is hilarious. I think many people blame semicolons as one of the major hurdles to learning c nowadays. The things we fixate on...

Secondly, parentheses are a non-issue in lisp. Its almost like reading english text with spaces. After a while(quite quickly in-fact) they are a total non issue.

>>New programmers and developers look at that and compare it to something like Go, Python, or JavaScript, and all those look easier to write

Arguably the biggest problem today is programmers who are stuck at early intermediate level all life.

> if the next line is indented, anything from the beginning of the current line starting at the indent till a dedent matching the current line indent is wrapped in one set of parentheses.

Seriously, what about this?

    defmacro deftag [name]
      list 'defn name ['& 'inner]
           list 'str "<" (str name) ">"
                '(apply str inner)
                "</" (str name) ">"
    
    deftag html
    deftag body
    deftag h1
    deftag p

    html
      body
        h1 "Hello World"
        p "How's it going?"

    defn qsort [coll]
      if (empty? coll)
        coll
        let [pivot (first coll)
             remainder (rest coll)]
          concat
            (qsort (filter (partial > pivot) remainder))
            [pivot]
            (qsort (filter (partial <= pivot) remainder))

I'm perfectly happy with writing (+ 1 2 3) or whatever, the only parentheses that bother me are those that are perfectly delineated by indentation already, just as newlines perform the same duty as semicolons. They're just duplicated noise††.

† Other languages perform similar semicolon insertion, with varying degrees of success and ambiguities (JS==terrible, Go==terrific).

†† I know, you're supposed to get used to it and "unsee" them. I know, "paredit!". But seriously if you have to write a tool solely to produce noise, and you have to get accustomed to ignore said noise, well, somehow, something's off.

For example, see https://gist.github.com/coding4food/1248505

Part of this is because lisp tends to be more concise, so there are fewer expressions required. There are relatively few places where lisp adds parentheses, rather than just moving them - mostly just basic operator expressions: (+ a b) vs a + b. Adding parens (a + b) doesn't make it any harder to read.

For function calls, Algol-descended languages already use parentheses and prefix notation, they just put the parens around the arguments instead of the whole expression:

  (function argument list)

  function(argument, list)

As a motivating example for why one should use lisp, or what lisp brings to the table, it's very poor, because it is wholly unmotivating and doesn't appear to demonstrate anything unique.

Like I said, this is a very bad justification for lisp.

I've definitely got a use case for an XML version of this - a means of modifying a large file without affecting its indentation or re-ordering attributes in areas that have not changed.