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

In Java, I could use a bytecode manipulation library to read in a class file, manipulate it by using the library's API to add, modify, delete members of the class. Then write the class back out as a file.

Code becomes data and is manipulated as date and written back out.

In Lisp 'code is data' is so much more natural because code IS the most elementary data structures of the language. No need for a library to manipulate code behind an API. The API is the language primitives. The code is the data structure you manipulate using language primitives.

  deftag "html"

  html = tag "html"

The lisp that didn't win is not an acceptable lisp.

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.