Slashdot Mirror
Why Java Won't Have Macros
bugbear writes "Carlos Perez has just posted a page that quotes Sun Java 'theologist' Gilad Bracha about why there is no plan to add macros (in the Lisp sense) to Java."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
Well, that depends on the language. In Common Lisp and most other Lisp dialects (not Scheme tough), macro's are normal functions that are run at compile-time instead of at run-time. They can do everything normal functions can do, such as calling other functions, doing I/O, etc..
You're completely right of course. But as many people are complaining macro's don't fit in Java's everything-is-part-of-a-class philosophy, I'll just point out you can easily put macro's in classes and use them like this (assuming you have an OpenGL class):
given this statement
...has anyone declared Perl *the* LFSP? I can't think of a more abstract and unreadable language off the top of my head (Cobol doesn't count just because the younger generation has never used it).
The real point is that LFSPs (Language for Smart People) have a much greater support for abstraction, and in particular for defining your own abstractions, than LFMs (Language for the Masses).
--trb
If you have higher-order anonymous functions in your language, than it's easy to do this kind of thing by turning the binding inside-out and making it an argument to the rest of the code. In general macros that bind variables or have effect are trouble, because, for one thing, the scope of declarations is "open."
I used to be a crazy cowboy C programmer, and I loved macros more than anything. But seriously, functions go a long way, as long as they are syntactically brief (anonymous) and semantically powerful (nestable, higher-order). I program mostly in SML these days, and hardly ever wish I had macros.
Java, and about every non-Lisp language, lacks syntactic extensibility. Yet, Java programmers obviously consider Java syntax to be not usable for a lot of everyday tasks - hence the ever-growing number of special mini-languages around Java, like Ant-XML, XDoclets, JXPath, to a degree even XSLT.
Of course it is possible to implement such DSLs in Java, but you typically end up writing an interpreter, and that usually means that, if you want to use the DSL in your program (say, evaluating expressions built at runtime), you end up manipulating strings and feeding them to a huge, opaque interpreter machinery - which is error prone and the hell to debug. And, by the way, one of the things people often call one of the biggest problems of macros, when they only know C-style ones.
Basically, much of what macros allow you to do is already done in the Java world, just without the language supporting it, and hence in slow, buggy and hard-to-debug, often ill-specified ways.
Programming can be fun again. Film at 11.
But you see, that uncertainty, that new language I need to read, is what java develoeprs shouldn't have to deal with. It's like Java and SQL. EJB solves a lot of that, "I need to know SQL to get stuff from the DB." The exception is when you have to define finder functions in your configuration. Point is, it doesn't change how java looks. No syntax changes.
That's prolly what java doesn't want. Syntax changes done by something like macros, or from what you've pointed out.
-
ping -f 255.255.255.255 # if only
Programming languages are cultural artifacts, and their success (i.e., widespread adoption) is critically dependent on cultural factors as well as technical ones.
So the idea is to gain wider adoption by not implementing powerful features that might make code harder to understand. That should sound pretty familar to people who use VB... Not that there's anything wrong with that.
Quickly now, can you tell me if 'char' is signed or unsigned by default on your C++ compiler? Or how long is an 'int'?
It's a simple matter to change those definitions in a single place, but if you change compiler you may have to refactor a whole lot of your code to keep it compatible. Using the typedefs you will always know that a DWORD is an unsigned 4-byte value and a LPSTR is a pointer to signed bytes.
Java has labeled statements, so you can put a label on the outermost loop statement and then simply write "break label;" when you have to exit all the loops.
Sig (appended to the end of comments I post, 54 chars)
The problem with macros, is they sorta defeat Java's OOP.......Sounds awfully like a procedure/function to me.
Sounds like you are bashing procedural. There is no evidence that OOP is objectively better than procedural. For every "fault" you can find in procedural, I bet I can either find a better procedural way to do it, or find flaws with the OO approach also that you either never thought of, or ignored out of habit.
(PS. If you tag this message "flaimbait", then please tag the parent also. Them'r the one who started the paradigm war. As far as macros being good, I am on the fence on that one.)
Table-ized A.I.
While laziness can be a virtue for a good programmer, the truth is that Macros lead down that ugly slippery slope that ends in completely unreadable code. It may work great for a few programmers, however once you start working on large projects with many people coming and going you end up with a freaking mess.
Just about any tool/feature can be turned into a mess maker. There is no language that jabs stupid programmers in the eye when they get stupid (other than maybe crashing or buggin' out and being hard to debug).
However, I will agree that some features can be downright ugly in the wrong hands. I would rather debug sloppy Pascal than sloppy Perl, for example. But, that might not necessarily be my same choice if it is my own code that I have to work with.
Table-ized A.I.
Java is clearly a syntactically constrained language. As a programmer seeking to build a powerful library or problem solving toolkit for a complex application domain, this can be annoying. And several others have pointed out that this seems to keep resulting in people creating meta-languages (XML-based or otherwise), code-generators and the like for complex Java projects because they are needed to solve certain kinds of problems in an efficient manner. This is certainly true, and such systems can become rather ungrokable fairly rapidly. However, you can generally isolate such complexity from the hordes of mediocre developers who are there to pound out mediocre, simple code.
With LISP, or even C/C++, the power is there all the time. Programmers will inevitably try to use the tools they learned about in school and _will_ shoot themselves, their development projects, and their managers in the foot. Java creates a hierarchical system of complexity - most Java code is universally readable, and if there is a need to learn special metalanguages (EJB descriptors for example), they are usually highly constrained XML dialects, separated out from the rest of the Java code. Sure, there's an XML parser and code generator that only one guy really understands and can maintain, but if that lets the rest of the development team pound away on their mediocre code in standard, vanilla Java, and edit some simple XML documents, then it makes software development more efficient.
When you are managing mediocre people, you can appreciate the benefits of having them work in a language that prevents them from doing too much damage. Development is more predictable, bugs tend to be more apparent and less insidious, even though it's not always the most powerful or most efficient language for every problem domain. Of course, there are a lot of domains where you'd be crazy to try to use Java. And when you tackle those problems, you need to hire better developers who can handle the power of LFSPs (or at least languages with more foot-shooting power).
And I consider Python to be comparable to Java in terms of readability. It is similarly somewhat syntactically constrained, with relatively few obvious mechanisms to accomplish a task, as opposed to way too many mechanisms to accomplish a task - and I love the forced code indentation as well (it forces consistency of style, another readability barrier). Where Python loses out is its far less comprehensive, standardized or well documented API, though I'm sure Jython has come quite a ways since I last looked at it (Python code + Java API - potentially a very good tool for scripting use in large Java projects). However, for larger software projects involving a large number of modules and many developers, a weakly typed language fails utterly - you need strict enforcement of method contracts and object typing that you get from a strictly typed language. This goes a long way to improving code readability and modularity for larger projects, and lets you catch many simple errors during compilation instead of having to rely on yourself to catch them all, or waiting until runtime to find problems ("oh, of course, I need to pass method foo an Orange object and two strings, not an Orange, a Grape and an integer").