Time to open up a can of worms: LINQ
Casper Bang
checked exceptions debates, whether to add closures, fixing generics,
how to add binding (properties and events) etc., other languages have
this in place and are moving forward towards new grounds. One of those
being (time to find your cross, bible and holy water), C# and LINQ.
I am baffled at how little Java developers seems to know (or care)
about the productivity gains of other languages. It used to be like
this for Ruby/Rails too (consult the earlier podcasts), before JRuby
and Grails made it to the VM.
In short (skip this paragraph if you've sniffed out the enemy before),
LINQ enables type safe querying as a first-class construct from any
colletion (IEnumerable<T>) which not only means common data types but
also databases, XML files, class reflections etc. It means no more
language within a language (SQL and JPA queries) where the syntax and
semantics is lost within strings tokens. It also means there's no need
for tools to generate various beans and no need to rely on runtime
dependency injection to test something out. The turnaround cycle is
just awesome, take a look at an example:
http://weblogs.asp.net/scottgu/archive/2007/06/29/linq-to-sql-part-3-querying-our-database.aspx
Is ANYONE interested in such functionality in Java? I hope so, perhaps
that is why the debate about the core Java language is peaked these
days. In any event, LINQ like functionality would require reified
generics (which I guess is possible, Gafter describes an aproach at
http://gafter.blogspot.com/2006/11/reified-generics-for-java.html) as
well as a type inferencing mechanism (which I guess is possible, Scale
uses this as well).
Will we ever get such groundbreaking productivity features for Java or
are there too many obstacles in the way, what's your take?
/Casper
PS: So that I will not be know as the always Java critical guy, let me
just declare my love for Java Enum's. They are crisp and flexible and
are always sure to make my development days more joyfull.™
darren...@fortybeans.com
kind of thing before is SAP's proprietary language ABAP, which has
embedded SQL as a 1st class feature.
- Darren
Christian Catchpole
have to abandon everything about the Java world. The APIs, IDEs, the
"knowledge" and the way of doing things. I think cross-over languages
and JVM implemented languages will help. You can mix and match and
the new languages can take advantage of all the optimization of
features of the modern JVM. Perhaps Java people can as assimilated
rather than converted.
Alexey Zinger
I wholeheartedly second that. Given the current choices of bytecode-producing
and JVM-based dynamic languages, I don't get the way some people get upset over
Java-the-language and want to change it rather than look for suitable
combinations of languages that can happy interoperate. I've had BeanShell (a
dynamic loosely typed Java superset) scripts running in .NET with the help of
IKVM and talking to both my C# and Java API for crying outloud. Yes, I've
written .NET code -- sue me :)
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121
Christian Catchpole
> Yes, I've
> written .NET code -- sue me :)
You may be a better patent position then to sue others. :)
Forgive my typos on the last post. It was early in the morning...
Here are some more typos...
It has been mentioned that the Java bytecode spec may not be the best
way to implement a cross platform binary (eg. use a logic tree etc),
but that aside, the JVM has had years of research and effort pored
into it.
The only downside I see is that it has no true "arbitary pointer to
method" (virtual method) ability. Virtual methods must be implemented
as "first-class" class, sub-classing or implementing an interface.
For example, say you want to emulate an instruction set, calling
methods indexed by an 8 bit code (sure you can use a jump table - but
lets ignore that for now because it has limited use) - the only way it
to do that is to create 256 classes, set instances into an array and
do
Instruction i = instructions[index];
instuction.call().
Maybe this isnt a problem, but I see it as the only limiting factor
for use with other languages, if they require such trickyness.
Curt Cox
evolving the language. Where this strategy falls short is in the
dearth of well supported languages for the JVM. There are a great
many JVM languages that are poorly supported and don't interoperate
well with Java. In total, they are less useful than a few well
supported ones.
This might be changing. It looks like Sun is supporting Javascript,
JRuby, and JavaFX. It looked like VB would be on that list a year
ago. If Java developers could easily write part of an application in
C# and part of it in Java, there would be a much larger pool of
developers able to make an informed decision about language features.
Consider the following:
"TIOBE Programming Community Index for June 2007"
http://www.tiobe.com/tpci.htm
There are well supported ways of running 4 of the top 10 on the JVM.
The Java community would grow substantially if more were supported.
Reinier Zwitserloot
In that it both looks like cartoon swearing and it has a stack of
language features that almost no C# programmer actually knows.
Pop quiz:
What does this code do?
Object a = someObject();
Object b = someOtherObject();
Object c = yetAnotherObject();
return a ?? b ?? c;
Ask any C# programmer you know. Most of them won't be able to tell
you, yet it's perfectly valid C# code.
Scroll down for the answer.
.
.
.
.
.
.
.
.
It returns the first object in the chain which isn't null. It's
functionally equivalent to:
public static <T> T findFirstNonNull(T... args) {
if ( args == null ) return null;
for ( T arg : args ) if ( arg != null ) return arg;
return null;
}
except for one interesting difference: ?? lazy evaluates, whereas the
above java method wouldn't.
I don't know about you, but Collections.findFirstNonNull(a, b, c);
sounds a lot better than a ?? b ?? c to me.
This is an excellent example - ?? is cartoon swearing, and no one
knows what it does.
Effect: If you see someone else's C# code, you don't know what's going
on. Saying "I am proficient in C#" no longer means you can read other
C# code. This is the way of PL/I - a language that is OO, functional,
dynamic, static, logical, and every other paradigm in the book. Those
languages don't work, they produce little code islands because only
the best of the experts know all those features.
Java's approach to this (Hey, there's a JVM, lets make interop easy
and let people write languages for it) is much better, except that
there's a dearth of domain specific JVM based languages out there
right now. The current focus seems to be on porting complete languages
to the JVM; JRuby, beanshell, groovy, etc. I'd much rather see stuff
for a specific domain get ported.
- Some sort of SQL-like language (java's LINQ, effectively).
- Haskell, in that writing pure algorithms in it is soooo much easier,
but try to do I/O or related material and haskell doesn't far so well
- Direct XML manipulation, perhaps. $deity knows, SAX/DOM are just...
stupid, I can't find a better word for it.
and whatever else strikes your fancy.
On Jun 30, 4:59 pm, Casper Bang <c...@brunata.dk> wrote:
> While the Java community is deeply entangled in checked vs. non-
> checked exceptions debates, whether to add closures, fixing generics,
> how to add binding (properties and events) etc., other languages have
> this in place and are moving forward towards new grounds. One of those
> being (time to find your cross, bible and holy water), C# and LINQ.
>
> I am baffled at how little Java developers seems to know (or care)
> about the productivity gains of other languages. It used to be like
> this for Ruby/Rails too (consult the earlier podcasts), before JRuby
> and Grails made it to the VM.
>
> In short (skip this paragraph if you've sniffed out the enemy before),
> LINQ enables type safe querying as a first-class construct from any
> colletion (IEnumerable<T>) which not only means common data types but
> also databases, XML files, class reflections etc. It means no more
> language within a language (SQL and JPA queries) where the syntax and
> semantics is lost within strings tokens. It also means there's no need
> for tools to generate various beans and no need to rely on runtime
> dependency injection to test something out. The turnaround cycle is
> just awesome, take a look at an example:http://weblogs.asp.net/scottgu/archive/2007/06/29/linq-to-sql-part-3-...
>
> Is ANYONE interested in such functionality in Java? I hope so, perhaps
> that is why the debate about the core Java language is peaked these
> days. In any event, LINQ like functionality would require reified
> generics (which I guess is possible, Gafter describes an aproach athttp://gafter.blogspot.com/2006/11/reified-generics-for-java.html) as
Casper Bang
point. You do not need to come out and attack C# and pull in loaded
terms like "cartoon swearing" because it is all to easy to come up
with counter attacks on Java. I don't even know where to begin,
sufficient to say the Java Puzzlers and Effective Java are both very
good starting points. Rather than trolling, this post was meant to
draw up some perspective on whether it could be done and what it would
take.
If your argument revolves around multiparadigm confusion, then I beg
to differ. The time has long passed where we throw a language into one
designated paradigm camp with high walls and barbwire around them. As
long as we are not talking AOP (which I agree, easily becomes one mans
personal programming language) it is good to have the means to express
intension declaratively, rather than in a meticulously detailed
fashion write how it should be done.. line by line, missing only
10...20....30.. labels of legacy Basic code. IOC is a good example of
something that is seeping in all over, yet doesn't exactly belong in
the realm of imperative programming either. You prefer going back to
EJB 2 and writing 7 classes for each entity? You'd be the first.
Your post eludes the fact of whether you have actually taken a look at
LINQ or is just shooting back per reflex, but surely you agree that we
haven't really achieved much since SQL became the way to query
relational data, that a language-within-a-language is hardly ideal and
that fundamentally the relational vs. object issue is still unsolved -
but that LINQ takes a pretty good shot at it.
/Casper
sherod
I was very impressed with it, although, as always, I wondered how it
dealt with large quantities of data.
Finally ?? looks useful to me
http://msdn2.microsoft.com/en-us/library/ms173224(VS.80).aspx
You other remarks about Java ring true to me. I feel the Java
community is still arguing over the color, brand and length of the
nails we should use whilst other languages are off building
skyscrapers.
Rick
now. However there are a small minority of people who suggest that
the primary building material should be ivory.
...Except that none of them can agree on what kind of beasties should
be killed to obtain that ivory...
> > > > are always sure to make my development days more joyfull.™- Hide quoted text -
>
> - Show quoted text -
Rick
I just want to qualify the above. I think that debate on Java is a
good and healthy thing. I even like a minute subset of the features
added to Java since 1.2 (annotations).
Reinier Zwitserloot
> You've given a similar answer before but I think you are missing the
> point. You do not need to come out and attack C# and pull in loaded
> terms like "cartoon swearing" because it is all to easy to come up
> with counter attacks on Java.
In the exceptions debate, I came out swinging in favour of changing
the language. I -really- like CICE. Half the runtime is badly designed
so I really want to see a way to run multiple instances of a class in
one JVM so that you can actually make backward-incompatible changes
while still being able to run old code seamlessly, and so many other
things. So, yes, there are tons of problems with java. That wasn't the
point of my post.
LINQ, and the entire idea behind it (loading up the 'main' language of
a common runtime with cruft, however useful it may be), is not the
way. I already mentioned the way forward: Domain Specific languages
that run on the JVM (read: compile to class files). I think it's
unfair to say that a post is simply an attack on an idea with loaded
terms, when I offer solutions to the very issue that the thing I'm
"attacking" is solving.
>
> If your argument revolves around multiparadigm confusion, then I beg
> to differ. The time has long passed where we throw a language into one
> designated paradigm camp with high walls and barbwire around them.
There's a big difference between soft enabling of other paradigms and
going towards a paradigm in a 'big way' like LINQ is doing (There are
a bajillion LANGUAGE LEVEL changes to C# all under the header of LINQ,
which is what I'm taking exception with). Closures is basically
'functionalifying' java which I'm tentatively in favour of (though I -
really- like CICE in that it embraces the java way of doing that much
better than the other 2 proposals). Soft enabling is excellent - don't
get in the way of the programmer too much, by all means. Completely
integrating a programming style into the language is bad, in that you
can't make a language that's good at everything, period.
>
> Your post eludes the fact of whether you have actually taken a look at
> LINQ or is just shooting back per reflex, but surely you agree that we
> haven't really achieved much since SQL became the way to query
> relational data, that a language-within-a-language is hardly ideal and
> that fundamentally the relational vs. object issue is still unsolved -
> but that LINQ takes a pretty good shot at it.
I've taken a look at LINQ and I know what it does. The problem is
simply that it's short-term thinking. This stuff needs to be channeled
into extensible packages instead of just becoming part of the
language. LINQ as a library or DSL would be great. But, just
integrating it into the language because it 'seems cool' is the way to
madness; the languag would just grow and grow and grow until not one
being on this earth can honestly say they grok the language 100%.
There needs to be a way to make cool stuff easy to use as a library of
sorts - something you can 'opt out of' so to speak. DSLs running on
the JVM is the simple way to get there. Ways to extend java so that
the tooling can automatically follow would be cooler, if it is
possible at all.
That's a real issue here: The tooling (Your IDE, ant scripts, code
coverage tools, bug finders, Annotation Processing tools, things like
GWT, etcetera) need to be able to automatically 'do the right thing'.
Changing the language forces all tools to catch up and implement this
stuff.
For example, operator overloading and a way to define custom literals
(in a NON turing complete 'language' - halting must be guaranteed!)
would be excellent. You could implement pretty much all of LINQ with
just those two features, as well as tons of other ideas.
Tossing things into the language on an as-needed basis is very
shortsighted, and that's what I mean when I compare C# to perl. Perl
used a similar tactic: Anytime something is 'hot', toss it right into
the language. At some point your language hits the 'sweet spot', but
soon after that your language is loaded down with tons of unreadable
cruft no one uses anymore. We see this in the java libraries all the
time - no one likes java.util.Date. java.util.Calendar was a
humonguous mistake. Collections.sort (versus someListInstance.sort())
is a blight. Now imagine the same stuff on the language level. A
library function effectively doesn't exist as long as you aren't using
it. A language feature always brings baggage. They are a pain to keep
documented (there's no auto-complete for operators and language
features, and you can't javadoc a language feature), and all toolings
out there need to support every single last language feature in order
to be useful.
I have in fact written a db layer that sits somewhere between full
blown ORM and raw SQL - a java model of SQL. You can do stuff like:
new Select().from(SOME_TABLE).where(Equals.make(SOME_TABLE_NAME,
"foobar")).fetch(SOME_TABLE_EMAIL).limit(1);
which gives you most of SQL's flexibility but it's db independent and
immune to sql injection. It's also much easier to build your query in
a modular fashion (e.g. a security layer can check out which tables
are being queried and add some 'wheres' to exclude restricted material
separately from the code that builds up a query) - but it's much
harder to write compared to plain SQL. Especially the clauses are
fugly and could really use either operator overloading or some sort of
compile-time reparsed literal construct. Preferably the latter.
Casper Bang
> a common runtime with cruft, however useful it may be), is not the
> way. I already mentioned the way forward: Domain Specific languages
> that run on the JVM (read: compile to class files). I think it's
> unfair to say that a post is simply an attack on an idea with loaded
> terms, when I offer solutions to the very issue that the thing I'm
> "attacking" is solving.
Fair enough, though there seem to appear much more substance behind
your second post than in your previous. :)
> There's a big difference between soft enabling of other paradigms and
> going towards a paradigm in a 'big way' like LINQ is doing (There are
> a bajillion LANGUAGE LEVEL changes to C# all under the header of LINQ,
> which is what I'm taking exception with). Closures is basically
> 'functionalifying' java which I'm tentatively in favour of (though I -
> really- like CICE in that it embraces the java way of doing that much
> better than the other 2 proposals). Soft enabling is excellent - don't
> get in the way of the programmer too much, by all means. Completely
> integrating a programming style into the language is bad, in that you
> can't make a language that's good at everything, period.
Obviously not, but you *can* make a language better (read: more
productive/less verbose). Few would argue that a unified query
mechanism extending collections is a bad thing, after all, what
program does not hold a collection of some kind. So what I hear you
say is you'd rather see this done through the libraries. It's an old
debate, of which Guido van Rossum (Python) and Anders Hejlsberg (C#)
simply disagrees. I might be inclined to agree with you, but Java's
syntax isn't flexible enough to allow for everything to be done though
a library. I can't tell you how many times I have cursed at
BigDecimal.add (which should really be called plus) and missing simple
operator overloading (another thing C# has but Java is missing).
> I've taken a look at LINQ and I know what it does. The problem is
> simply that it's short-term thinking. This stuff needs to be channeled
> into extensible packages instead of just becoming part of the
> language. LINQ as a library or DSL would be great. But, just
> integrating it into the language because it 'seems cool' is the way to
> madness; the languag would just grow and grow and grow until not one
> being on this earth can honestly say they grok the language 100%.
> There needs to be a way to make cool stuff easy to use as a library of
> sorts - something you can 'opt out of' so to speak. DSLs running on
> the JVM is the simple way to get there. Ways to extend java so that
> the tooling can automatically follow would be cooler, if it is
> possible at all.
I saw LINQ showcased first time at the PDC 2001, though it was then
known as Object Spaces - so donno how short-termed I would call it.
Java extensions tend to be purely additive, to the point where I would
claim few knows 100% of the language and standard API - 16.000 classes
last time I counted. When something is added to the language, it's
usually only done if it doesn't clash with existing tokens (the reason
foreach is implemented with a colon) with the exception of Enum that
finally arrived with Java 5. It made code so much more type safe,
readable and expressive. Were you against this language intrusion as
well?
> That's a real issue here: The tooling (Your IDE, ant scripts, code
> coverage tools, bug finders, Annotation Processing tools, things like
> GWT, etcetera) need to be able to automatically 'do the right thing'.
> Changing the language forces all tools to catch up and implement this
> stuff.
It's funny, the first 6-7 years I wrote Java code tools were pretty
much non-existing. You had a few terminals open and perhaps a powerful
text editor, but that was it - until Visual Studio 97 and JBuilder
came along. Today we all enjoy IDE's and debuggers, but I think the
work Tor is doing with Ruby proves you can tame a highly dynamic and
expressive syntax.
> For example, operator overloading and a way to define custom literals
> (in a NON turing complete 'language' - halting must be guaranteed!)
> would be excellent. You could implement pretty much all of LINQ with
> just those two features, as well as tons of other ideas.
> Tossing things into the language on an as-needed basis is very
> shortsighted, and that's what I mean when I compare C# to perl. Perl
> used a similar tactic: Anytime something is 'hot', toss it right into
> the language. At some point your language hits the 'sweet spot', but
> soon after that your language is loaded down with tons of unreadable
> cruft no one uses anymore. We see this in the java libraries all the
> time - no one likes java.util.Date. java.util.Calendar was a
> humonguous mistake. Collections.sort (versus someListInstance.sort())
> is a blight. Now imagine the same stuff on the language level. A
> library function effectively doesn't exist as long as you aren't using
> it. A language feature always brings baggage. They are a pain to keep
> documented (there's no auto-complete for operators and language
> features, and you can't javadoc a language feature), and all toolings
> out there need to support every single last language feature in order
> to be useful.
>
> I have in fact written a db layer that sits somewhere between full
> blown ORM and raw SQL - a java model of SQL. You can do stuff like:
>
> new Select().from(SOME_TABLE).where(Equals.make(SOME_TABLE_NAME,
> "foobar")).fetch(SOME_TABLE_EMAIL).limit(1);
Well there you are missing one of the useful things about LINQ and
what makes it vastly superior to JPA annotations (apart from type
safety). You start out be declaring the "universe of discourse" you
are projecting from, which enables you to get code completion in a
tool:
FROM Consumer SELECT <POPUP with Consumer attributtes>
In any event, thanks for the feedback. I knew I would meet some tough
counter arguments.
/Casper
Reinier Zwitserloot
> productive/less verbose).
Absolutely. However, even here there is a caveat - each improvement
step needs to be grokked by the entire userbase. Tooling may need to
be updated, code needs to be refactored, people need to acquaint
themselves with the new feature. I'm with Guido on this one -
preferably there is only one way to do it. Basic premise to take from
this: I'm of the opinion that established programming languages
shouldn't evolve too quickly. C# is arguably going a bit fast. Java
was definitely going too slow, though since (and including) the 1.5
release, the speed is pretty good. Not too fast, probably not too
slow.
> Few would argue that a unified query
> mechanism extending collections is a bad thing, after all, what
> program does not hold a collection of some kind.
Plenty. The idea here to me is completely obvious: Anything which is
going to be used pretty much by all software projects can be a
language feature. Things which a significant number of apps will never
need should definitely not be.
The real question is: Where does one draw the line?
Database-like operations on collections? I argue this falls far short
of the requirement. Not really something every project will need.
GUI stuff, like Swing? I doubt there's any argument here. This is
rightly so entirely a library thing, as it is in most languages.
map and list literals? Yes, I'd love to see direct language support
for those (something java currently lacks).
closures? Tentatively, yes. There's also the issue where this is
practically impossible in a library format.
> I might be inclined to agree with you, but Java's
> syntax isn't flexible enough to allow for everything to be done though
> a library. I can't tell you how many times I have cursed at
> BigDecimal.add (which should really be called plus) and missing simple
> operator overloading (another thing C# has but Java is missing).
Ah, this is related yet entirely different. I wish java WAS powerful
enough to make it easy to do things as a library which are currently
being considered only as a language feature. However, java has more or
less stumbled accidentally onto something very very important:
tooling.
In eclipse's default keyboard layout, CMD/CTRL+clicking on anything in
a java source file, be it a variable of some sort or a type
identifier, takes you directly to the declaration of that thing. This
is phenomenally useful and utterly impossible in dynamic languages. It
just can't be done, the halting problem being what it is. This is but
one example of a great many things which java is exceptional at.
Refactoring is another one of those things that just works better in a
very explicit, static language. That's the java way. We can discuss
whether this is worth losing most of the advantages of Dynamic Meta
Programming (this is javascript/python/ruby's forté... things like
redefining methods on system libraries, something you just can't do in
java normally) - but going for DMP instead of static explicitness now
is just marrying the bad properties of python/ruby/javascript with the
bad properties of java, a losing proposition. I'm not accusing anyone
of advocating this, it's just to set the stage for the tooling
argument: It is extremely important that changes stick with the
tooling.
This, for example, completely precludes adding duck typing to java. It
doesn't mesh with things our tools currently do - it blows up things
like auto complete and static code coverage analyses.
It does NOT stand in the way of introducing operator overloading,
though. Something that either needs to be added, or, if not,
BigDecimal and BigInteger need to be available for use with all the
usual operators, at the very least.
> foreach is implemented with a colon) with the exception of Enum that
> finally arrived with Java 5. It made code so much more type safe,
> readable and expressive. Were you against this language intrusion as
> well?
Every single addition in java5 was excellent, especially generics,
something lots of C# haters tend to dislike in my experience. There
are some mistakes though, particularly the brainfart regarding varargs
and generics. By implementing varargs as an array instead of a
collection, You cannot use generics of any form in varargs, or the
callers get warnings. But I digress.
additive updates is not a problem with libraries. You can deprecate
those things. You can stop shipping them and download them on demand
instead. Hopefully in the future you can update them in such a way
that you can keep backwards compatibility yet change the way they work
for new code somehow.
>
> It's funny, the first 6-7 years I wrote Java code tools were pretty
> much non-existing. You had a few terminals open and perhaps a powerful
> text editor, but that was it - until Visual Studio 97 and JBuilder
> came along. Today we all enjoy IDE's and debuggers, but I think the
> work Tor is doing with Ruby proves you can tame a highly dynamic and
> expressive syntax.
To an extent. There are things java toolings do that are completely
impossible in DMP based languages, but I covered this already.
>
> Well there you are missing one of the useful things about LINQ and
> what makes it vastly superior to JPA annotations (apart from type
> safety). You start out be declaring the "universe of discourse" you
> are projecting from, which enables you to get code completion in a
> tool:
I know, and that's great. I want Java (or any other language, really.
I'd switch in a heartbeat if it existed) to have language features so
I can program a LIBRARY that allows you to write something like 'from
consumer select ' and then get a popup with consumer attributes. It
can be done, it's not even that hard.
I think what needs to happen is - there needs to be a strict subset of
java. This version is not turing complete (e.g. no while, no long for,
just the foreach version) and has only very limited elements of the
standard libraries. It doesn't even need to be java, really. Couple
this to a standardised AST model and a few other such things, and you
have a 'script language' for the tooling.
Neil Bartlett
It's obviously not possible in the Java language, but it should be
possible in Scala.
LINQ basically boils down to monads, which are very familiar to
Haskell programmers. In fact LINQ was directly inspired by the
HaskellDB library. The designer of LINQ, Erik Meijer, is an long-time
Haskell geek who crossed over to the Dark Side (the pay is better!)
Since version 2.5, Scala has supported higher-kinded types, which
means you can write real monads, so a clone of LINQ should be
perfectly possible. Okay so this isn't exactly "LINQ for Java" but it
is at least "LINQ for JVM" and interoperable with Java code.
Neil
On Jun 30, 3:59 pm, Casper Bang <c...@brunata.dk> wrote:
> While the Java community is deeply entangled in checked vs. non-
> checked exceptions debates, whether to add closures, fixing generics,
> how to add binding (properties and events) etc., other languages have
> this in place and are moving forward towards new grounds. One of those
> being (time to find your cross, bible and holy water), C# and LINQ.
>
> I am baffled at how little Java developers seems to know (or care)
> about the productivity gains of other languages. It used to be like
> this for Ruby/Rails too (consult the earlier podcasts), before JRuby
> and Grails made it to the VM.
>
> In short (skip this paragraph if you've sniffed out the enemy before),
> LINQ enables type safe querying as a first-class construct from any
> colletion (IEnumerable<T>) which not only means common data types but
> also databases, XML files, class reflections etc. It means no more
> language within a language (SQL and JPA queries) where the syntax and
> semantics is lost within strings tokens. It also means there's no need
> for tools to generate various beans and no need to rely on runtime
> dependency injection to test something out. The turnaround cycle is
> just awesome, take a look at an example:http://weblogs.asp.net/scottgu/archive/2007/06/29/linq-to-sql-part-3-...
>
> Is ANYONE interested in such functionality in Java? I hope so, perhaps
> that is why the debate about the core Java language is peaked these
> days. In any event, LINQ like functionality would require reified
> generics (which I guess is possible, Gafter describes an aproach athttp://gafter.blogspot.com/2006/11/reified-generics-for-java.html) as
Woolery
convinced that it is a groundbreaking improvement. It definitely has
my interest and I will try it on real projects when it hits RTM, but
IMO, .NET's major advantages over Java aren't from specific
technologies such as LINQ, but in general:
- Simpler technology stack. To build a web app in .NET, you just need
ASP.NET. You can buy one book that provides all you need. With Java,
you need to learn many different frameworks and libraries (such as
Struts, Tiles, JSP, and Servlets, and of course there are hundreds
other other combinations)
- Tighter Integration. In .NET land, the web framework, IDE, web
server, and OS are extremely well integrated compared to Java where
there are many different frameworks, IDEs, servers, and OS's that take
more effort to work together
Steve Lewis
Will we ever get such groundbreaking productivity features for Java or
are there too many obstacles in the way, what's your take?
LINQ is just Microsoft's answer to the ORM problem and some in the OS .NET community has been grousing lately about LINQ because Microsoft has missed some *critical* features in order to do something grander. Yeah it's grand but (it is claimed by some of the .NET crowd) it doesn't *work* yet.
I think you have a good argument, to a point, but the grass really isn't that green over here when you actually have to mow it.
--
SteveL (professionally in exile in a .NET shop)
BoD
if (x == null) {
return "";
} else {
return x;
}
or
return x == null ? "" : x;
or
return x ?? "";
(ps: how do you guys like my new sig ;)
--
BoD
"It is time to break the compatibility! We want a new Java!"
>> are always sure to make my development days more joyfull.(tm)
>>
>
>
> >
>
Alexey Zinger
> cruft no one uses anymore. We see this in the java libraries all the
> time - no one likes java.util.Date. java.util.Calendar was a
> humonguous mistake. Collections.sort (versus someListInstance.sort())
I keep hearing people talk about how the don't like java.util.Date or
java.util.Calendar, but I have yet to hear a substantial reason. I see nothing
wrong with Calendar personally.
As far as Collections.sort(List), I don't see what's so terrible about that
either. Seems to me most people are arguing over the look of the language, not
what's practically possible to do with the API.
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
____________________________________________________________________________________
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
Reinier Zwitserloot
>
> I keep hearing people talk about how the don't like java.util.Date or
> java.util.Calendar, but I have yet to hear a substantial reason. I see nothing
> wrong with Calendar personally.
Seriously?
you must be joking.
Have a look at jodatime (which will enter java7 as part of the
library, finally), and contrast to the idiocy of Calendar, and you
have your answer. Some highlights:
- Neither Date nor Calendar are immutable. This is extremely
annoying.
- doing 'math' on Calendar involves using a set method and a (non-
enummed) 'constant' to identify what kind of time you want to change.
This is just bluh. I want a Time Interval and a single math operation
(add, subtract).
- months start at 0, days start at 1, and years start at 1900.
Eeeeearrgh!
I'd add more but frankly I haven't even touched Calendar for the last
5 years. I've mostly forgotten the horrors of it and I don't want to
ruin that by reacquainting myself.
>
> As far as Collections.sort(List), I don't see what's so terrible about that
> either. Seems to me most people are arguing over the look of the language, not
> what's practically possible to do with the API.
The operation isn't terribly, it's supposed to go:
list.sort(sorter)
instead of:
Collections.sort(list, sorter).
A way to add default implementations to interfaces, or even just
adding static methods to interfaces, would have been better.
List.sort(list, sorter) is nicer than Collections (as sorting anything
but lists/arrays doesn't make any sense), and list.sort(sorter) would
be even better.
Christian Catchpole
contructs like extension and overloading. Now the consesus seems to
be it has its place, but dumb data carrying beans, more interfaces and
and composition can be better than single objects which try to do
everything... (There is a point to this). I dont think sort() should
be on a collection interface. All collections then must then be
sortable and implement the code. What if it's mapping to a DB or
something read only? I think the Java Collections interfaces are too
bloated. When I implemement List and Map, I have to implemement all
this crud which isn't nessisary (like putAll(Map m) ). The worst
offender is Map.entrySet which returns a set of Map.Entry - open hash
maps dont use this but you have to return them. Even Trove says "its
a pain, but we have to implement this".
My point to all this (if I have one), is that if all the interfaces
were a bit cleaner, it would make integration with the lanuage easier
and cleaner. Let look at what methods are "integrated" today.
- toString() in String concats. "Value = " + object
- Iterable in the new for( : ) loop.
Cant think of anything else at the moment...
Something they could have done...
- object1 === object2 (using equals()) hey, both = and == are
taken :)
As for Date and Calendar I think the argument is, they are awkward to
set and change, Date objects must be created out of a Calendar and
then cant be changed (they deprecated a bunch of methods). And they
dont deal with time durations. I just want something which implements
the anchient Queensland Beach Fishing Rod Sun Dial and seasonal
tracking system (a big pile of beer cans).
Reinier Zwitserloot
> everything... (There is a point to this). I dont think sort() should
> be on a collection interface.
You're confusing language flow with responsibility.
There is not a glimmer of doubt about it, the 'language flow' dictates
that the most aesthetically pleasing way to sort a list is:
list.sort(whatever parameters are needed to complete the sort. Like,
say, a Comparator, or for naturally ordered elements, nothing).
Collections.sort(list, parameters) is fugly.
However, at the same time, the code for 'sort' should be centralized.
This is exactly what superclasses are for - the superclass contains
the implementation, and all you need to do, is extend the class, and
you get the sort 'for free'. Unfortunately extending is 'heavy weight'
and you can only extend one thing. Bad.
> All collections then must then be
> sortable and implement the code. What if it's mapping to a DB or
> something read only?
Collections.sort() can be called on unmodifiables - you just get an
error. This is no different from a sort() method on lists.
Obviously, if all lists need to implement their own sort, that would
be really bad, but that's not neccessary. Behold: all the advantages
of multiple inheritance with none of the disadvantages:
1. allow static methods to be declared on interfaces. static methods
fall outside of the scope of class hierarchy anyway - the reason they
exist inside class definitions at all is SOLELY as a namespacing
issue. An interface is a namespace, same as anything else (in fact,
it's perfectly legal to toss enums and static classes inside an
interface), so why static METHODS aren't allowed, is a mistake that
needs to be rectified.
2. allow some sort of annotation or keyword
('hasDefaultImplementation') on interface declarations that basically
say: If an implementing type doesn't explicitly provide this method
somehow, either by itself or because any of its superCLASSES (not
interfaces) has an implementation, use the static implementation. The
static implementation has the same method name, the same exception
throwing, etc, etc, except that it has 1 more parameter - the first
parameter is the same as the interface.
3. If ever there's a clash (2 different interfaces both with the same
method name and both with a default), it's a compile time error unless
the implementing class offers an implementation itself. This can, of
course, just pick one of the two by using the static method normally.
To show how this would work, here's what happens to sort:
A. transplant Collections.sort, verbatim (copy/paste it) into the
java.util.List interface. It's a static method, so no problems there.
B. add the following declaration to the List interface:
public abstract @HasDefaultImplementation void sort();
public abstract @HasDefaultImplementation void sort(Comparator
comparator);
(for the full signatures with the appropriate generics, see the source
of collections - it's the same).
and that's it. From now on you can call .sort() directly on any list.
You can use this mechanism for mixin behaviour as well, quite easily.
> I think the Java Collections interfaces are too
> bloated. When I implemement List and Map, I have to implemement all
> this crud which isn't nessisary (like putAll(Map m) ).
Absolutely, which is why you should not be implementing those, but
instead be extending AbstractMap and AbstractList. Of course, you
can't do that if you're already subclassing something else. In those
situations you really want a mixin - which is exactly what the feature
I just described adds.
> - object1 === object2 (using equals()) hey, both = and == are
> taken :)
Another unfixable pet peeve. I -really- want an operator that is
equivalent to:
(a == null ? b == null : a.equals(b)). in case a and b are objects,
and
(a == b) in case a and b are primitives.
(in case one is primitive and the other isn't, autobox the primitive).
In other words, the null-safe .equals(). The best candidate for this
is to take the current == and make that === (in that all other
languages that use == for comparison use === for 'identity
comparison'), and take the now freed == for this null-safe equals
comparison thing.
Unfortunately, THAT is totally not backwards compatible. Stuffing this
new null-safe equals under === would be, but that's extremely
confusing, as then in java == would be indentity-compare, and ===
would be content-compare (which at least in theory is reversed in at
least javascript).
I don't really know of a good solution. The tilde is free but in some
languages, ~= is not equal (like !=), so that's also a really bad
match. =? is potentially usable but is a bit cartoon-swearing to me.
>
> As for Date and Calendar I think the argument is, they are awkward to
> set and change, Date objects must be created out of a Calendar and
> then cant be changed (they deprecated a bunch of methods). And they
> dont deal with time durations. I just want something which implements
> the anchient Queensland Beach Fishing Rod Sun Dial and seasonal
> tracking system (a big pile of beer cans).
Can't you just create your own subclass of Calendar for that? :-P
Christian Catchpole
interfaces which simply define methods, not static methods for default
implementations. (Would that open a can of worms, staticifying things
which would normally be non-static).
I also dont think "it looks nice" should dictate implementation. That
is to say, I would accept some of these niceties if the langauge had a
serious overhall or was a different language all together. Some of
these things could look nice on the surface but cause problems down
the track. I'd prefer a little bit ugly than nice but dodgy.
Im also not a fan of method which might not work - like stream
marking. I think it's better (in a stronly typed langauge) to use
interface extension. For example Collections could have base
interfaces which only have get methods, then an extension with set
methods. Most implementations will use the full interface, but those
with no set ability wont work at compile time. I guess there are
problems with that too.. Code might be written which only reads but
uses the full interface. But where should a language accomodate bad
programming. I think its a balance. programmers say "make it easy" -
the language designers say "make it right".
Eric Winter
think it would be a great language to have on the JVM. Perhaps the
problem is that it is too similar to Java but instead of changing the
Java language why not just add one that many think is superior.
Although it is great to have the "agile" dynamic languages on the JVM
it would be very nice to have another strong static contender as
well. I, for one, prefer a static language (maybe because I'm a fuddy
duddy) with the good tool support that it entails.
E
Casper Bang
cleaned up branch of Java where we *can* break binary code
compatibility. After all, a plethora of lessons have been learned
since Java's inception - and as with all software product the law of
entropy starts to sets in. The two branches would have to run in
parallel for a while but eventually "old Java" would enter a strictly
legacy/maintenance mode.
A radical step like this worked pretty well for Microsoft (VB6
to .NET), where Microsoft arguably took the best parts of Java but
fixed the broken parts. A new Java could do the same. However, I doubt
Sun has the tenacity or resources to pull that off, it would probably
have to come from a very strong and liberal front - The Eclipse
foundation comes first to mind, or perhaps a dream scenario of Sun/
Google/Oracle merging.
/Casper
Alexey Zinger
>
>
> >
> > I keep hearing people talk about how the don't like java.util.Date or
> > java.util.Calendar, but I have yet to hear a substantial reason. I see
> nothing
> > wrong with Calendar personally.
>
> Seriously?
Seriously :)
> you must be joking.
Nope.
> Have a look at jodatime (which will enter java7 as part of the
> library, finally), and contrast to the idiocy of Calendar, and you
> have your answer. Some highlights:
Looks great, no doubt about it.
> - Neither Date nor Calendar are immutable. This is extremely
> annoying.
Date mutators are all deprecated. If they don't break now, you'll certainly
see compiler warnings pointing you in the direction of where you're using them.
If you're concerned about some third party library mutating your Date objects
(highly unlikely), simply use an immutable Date wrapper. Calendar is not
supposed to be immutable. It's supposed to be a utility that allows one to
perform calendar-specific computations spitting out Date objects at the end.
When Calendar was introduced, Date was meant to be used as an immutable date
and time reference type.
> - doing 'math' on Calendar involves using a set method and a (non-
> enummed) 'constant' to identify what kind of time you want to change.
> This is just bluh. I want a Time Interval and a single math operation
> (add, subtract).
> - months start at 0, days start at 1, and years start at 1900.
> Eeeeearrgh!
>
> I'd add more but frankly I haven't even touched Calendar for the last
> 5 years. I've mostly forgotten the horrors of it and I don't want to
> ruin that by reacquainting myself.
Those are annoying, but they're problems with GregorianCalendar, not Calendar.
Use getMinimum(Calendar.MONTH) and you won't miss or subclass GregorianCalendar
so months start with 1.
>
> >
> > As far as Collections.sort(List), I don't see what's so terrible about that
> > either. Seems to me most people are arguing over the look of the language,
> not
> > what's practically possible to do with the API.
>
> The operation isn't terribly, it's supposed to go:
>
> list.sort(sorter)
>
> instead of:
>
> Collections.sort(list, sorter).
>
> A way to add default implementations to interfaces, or even just
> adding static methods to interfaces, would have been better.
> List.sort(list, sorter) is nicer than Collections (as sorting anything
> but lists/arrays doesn't make any sense), and list.sort(sorter) would
> be even better.
The only way to assign a non-static implementation of sort to list classes
would be through multiple class inheritance. Since everyone in Java has by now
hopefully agreed that we don't want that, we have to make it a static method
and have Comparator encapsulate the order logic. Yeah, it can't go into List
as a static method, but everyone knows that Collections is a utility class with
"global" methods, so I'm not sure what the big deal is really.
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
____________________________________________________________________________________
Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/