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)
-n
http://www.remix.net/
No macroth? Thath too bad. ;)
That was an obviouth joke.
Tho thue me.
macros are useless, theyr just inline functions, if u want the extra performance boost for inline code, just declare a function final...
Great Atrocit
Just to clarify further why macro's are bad.
The problem with macros, is they sorta defeat Java's OOP. Think of it. Defining a symbol, just to be replaced in thousands of other places where it's written, tied only to the global space.
Sounds awfully like a procedure/function to me.
If you tied macros to objects, they'd just be inline methods. So there really is no point.
-
ping -f 255.255.255.255 # if only
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.
Thanks for the suggestion. Yes, we do know what macros are, and we may have even heard of Lisp. Seriously, some formulations of macros are well structured enough to prevent the onerous kinds of abuse that have given macros a dubious reputation in the C culture.
A tacit admission that good text-replacement macros are a whole lot harder to do than S-expression macros, perhaps?
One less language to be used in obfuscated code contests. Where's the fun without macros and overloading? sigh....
Oh, macros, one "s". Gotcha.
It's difficult enough without macro's, so why would you need them? The advantages of Java is that everyone can read a Java program and understand what is going on. User defined macros destroy that property.
Overrated? How can the only moderation done to parent be "overrated" if it's never been rated before? "offtopic" perhaps, but "overrated"?
Feature request for slash: the first moderation to a comment can't be "overrated" or "underrated".
Well, obviously it's "underrated" now. "funny" is also an acceptable answer. Help me rebuild my karma rating or I'll never be able to get a loan.
... 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!
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
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.
good lord that is awful code... thanks.
but still: why is it bad?
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Eh, there are some things you can't do with this approach that you can do with macros. A (fairly trivial) instance in my example is how it lets you specify a variable name (color), which then gets bound to the color of the window. Uses of "color" in "non-boiler-plate-code" thus handily become references to the window's color.
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.
Please to note my post said ' u ' to ' you ' - see the spaces? I put those there just for someone like you, Elwood. :)
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.
To answer your question though, how would you like it if you had to read over and work on someone elses code and they had aliased all the symbols to something different?
The example doesn't really add up -- stick that code in a utility class static final method and it'll inline. You probably wanted something that'd actually transform its input instead of just saving some typing. Most lisp macros need to work on the parsed form of the sexp that is their argument, splicing bits in here and there, inserting control statements or special forms that wouldn't work in a function. Java has neither the sexp format nor any special forms in such formats that would lend itself to a macro facility like lisp.
Anyway, if you really want to extend the language in a clean way, just use OpenJava like everyone else does. As long as OJ is developed independently from Sun, it stands more chance of being actually being useful and not crippled.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Ack. Pthpt. [thump]
There are no trails. There are no trees out here.
Common Lisp defines no "while" form. Nobody complains about this, because its easy to write a macro to implement while:
Here's a sample call that flips a coin until getting a tails, printing BORK for each heads flip:IMHO this is prettier and more intuitive than the function-passing approach:Where "(\ ()This approach is what I'd call "too dang inconvenient". :)
I think history bears me out that macros are the superior approach, as most languages do NOT implement while as a function. ;)
Also there's an efficiency argument to be made against passing too many functions with "closed variables", as this will often cause those variables to be heap allocated instead of (faster) stack allocated. On the other hand 99% of the time you've got a fast enough computer to not care, but I have had times where the efficiency matters.
To really get off topic, even for this thread, I like LISP macros, because they can do dangerous things like variable capture. Perl has almost every flow control construct binding $_ to the most recent interesting expression. If I wanted to add that functionality to LISP, I could easily do so without touching a line of source code. I create my own package that uses most of the symbols from the lisp package, but has its own definitions for if, while, etc:
Presumably users of these functions will intentionally refer to the symbol "it" to get the test result. That's all there is to Perl's $_. I don't think you can do this by passing around functions. (in any case not prettilythe "and" and "or" macros you showed are in fact part of ISO C++ and C99. #include (or ciso646 for C++) and see for yourself. Personally, I love 'em.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Look closely, that's why I gave it a symbol to pass into which it loads the window's color. And yes I did tack it on at the last minute as a bulkward against just this kind of post.
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.
As opposed to ... Do your prep stuff ... ... Do your post stuff ...
someMethod(Object something, Method todo) {
todo.invoke(something, null);
}
Yeah, it's just sugar. It's a shame that more folks don't use reflection - it's mighty powerful stuff.
> Where "(\ () ...)" is my made-up syntax for introducing a function of 0 arguments with "..." as its body.
:) I think history bears me out that macros are the superior ;)
;)
Why not make up a simpler syntax, then? You could use a single character for suspending code with zero arguments, and then the use of the while example would be only two characters longer than the lisp macro version. (Lisp programmers surely cannot complain about two extra characters, as their language is filled with extra verbosity!)
The advantage of such a system is that it can be explained simply in terms of other features in the language, and so it behaves rationally. You can't incur capture or otherwise violate the scope of variables (except in the ways that lisp already does), you can't change around the code that is passed in (except in the normal lisp way, again) and most importantly a programmer can look at a piece of code and know "what it does" at the same level as he looks at other code. For the uses of macros that I think of as good coding practice, this is certainly possible.
> This approach is what I'd call "too dang inconvenient".
> approach, as most languages do NOT implement while as a function.
Well, most languages also do not implement it as a macro. As a lisp programmer, do you REALLY want to argue that the popular historic ways is the superior way? (In fairness, I think you have a good argument, but this isn't it!!)
> Also there's an efficiency argument to be made against passing too many functions with "closed variables", as this will often
> cause those variables to be heap allocated instead of (faster) stack allocated. On the other hand 99% of the time you've got
> a fast enough computer to not care, but I have had times where the efficiency matters.
I don't know what "closed variables" means; do you mean an environment? Who says a compiler has to heap-allocate closures? There is an efficiency issue, sure, but this is not something that the programmer should have to deal with. A good optimizer should be able to tell that inlining the 'while' function turns its arguments into beta-redices, and then you end up with the same code that the macro pre-compiler produces.
> I don't think you can do this by passing around functions.
No, because this is precisely the kind of hack that makes lexically-scoped functions nice and macros unhygienic!
On the critical side:
Suppose I'm sitting down to maintain this. Does "or" mean logical or or does it mean bitwise or? I have to guess from context or look at the header file. As Dilbert said in the TV series, "it's not that it's difficult, it's *unnecessary*". Does that header file ever change? Which version of the header was in use when the code I'm looking at was written?
Worse, suppose I don't look at the header file and think that "until" has the same semantics that it does in other languages, namely always executing the body at least once. Ouch.
They're also bad if you are a believer in the philosophy "syntactic sugar causes cancer of the semicolon" (Alan Perlis).
That was pretty smart of u.
-no broken link
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.
I'd appreciate it, though I suppose I could run cpp on my java source, but I'd rather that javac handled it for me.
You can't judge a book by the way it wears its hair.
Point taken.
I think when you get down to the nitty gritty language implmentation most languages implement it as a macro with labels and goto. That their macro language isn't exposed to the user is not completely germane.
Exactly.
Well, consider we've got our "while" implemented as a function in while.o. All the callers of "while" in foo.o, bar.o, and baz.o pass stack allocated environments to while. While looks like this:Then late one night a disgruntled employee does this:This means that the nth call to while will use the (n-1)th call's test clause. The next morning your "make world" rebuilds while.o, but in the meantime foo.o, bar.o, and baz.o will still pass stack allocated environments to a function that expects the environment to be valid across multiple calls. Bus errors ensue. What this boils down to is that you need a new keyword to tell the compiler your passed function+environment will be stack allocated or heap allocated. The optimizer can't make the decision unless its inlining the function call. (And sometimes you can't inline function calls, like when you compute which function you'll be calling
I love that word when applied to macros! I feel sooo dirty
Ah, I've never gone to the trouble to translate what Java means by "reflection" into terms I fully understand. What does it mean in this context?
That code snippet you posted seems to invoke a computed method (todo) on a computed object (something), and pass it a constant argument (null). This is reflection?
For the same reason the following:
typedef int DWORD
typedef char* LPSTR
(yes, burn in hell Microsoft)
are bad. There is a delicate balance in a language between the added intellectual overhead of introducing a new statement versus the savings in time and increase in readability. To something as simple as a function call:
do_foo(5);
When a programmer sees that call, he has to think, "well, WTF does do_foo() do?" Now, if do_foo() is well named, and wraps a lot of other code, the added intellectual overhead of understanding what do_foo() is and what it does is outweighed by the time and energy saved reading and understanding all the code in do_foo(). Now, in these other examples, the intellectual overhead is relatively high (if only because a programmer can easily become suspicious that those macros must be doing something more, because why would anyone create such a simple 1:1 mapping to a built-in feature) and the payoff is zilch, because C programmers except to see || rather than 'or'.
A deep unwavering belief is a sure sign you're missing something...
could you post an example from outside the academic sense of comp sci in a language that anyone actually uses outside of academia?
Oh my god. ... Is THAT what the original UNIX source code looks like? I'm going to have nightmares now...
--jeff++
ipv6 is my vpn
> I think when you get down to the nitty gritty language implmentation most languages implement it as a macro with labels and
> goto.
Yeah, well, that's how functions are implemented too.
> What this boils down to is that you need a new keyword to tell the compiler your passed function+environment will be stack
> allocated or heap allocated.
You're right, if while lives in a different module and your module system only lets you specify the most basic things about the symbol. But lots of compilers do cross-module optimizations, and in this case a proper leaf procedure where the argument functions don't escape (like the original implementation of while) could be called with pointers to closures on the stack without any problem.
Also, some programs that does loops in irregular ways (such as non-recursive searching programs that backtracks) can be rewritten in a way that is much more readable IMHO. Alas, it is still as hard to make sure such code is correct, since you still have to follow every possible execution path, so it doesn't make the writer's life better.
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.
Red Alert: To anyone reading Piers Haken aka Spongman's posts.
.com pontificating bullshit and misinformation on Slashdot.
He is a liar who claims to have worked at Microsoft (he thins this justifies his blind Microsoft zealotry). The loser who never really worked there.
He now works as a low end grunt at a dead
He is basically your run of the mill Iraqi Information Minister Muhammed Saeed al-Sahaf of programming, minus any interesting humor and a bunch of IQ.
Red Alert: To anyone reading Piers Haken aka Spongman's posts.
.com pontificating bullshit and misinformation on Slashdot.
He is a liar who claims to have worked at Microsoft (he thins this justifies his blind Microsoft zealotry). The loser who never really worked there.
He now works as a low end grunt at a dead
He is basically your run of the mill Iraqi Information Minister Muhammed Saeed al-Sahaf of programming, minus any interesting humor and a bunch of IQ.
You are a fucking god damn cum guzzling fucking queer. Not a normal homosexual, but a smelly dog-raping boi-loving sociopathic fucker. Man, you make me sick. For those of us who know of you, we know about your little nightly soirees with married men at various turns off in the Bay Area. You are a fucking anal madman. But people are going to find out you are a bug donator, giving disease not only to bug-chasers but innocent gays, women and other helpless beings.
.com and a former Microsoft droid.
Now you come here, and plausibly deny your true Hydian self with this facade, the charade, this act. You, a programmer for a dead
The entire summation of your existence is nothing. You have a hard time accepting this. You are a blip. A genetic mistake. A poster child for birth control and legal abortions. You are the reason that the death penalty isn't easily abolished.
We see at the DNA lounge. We know you are there, seeding hepatitis on toilet seats.
Well, what does that have to do with #define or ||?
Nothing. The point of macros facility in question isn't C-like preprocessor string substitution, but the availability of full language at compile time to do code generation.
Think of defining your own object systems, domain-specific languages, encapsulating boilerplate code and similar rather than of defining constants and changing language keywords to silly names.
Lisp is the Tengwar of programming languages.
Please re-read the original post I was replying to and the one I wrote. Thanks.
I personally do like the macro capability of C. I think it is a useful tool for putting common code in places where a function is overkill. Like doing a bitwise operation, such as in fcntl.h (if memory serves) for checking read/write permissions on files.
Norris/Palin 2012
Fact: We deserve leaders who can kick your ass and field dress your carcass.
So, for example you could write a macro that takes a variable, a list, and a statement and returns a for-loop that iterates over the variable, and call the macro, say, 'foreach'. Or you could write a macro that takes a boolean expression on a set of classes and return a statement block to do some JDBC calls and create a bunch of objects that represent the join of that expression. Or... (substitute here anyting you do on a regular basis that can't be made into a method).
Please re-read the original post I was replying to and the one I wrote. Thanks.
I was browsing at +4, and the direct parent didn't make it through. Sorry for the way-off reply.
Lisp is the Tengwar of programming languages.
No problem... try at +2 or +3. And set to ignore karma bonuses. Usually the s/n ratio is adequate at that level.
Norris/Palin 2012
Fact: We deserve leaders who can kick your ass and field dress your carcass.
Functions were only "overkill" when compilers weren't smart enough to inline them.
Strictly-sized typedefs have value for defining file formats or wire protocols, but it's better to use native types everywhere else. But Microsoft's are pretty lame--they implicitly claim "word" means 16 bits when in fact it's the machine's word size (usually 32 bits today), and LPSTR is pointlessly obscure (if it's always "char *", what's wrong with writing "char *"?).
#define IS_EXECUTABLE(x) x&0x01
/*
Do you really think that is worth creating a function? I don't think so. Especially if you are going to document it.
* And input against executable bit mask.
* x is an input bitfield
* returns non zero if input is executable
*/
int is_executable(int x)
{
return x & 0x01;
}
Nope, not worth it in my book. You cannot rely on your compiler to optimize it out. It'd be nice to assume every compiler will, but you simpley cannot know for sure it will. Some embeded compilers are not upto snuff with icc or gcc. Sure, you can specify "inline" however just as with the "register" keyword it is only a hint to the compiler.
Norris/Palin 2012
Fact: We deserve leaders who can kick your ass and field dress your carcass.
What makes you think the heap is slower? A copying collector (unlike malloc/free) can allocate memory by bumping one pointer. And you don't have to copy an object to allow it to live beyond the current funcall. And you get continuations for free.
I'd go for the function, no question. It requires no more documentation than the macro. It's typesafe and never re-evals its arguments. The debugger can step through it. In C++ it's confined to a namespace (things don't blow up randomly if someone wants to name anything else IS_EXECUTABLE), can be overloaded for your own types, and passed to higher-order functions ("how many objects in this collection are executable?"). If your code generator sucks, the extra funcall is the least of your worries.
And macros are error-prone. For instance, yours should be ((x) & 0x1) so that complex expressions inside or around it are parsed correctly.
add an #include and you get much of that.
as for LPSTR, the problem with writing "char *" is that you don't necessarily know whether or not the chars being pointed to are signed.
Uh...unsure.
Well it sure can't be any faster, since free-ing stack allocated memory takes zero time -- you already have to bump the stack pointer for function return. Stack allocation just adds a (usually) constant number to the already constant stack bump. I don't know what a "copying collector" is, but if it takes 1 cycle to allocate or one cycle to garbage collect (GC) or 1 cycle to free, its for sure slower than stack allocation.
The language I used where heap spam became important used a "mark & sweep" GC algorithm. In our case it wasn't the allocation time that was killing us, but the frequency & expense of the GC getting too high.
Quickly now, can you tell me if 'char' is signed or unsigned by default on your C++ compiler? Or how long is an 'int'?
>>>>>>>>
In the common case, you're not supposed to care about the exact details. There are a few cases where you should be using specific-sized types (when dealing with file formats and such) but most of the time you're supposed to use the native types because it allows the compiler to use whatever exact sizes are best for the platform. In case where you need to know sizes because of range issues, then you're supposed to use the standardized limits headers. Microsoft's tendency to redefine standard features like this is just one of the reasons why Win32 sucks so badly compared to POSIX.
A deep unwavering belief is a sure sign you're missing something...
And somehow I don't think they meant to use a nonstandard meaning of "word". They just started using it in a short-sighted way and then had to declare it incorrectly (memorializing their ignorance) for Win32 and Win16 to be compatible. Probably the same people who think a "byte" is always eight bits instead of using "octet".
If your point is "LPSTR is always signed", as far as I can tell you're mistaken. I never believed that or even heard anyone claim it until today, the docs don't say so, and <winnt.h> from the Platform SDK doesn't try to make sure it is (neither do the Visual Studio 6 headers, and Visual C++ can go either way depending on the /J option). Can you substantiate this at all?
Where do you get "everyone at MS is complete fools" out of what I said? I know people there, and they aren't. "Byte" and "word" date back to, what, the 50s? Ignorance about them is widespread, and it only took one sloppy maintainer to codify a mistake that really can't be fixed.
I guess it shows just how much the Java Community Process is worth when someone from Sun comes out and says "Java will not have X because we say so".
Things that appear to be on the fringe, Sun ignores it. Is that bad? Ask yourself this "do I have time to follow every thought and request of my customers every minute?" The answer is probably going to be "no, I have limited time and resources."
Only thing whiners achieve is noise. Do something about it and become part of the JCP, write a reference implementation and get other developers to support it. What's so hard to understand about the process? It's call process because it takes time and effort, otherwise it would be called "java magic lamp" and anyone could just make a wish.
I think you've confused C macros with
Lisp macros (hygenic and non-hygenic).
The two are quite different. C macros are
extremely simple; kinda like comparing ed
to emacs.
The article, and my post, are talking about Lisp macros. Well the article is more talking about scheme macros, while I'm more talking about (wacky, dangerous) Common Lisp macros. The reason the CL macs are wacky and dangerous is because novices often write macs that do unintentional variable captures and unintentional muliple evaluations of the same form.
That's Bourne for you, he didn't like C's punctuation.
sh(1) has remained very stable from the late 1970s through the present. That coding style had a lot to do with it. sh(1)'s stability insured that features were added as external commands instead of shell builtins, as everyone from MS NT, DEC VMS, IBM JCL did, making scripts not so backwards-compatible. That in turn enforced unix's component software tools philosophy.
you know, haken, he nails your fucking ass in the following arguments.
anyone with any technical acumen does.
you are a liar, farud jack of all trades master of none fucking fool. your fucking bullshit is not needed here. you fucking liar. fraud. what a stupid motherfucker. i nailed your ass. i nailed it. i fucking nailed you in lies and nailed you in your fucking flawed thinking. i love watching you get bitch slapped by others, too. FUCKING FOOL.
Macros are great if you have a lot of repetitive code that you can't get around doing (i.e., you can't just create and call a method/function to do xyz for whatever reason). This doesn't happen in Java much, at least not that I have found. But I used to have to do data processing in this obscure, unmentionable scripting language, and once I taught myself the macro syntax I was able work faster and make the QA dept's life a lot easier.
I'd be willing to bet a good bit of money that you have little or no significant real-world programming experience.
No, but please go ahead. Declare PERL the language of choice for under-ego'd nerds with thier heads up thier own buts, a desire to overcomplicate everything and prove themselves by coding unmaintainable line-noise in as 'clever' a mannner as possible and no appreciation of Martin Fowler's comment that "any fool can write a program that a computer can understand. The difficult thing is to write code that other people can understand"
The order of operations for your macros may not be clear, or it may be unexpected. Consider that in C, && has a higher precedence than ||, and so will your and have over or, but when a programmer reads the long-hand names, the property is quite possibly counterintuitive
That sir, is a very good point and I thank you for pointing it out in this argument
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
You can do what iContract, sqlj, and jsp did and invent one from scratch.
If you are Sun you can add to the language. Some kind of "for each" is being added to JDK 1.5.
The two views that I vacilate between are:
1. Java sux and should be dumped for Lisp, Python or Ruby
2. Java is widely used and macros will help it evolve