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)
No macroth? Thath too bad. ;)
Which is why Python is rapidly becoming my favourite language. I find other people's python code far easier to understand than stuff written in other languages. This despite the fact that I've only been hacking python for a few months, and I've been using C++ and other languages daily for several years.
I feel that there's scope for yet another 'methodology', alongside OO and XP and all that - it might be called 'code as conversation', whereby the quality of a piece of code is judged by how readily it communicates intent to other programmers.
> if u want the extra performance boost
Maybe you wouldn't find macros so useless if you created some keyboard macros to replace ' u ' with ' you '.
Just a thought.
No, in Lisp macro's aren't used for inline functions , but for syntax extensions. For a demonstration of what real macros can do, look at The Swine Before Perl. That presentation shows how easy it is to implement special syntax for automatons in Scheme, and how natural & simple the result looks.
One less language to be used in obfuscated code contests. Where's the fun without macros and overloading? sigh....
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
The macros the article is talking about are Lisp-style macros.
These are not your "shoot self in foot" C macros (i.e. replace text x with text y), but a very powerful and expressive way to have the entire language at your disposal at compile time.
If you've seen the neat tricks you can do with C++ templates (template metaprogramming, etc), you might have an idea of what real macros would be like, when severely watered-down.
Lisp macros make things like Generic programming and OOP very simple to add to a language, as well as almost any other conceivable programming construct.
For instance, with proper macros in Java, you wouldn't ask, "When will templates be added to Java?"; you could add them yourself.
... and losing badly.
:)
Okay, C programmers, tell me why these 4 macros are bad:
#define is ==
#define and &&
#define or ||
#define until(a) while(!(a))
Tell why they're good if you think they're good, but I'm only interested in the bad argument (having lost it all day).
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
They're bad because they don't extend the C syntax, they just change it. Good macros extend the syntax, but keep the new syntax in same style as the original language. If you want to know to what your four macro's lead, look at the famous Bourne shell source code. A few simple definitions like yours in mac.h result in the horror of xec.c and cmd.c.
Flash-back to 1969 when the same arguments were put forward by assembly programmers against named functions:
History has show that user defined functions are good. People are finally realizing that lisp macros are perhaps an equally important good. By taking this position, Jabba is positioning itself on the losing side of history.Seriously, what's easier to read:
ORIf you look at it in terms of lines of code, in terms of error-prone-ness, in terms of high-level versus low-level, in terms of maintainability, ONLY AN IDIOT WOULD CHOOSE AGAINST MACROS.Okay, sorry for being ornery, but mod this scruffy post up!
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
Programming languages are similar to spoken/written language, they are meant to convey an idea. In programming the ideas are instructions to the computer and to someone maintaining the code. For each language there are pedantic ways of doing things, usually from tradition or common ideas.
/* handle errors here */
/* handle errors here */
/* parent */ /* child */
// non error condition here // handle accept error here // no matter error or not here
In C when you are writing and infinite loop for a server, the standard way to do it is
for (;;) {
if ((acceptfd = accept(...)) < 0) {
}
if ((pid = fork()) < 0) {
}
if (pid == 0) {
} else {
}
}
There are two very common C practices used in this. The first is the for (;;) {}. This is the standard way to do it because there is no comparison ever used within the loop, where a while (1) {} would seem to do the same thing it does have a comparison. Well, now it wouldn't matter since the compiler would optimize the loop anyways since the '1' is a constant, older compilers or non-optimizing compilers would not catch that though.
The second practice is the if ((x = f()) < 0) {}. This arises more out of tradition. It gets the return value of a system call and allows the error handling to be done immediately. It also helps keep the indenting level from running away.
Ammusingly enough in Java with JCSC I find that it gives warnings saying it is bad style. I would guess that it would prefer
try {
int acceptfd = accept();
} catch (Exception e) {
} finally {
}
From a C background I find this abhorrent. Look at the level of indentation required! Evil!
Well, what does that have to do with #define or ||? Tradition. C programmers are used to seeing "||" as an "or". There is no keyword "until". If a C developer is hired new into the place he will have to learn the idiosyncracies that this place uses.
Specific arguments against using macros to extend the language are that you are in effect adding keywords to the language. In effect "or", "and", "is" and "until" are now keywords in C. Since these are not part of the language normally, any code that uses any of those as a variable will now have issues.
Well, who would use "or", "and", "is" as a variable name? Well, look at the linux kernel code and you will find that "new" is used occasionally, which causes the kernel to not be able to be compiled with a C++ compiler. I would also argue that "or" could easily mean outputReport and "is" quite often means inputStream to me.
By using this "or", "and", "is" nonsense you are also leaving out the possiblity of using similar ideas for bit fields. You could use "xor", but you would need a "bor" for bitwise or'ing of a field.
Basically what I see by using the macros here is that you are limiting yourself to a number of poor programming practices. When you use these you will be confusing real programmers and potentially inserting errors into the code. In C "||" is well defined and any C programmer is able to understand it. "or" on the other hand is ambigious to C programmers since it is not part of the programming language.
Norris/Palin 2012
Fact: We deserve leaders who can kick your ass and field dress your carcass.
>> if u want the extra performance boost
>Maybe you wouldn't find macros so useless if you created some keyboard macros to replace ' u ' with ' you '.
>
>Just a thought.
Maybe yoyou woyouldn't find macros so youseless if yoyou created some keyboard macros to replace 'you' with 'yoyou'.
Jyoust a thoyought.
There are no trails. There are no trees out here.
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.