Re: FreeMarker, ANTLR & New FreeMarker Template Notations [was: JetBrains / IntelliJ IDEA v8 to Support FreeMarker!]

Daniel Dekany <[email protected]>
Newsgroups gmane.comp.web.freemarker.user
Message-ID <[email protected]>
Thursday, April 3, 2008, 12:41:44 AM, Jonathan Revusky wrote:

[snip]
>> Both are general-purpose programming languages that target the JVM and
>> interoperate with existing Java libraries. Scala aims to integrate 
>> functional programming with object-oriented programming. Scala's 
>> principal is Martin Odersky, one of the developers of Pizza, gcj and 
>> early work on generifying Java. (But I don't think he deserves blame 
>> for the oddball form of parametric polymorphism we now have in Java.)
>
> Java generics probably aren't genuinely useful enough to justify the 
> extra complication to the language AFAICS.

Huh? Well it's surely a bit(?) lame as it exists now, as it was added
too late, etc. But really, the thing here that can't have any
technically valid justification is that the Java Language didn't
supported type parameters from the very beginning. You see, it's a
strongly typed language, that's furthermore designed for writing
robust stuff and clean API-s, so... just what the heck were they
thinking when they left it out, I don't now. I'm certain it was some
kind of non-technical decision, like running out of time, or some
corporate heads was afraid that chimpanzees couldn't use the language
then...

> Being able to say List<String>, say, instead of just List is a bit
> useful, and it's there, so I use it, but I think the ability to do
> something like that could have been hacked in pretty easily, maybe
> via something like annotations or something. I mean, then you have
> the convenience that you can say.
>
> myString = list.get(n);
>
> instead of
>
> myString = (String) list.get(n);
>
> and AFAICS, that's about all anybody gets out of all of that generics 
> generality. A little bit of notational convenience, syntactic sugar.

All programming languages can be seen as just notational convenience
and syntactic sugar over assembly... and that's exactly their point.

> That's it. I mean, how many people write their own genericized 
> containers?

I think basically everybody who writes Java 5 code daily had already
written a few such classes. If you write "utility" classes, i.e.,
classes that are not really application specific, then it has a good
chance that you will want that at a few places. (If you want to see a
pervert amount of such classes, look into the Scala API.)

> There's hardly ever that much call for it and it's just too
> complicated anyway, it seems to me.
[snip]

It's a relatively simple variation of this kind of stuff, I mean, of
class parameters, or whatever we call this. Now really, just how
simple a full-weight programming language should be? In my humble
opinion, someone who can't even learn a moderately complex programming
language is, well, not too clever, and thus should not write any
programs. Other then hello world, I mean. So I don't think adding
generics was an overkill... I actually still find the language too
weak. Like, dear Sun, please torture me with something usable instead
of this dull public/default/protected/private +
non-hierarchical-packages thing. I rather want my head to blow up due
to the overly sophisticated visibility rules and version management
and whatnot than suffer with this. Or isn't this stuff for Enterprise
scale development? You know, dear Sun, things with more 10 classes, if
you have already seen something like that... :->

-- 
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.