Re: Seeking computer-programming job (Sunnyvale, CA)
On May 15, 6:31 pm, t...@sevak.isi.edu (Thomas A. Russ) wrote:
"eric-and-jane-smith" <nore...@nospam.com> writes:
Macros in other programming languages often seem to obfuscate the code =
as
much as they improve it, such that there may be little or no net gain. =
But CL macros can make the code orders of magnitude clearer, easier to
read, easier to work with, and less error prone. There is a powerful
synergy between the different advantages of CL macros, such that knowin=
g
them as a list of advantages is not enough to understand their real
power.
Yes, a good point.
I've lately decided that I really like the example of WITH-OPEN-FILE as
an example of a nice Lisp macro. OK, it's already in the language, but
the important point is that it would be something easy to add if it
WASN'T in the language. This exposition can proceed by looking at the
problem it was put in to solve, and comparing it to two Java solutions.
Problem: When you open a file, you have to remember to close it, even if
the code using the file happens to throw an exception.
OK. The standard Java solution would be to use "try ... finally":
OutputStream out = null; // Needs definition outside try blo=
ck.
try {
out = new FileOutputStream(filename);
// do stuff
} finally {
if (out != null) {
try {
out.close();
} catch (IOException ioe) {
// Do something like log this.
}
}
}
So, this is just a bit cumbersome, because you have to remember to
declare the variables in the correct place, remember to put in the
finally block, with appropriate safety checks. Note that because the
close() method can also throw an exception, you have to wrap it in its
own exception handling block. That's a lot of infrastructure that you
need to write around the file handling code that you really care about,
namely the "// do stuff" part.
Note in particular, that STATIC TYPING DOES NOTHING to enforce this type
of good programming practice. That's because it isn't a type error, bu=
t
an oversight in program strucure. Macros, on the other hand, allow you
to easily capture such good practice.
[Aside: There has of late been a lot of "excitement" about pattern-based
design. This is all well and good, but it is something that,
essentially, Common Lisp has had all along through the judicious use of
macros. In fact, lisp has gone beyond the notion of mere patterns and
instead calls this aspect the process of building a Domain Specific
Language (DSL)]
Now, you can, in fact, write the same thing in Common Lisp, yielding a
program that looks kind of like this:
(let ((out nil))
(unwind-protect
(progn
(setq out (open filename :direction :output))
;; Do stuff
)
(unless (null out)
(close out))))
where we set up the same basic structure. Now, since we nearly always
want to do something like this when we open the file, we would like to
have a safe way to do this that is convenient and gets the details
right. So we take the basic outline of what we want and write a macro
that embodies this particular idiom:
(defmacro with-open-file ((var filename &rest open-options) &body body=
)
`(let ((,var nil))
(unwind-protect
(progn
(setq ,var (open ,filename ,@open-options))
,@body)
(unless (null ,var)
(close ,var)))))
So now we have a macro that automatically handles the task of opening a
file and remembering to close it. That simplifies our code to the more
perspicacious and correct, because the macro has been carefully
constructed:
(with-open-file (out filename :direction :output)
;; do-stuff
)
This also allows us to concentrate our attention on the actual DO-STUFF
part, which is the variable part of this endeavor and the place where
logic bugs can occur. We don't have to bother ourselves looking at all
of the boilerplate and making sure we got it right, since we've already
gotten the boilerplate parts correct in our macro.
So, how would one go about doing something similar in Java. The real
crux of the matter is that there isn't any facility in the language that
allows you to introduce a new control structure that allows you to
insert your actual program into the middle of some combination of
existing constructs.
As near as I can tell, the method one would need to use involves
encapsulating the program you want to execute inside a (possibly
anonymous) class with a defined "run" interface so that it can be
executed. That would involve something along the lines of
public interface FileProcessor {
public void processFile (OutputStream out);
}
public class ProcessFile {
public static void processOpenFile (String filename, FileProcessor wo=
rker) {
OutputStream out = null;
try {
out = new FileOutputStream(filename);
worker.processFile(out);
} finally {
if (out != null) {
try {
out.close();
} catch (IOException ioe) {
ioe.printStackTrace();
}
}
}
}
}
OK. With this infrastructure defined, we can now write code that looks
sort of like this:
ProcessFile.processOpenFile(filename,
new FileProcessor=
() {
public void p=
rocessFile(OutputStream out) {
// do stu=
ff
}
});
where we create a new anonymous class instance to encapsulate the body
of the code that we want to execute.
So, it is possible to build up such abstractions in Java, but to my eyes
that looks a lot clunkier and less integrated than the Lisp macro
solution.
The "Spring" Java framework uses this pattern alot in its so-called
"template" classes, which help removing part of the boilerplate from
using some of the most common Java libraries. For example, when using
Hibernate (most used Java ORM) you have to write something like this
all the time:
//sessionFactory is initialized once and then reused everywhere
Session session = sessionFactory.createSession();
Transaction t = session.beginTransaction();
try {
//do stuff
t.commit();
} catch(HibernateException e) {
t.rollback();
} finally {
session.close();
}
While Spring gives you something like
HibernateTemplate tmpl = new HibernateTemplate(sessionFactory);
tmpl.doInHibernate(new HibernateCallback() {
public void dontRememberItsName(Session s) throws HibernateException
{
//do stuff
}
});
This is IMHO not only much uglier than a Lisp macro; it's really
conceptually different. It's more like
(do-in-hibernate (lambda (session) ...do stuff...))
where do-in-hibernate is a higher-order function, not a macro. This
might not look like a big difference to someone that is not accustomed
to macros, but can quickly become a pain in the @$$ if you start
nesting many pseudo-macro calls like that. Plus, the code loses some
of its "declarative" look, and loses big functionality too - no more
tampering with the lexical environment is allowed, including voluntary
variable capture, local declarations, etc. and also no more code
walking to analyze and transform user-provided code, since it's hidden
in a lambda. Of course, these are advanced concepts - I myself really
used them just a few times, mostly for experimentation - but knowing
they're possible gives you another weapon against the hardest
problems.
You see, there isn't any way of introducing new forms into
Java that look like the language itself. So there isn't any way to add
your own control structure construct that looks like
with_open_file (out, filename) {
// do stuff
}
which would be the real equivalent of the Common Lisp macro solution.
In fact, with-open-file style macros are so useful that IIRC the
designers of C# built them into the language, with the using(resource)
{ ...code... } construct. Of course, language designers can only
foresee a limited set of patterns that can have the dignity of a
dedicated language construct. So, you're out of luck as soon as you
encounter a pattern the language designers haven't included, unless
you have macros.
So this is a very simple example of what is meant when lisp programmer=
s
talk about using macros to write code that is correct, and a very
simplistic example of how we go about writing DSLs to solve problems, by
removing the superstructure required by the programming language from
sight so we can concentrate on getting the actual business logic right.
Really good points. I'll save your post and show it to my fellow
coworkers - all Java developers ;)
(To be fair, this is not much a Java problem but a general non-Lisp
problem ;-) In fact, Java is pretty advanced for being a "mainstream"
language - compare for example with C++ and its total lack of dynamic
typing, no reflection, no garbage collection, no anonymous classes
that can at least simulate closures, etc. etc.).
Alessio