Another language feature I'd like

[Orangy_Tang]

You go down a dangerous road with that kind of thing though - you either 1) special-case LINQ (or whatever) syntax in which case you end up cluttering the language spec for one very specific feature, or 2) add enough language flexibility so that LINQ (or whatever) can be written as a third party library. With the first you risk bloating your language with constant special-case exceptions which most people don’t want, and with the second you end up with the possibility of it being redefined so much you never know what the code you’re looking at actually does (see: Lisp).

I think the only practical method would be something that defines it’s own syntax and used it’s own compiler to produce suitable bytecode (much like how Nice is java-compatible syntax with additions). But then you’d loose existing tools/ide support (which would suck!).

[princec]

Any such addition would have to have an Eclipse plugin from the off. It’d also be nice to have javac use a syntax plugin thing too. So for any bit of the parsing javac couldn’t parse it’d somehow delegate to its sub-parsers and work out what to do to compile a bit of code. That’d be a nice solution to the whole issue. Just drop in a library - but the library this time exists as a javac plugin (and of course, probably a runtime library as well)! How cool would that be? You could enable the use of a particular plugin just with a quick annotation at the method or class level.

Cas

[erikd]

@Orangy Tang

You go down a dangerous road with that kind of thing though - you either 1) special-case LINQ (or whatever) syntax in which case you end up cluttering the language spec for one very specific feature, or 2) add enough language flexibility so that LINQ (or whatever) can be written as a third party library. With the first you risk bloating your language with constant special-case exceptions which most people don’t want, and with the second you end up with the possibility of it being redefined so much you never know what the code you’re looking at actually does (see: Lisp).

I think the only practical method would be something that defines it’s own syntax and used it’s own compiler to produce suitable bytecode (much like how Nice is java-compatible syntax with additions). But then you’d loose existing tools/ide support (which would suck!).

What do you mean by “one very specific feature” and could you give an example of a “special-case exception which most people don’t want”?
I’d say querying data (from collections in this case) is such a generic use case, that including better support for it in the language makes perfect sense.

I’d be more wary of your second suggestion because to me that seems to change the nature of java in quite a drastic way.

[quote]It’d also be nice to have javac use a syntax plugin thing too.
[/quote]
OTOH, it could potentially turn the java syntax into a horrid syntax-ghetto.

[princec]

It already is a bit of a muddle to be honest what with generics and various new features coming in Java7. There’d be absolutely no harm in having optional syntax plugins for javac as it would essentially silence both camps at a stroke - those who want Java to stay like it is don’t need to use any plugins, and those who want to modify it for domain specific purposes can just use a nice cross platform jar file. And those who just want to use bytecode thus produced without being scared by the syntax are free to do so as the bytecode is still bytecode and only requires a runtime library as before. What’s not to like?

Cas

[Riven]

Most of our hassles would be solved by allowing multi-line Strings in Java sourcecode:

`
String query = "

select
a
from
b
where
c = “+localVariable+”

";
`

Then you could easily build your queries, and pass them into an API, that does the dirty stuff for you, like parsing. Sure, it would lack auto-completion and compile-time checks, but it would be useful for so many things… Creating multi-line strings with StringBuilders is so 1999.

[pjt33]

I used to write Java in a fairly functional style, but I think mixing three paradigms in one language falls into the same trap as C++: you end up with most new to intermediate programmers knowing a subset of the language, but they don’t all know the same subset and so maintenance is a PITA.

There are already multiple compilers from functional languages to bytecode - see Scala, LambdaVM, etc. I would see it as more logical to use one of these, possibly alongside pure Java for the rendering, than to bung them together into one language.

[Orangy_Tang]

@erikd

What do you mean by “one very specific feature” and could you give an example of a “special-case exception which most people don’t want”?

Well personally I don’t particularly like the idea of LINQ being embedded at a language level - it’s not something I’d use much and it introduces a lot of new syntax. I like the fact that the java syntax is clean and minimal (er, less so with 1.5). There’s a feeling of “slippery slope” where today it’s collection querying, and the next it’s built in sql (because “most people” use sql), then explicit support for financial transactions, and account balancing and it just decends into me yelling “GET THE HELL OUT OF MY LANGUAGE”. :o

I imagine that it’d get a similar reaction from the “enterprisey” developers if I suggested adding in explicit support for n-dimensional geometry. Being able to do intersections, unions and find contact points between various 2d and 3d geometric shapes would be great with custom language syntax, particularly for games. But I’d never want to force that upon everyone using a the language.

[erikd]

@princec

It already is a bit of a muddle to be honest what with generics and various new features coming in Java7. There’d be absolutely no harm in having optional syntax plugins for javac as it would essentially silence both camps at a stroke - those who want Java to stay like it is don’t need to use any plugins, and those who want to modify it for domain specific purposes can just use a nice cross platform jar file. And those who just want to use bytecode thus produced without being scared by the syntax are free to do so as the bytecode is still bytecode and only requires a runtime library as before. What’s not to like?

I like being able to easily read any java code. That’ll be out of the window.
And I like that Eclipse can handle any java code (also the code of 3rd party libs that I download so that I can simply control-click to its source to see how stuff works under the hood). That’ll be out of the window too.

Although certainly an intriguing idea, it’s not without it’s potential problems that deserve some serious consideration imho.

[quote]Well personally I don’t particularly like the idea of LINQ being embedded at a language level - it’s not something I’d use much and it introduces a lot of new syntax. I like the fact that the java syntax is clean and minimal (er, less so with 1.5). There’s a feeling of “slippery slope” where today it’s collection querying, and the next it’s built in sql (because “most people” use sql), then explicit support for financial transactions, and account balancing and it just decends into me yelling “GET THE HELL OUT OF MY LANGUAGE”.
[/quote]
Most things can be cleanly solved using libraries, but the things LINQ addresses can usually only be solved with libraries in a somewhat spotty way.
I share your stance towards language changes in general, but I think LINQ solves such common problems that it’s at least worth considering.

Most of our hassles would be solved by allowing multi-line Strings in Java sourcecode:

I think that solves a different hassle, though?

[Mr_Light]

@ewjordan

your example requires far fewer keystrokes

if we used typing writing machines I’d might care, instead I use a ide. Moreover it would take me more keystrokes to do the proposed then the ‘normal’ one.

@ewjordan

is more understandable

if you say so.

@ewjordan

and omits all the crap boilerplate

And introduces new additional crap.

@ewjordan

that makes maintaining and extending most Java code a nightmare.

errr?

@ewjordan

I don’t know if everyone really thinks the Java “solutions” aren’t that ugly or what

Here you go: they aren’t

@ewjordan

Nothing at all against that code, it’s perfectly fine as far as Java code goes, but “just like a FileFilter” is exactly the problem - there’s no way to do it better in Java, and that sucks.

There are plenty - ‘JIT’ it in other words don’t start Select until you need the next element. Select on insert in other words the original collection backs the selection etc. etc.

SQL doesn’t support all of that cause data is in your database and not at your fingertips. it’s cheaper to do it then and there always, because going over the wire is costly.

There is plenty of other stuff where it doesn’t work or would cause it to be not alike SQL hell and that is even in the world I can imagine - not even the harsh world out there filled with creative ‘abusers’.

@ewjordan

In Scala it’s worth implementing convenience functions like “select” (or in Scala’s case, filter) because I can write

myList.filter( enemy => enemy.life > 0 )

to get a list of living enemies with zero hassle.

With CICE it would be

collection.select(Where(Enemy enemy) { return enemy.life > 0 });

But wait if your saying it’s zero hassle and you favor closures and you want ‘this’ where the hell would java end up then. I don’t know but having a zillion things to solve a problem means your maintainers need to understand all these zillion ways. Have fun extending and maintaining your code now.

@ewjordan

to do the same thing in Java, the abstraction has lost pretty much 100% of its convenience value

Hmm I must have been doing this wrong all this time. I always abstracted stuff to reduce complexity or as the bootstrap said’s: “remove the unnecessary so that the necessary may speak”

Hopefully Java 7 will include proper closures and add a new chapter to this story…

See above. That problem is also why BGGA and others don’t seem to hit home you don’t need overlap and that reason is why coping stuff directly from some other language or system doesn’t usually work.

@ewjordan

I yearn for a little more control over syntax in Java…DSLs are wonderfully expressive, and I wish we could create our own without leaving the language, that would actually allow for stuff like this to be in a library. Not holding my breath, though…

You confuse me; isn’t the advantage of a DSL that it’s specific, powerful and focused wouldn’t allowing ppl to use ‘everything’ kill the advantages of a DSL? Perhaps I’m misinterpreting “without leaving the language”?

//edit wait or did you mean the ability to inline a other language ala assembly with c?

[quote=“Riven,post:45,topic:33789”]
I simply love how you silently step over that :-*

[princec]

You language Nazis never change! Which is why Java’s stuck in the mid-90s still, where it started. I’m fed up of how much boilerplate crap I have to do to get simple things done, and I’d love a way forward to add to Java that had sod all effect on anyone who didn’t care. So a plugin architecture for javac would be brilliant, because Orangytang wouldn’t have to care about maintaining Java code - because it won’t be Java code, it’ll be base Java + SQL-over-collections-plugin code, and if that becomes some sort of standard plugin, then he’ll learn it.

Cas

[Mr_Light]

Hey I wasn’t finished…

@Cas I liked that train of though esp with DSL like stuff but i’d just limit it to syntax sugar DSL <- ‘transcode’ -> Java -> Bytecode
now the issue is that the Java code might look odd as it might be generated so you would need to make the DSL java like and only do simple stuff. The idea is that normal ppl can served up the normal java code but the ppl who have the plugin installed get served up the one with sugar.

Normal ppl see:

@Sugarise(BigNumber)
void foo() {
 BigInteger propertyX = BigInteger.valueOf(10);
 BigInteger propertyY = BigInteger.valueOf(10);
 propertyX = propertyX.add(propertyY);
 propertyX = propertyX.mulply(10);
}

Plugin powered ppl would see:

@Sugarise(BigNumber)
void foo() {
 BigInteger propertyX = 10;
 BigInteger propertyY = 10;
 propertyX += propertyY;
 propertyX = propertyX * 10;
}

Was thinking about this with the whole discussion about memory-mapped-objects or ‘memory-based networking’(as opposed of IP)
The network is the computer the computer is a network :persecutioncomplex:
Where ppl where also concerned about syntax.

//edit

[quote]You language ****s never change! Which is why Java’s stuck in the mid-90s still, where it started. I’m fed up of how much boilerplate crap I have to do to get simple things done, and I’d love a way forward to add to Java that had sod all effect on anyone who didn’t care.
[/quote]
You have a problem with handling collections other had problems with keeping their libraries type-safe. Err complaining about generics and saying this isn’t that a typical case of having your cake and eat it?

//edit2
btw if you just make a plugin architecture for your ide you don’t need to change a thing about java and you can do your stuff now. That and precompilers aren’t new are they? if you wanted to do it from the commandline. Release it and make it some “sort of standard plugin, then hewe’ll learn it.”

What’s stopping you?

[Riven]

We really need the IDEs these days! Pre-processors are not supported…

The only way not to b0rk your IDE, is to put the ‘new code’ in comments…

List items = ...; List filtered = Filter.filter( /* select a from b where c = 'd' */ );

And then your post-processor does something really fancy :persecutioncomplex: using the CodeAttribute in Java bytecode.

You can’t really do this with annotations, as you lack the ‘free style typing’ that you really need in these DSLs.

Still no compile-time checks and autocompletion, though. :-X

[Martin_Strand]

@princec

I think deep down it’s the same reasons as Hibernate exists - a deep seated fear that graduate programmers have of SQL, never having properly been taught it in situ with some real world problems to solve it remains enigmatic and scary to most Java programmers. If you’ve been doing SQL for any reasonable length of time you soon come to appreciate how obvious it is for set-based logical operations like for example that big thread on entity systems recently as an alternative programming paradigm.

Not just that but it’d make the whole entity-relationship mapping thing a piece of piss and Hibernate could be slowly tortured to death, as befits it.

You seem to have a lot of opinions here based on nothing, but this statement is so ridiculous I don’t even know what to say. Do you really think the point of Hibernate is to hide SQL from noobs?

As I said before: if you really need another language, there are several alternatives available for the jvm. Have you tried any of them?

[princec]

Based on very nearly 30 years writing code.

Hibernate is an incredibly complicated and fiddly library that makes an easy task into a pretty complicated one. Largely it seems to revolve around a deep suspicion of simply writing SQL. The other thing it tries to hide is the fact that JDBC is a fiddly way of working with databases compared to say, using SQL directly in the language. Anybody here ever used Powerbuilder? We’ve just gone 2 steps backwards since Powerbuilder as far as database integration is concerned.

Haven’t yet found a viable alternative to using Java. I was thinking of a compatible way forward that would solve the issues I’ve got but without breaking anything or upsetting anyone.

Cas

[ewjordan]

@Mr_Light

Hmm I must have been doing this wrong all this time. I always abstracted stuff to reduce complexity or as the bootstrap said’s: “remove the unnecessary so that the necessary may speak”

There’s a lot else to respond to, but this cuts to the heart of the issue - I don’t think Java’s current state effectively enables the removal of the unnecessary. When I look at the pure Java examples that do what Cas wants, my eyes are attracted to everything but the “live” bits of code in there, which to me means they fail at the mission. Screen space is dominated by boilerplate that doesn’t vary from use to use, and the tiny bit of logic that does vary from filtration to filtration is all but obscured. This is true in most real life Java code that I see, in amounts usually proportional to how complex the overall system being designed is.

That’s why characters typed is a useful metric even in the face of fancy IDEs that take care of the typing for you - it’s not that you actually have to type all that stuff, it’s that you have to parse it away when you glance over the code in order to figure out what the real logic is, and as projects grow, development time is dominated by code readability.

IMO, it comes down to this: a filter/map/reduce/fold should always be a one-liner, even if the criteria is only used once, and it’s just not possible to achieve that in Java. I understand that the ability to do this type of thing means some people will abuse it, but that’s what code reviews and standards are for. Reflection can be abused quite readily, but most people would be fired long before they could manage any real damage to a codebase by using it.

Hell, half the time when people abuse reflection it’s just to do things that would be trivial if they had closures anyways…who hasn’t seen the dreaded reflection-simulated-function-pointer anti-pattern showing up here and there in live code?

@princec

Haven’t yet found a viable alternative to using Java. I was thinking of a compatible way forward that would solve the issues I’ve got but without breaking anything or upsetting anyone.

I’d definitely vote for some sort of reasonable compiler plugin system, particularly one that didn’t involve an external build step (I’m very aware of all the stuff you can do with annotations and bytecode manipulation now, and it’s all a real hassle to use). The nice thing there would be that we’d all have access to the power, but companies or teams that feared the mess that could be made if their worst programmers had access to it could just forbid the specific compiler plugins at the IT level, which is a lot easier than enforcing coding standards.

Scala has almost exactly what you’re talking about, Cas, and it’s not perfect or anything (difficult to write plugins), but it’s a lot easier to use a plugin than it is to integrate a bytecode processor into a Java build (once it’s set up once, it can be used by default whenever necessary): http://www.scala-lang.org/node/140 (…I offer that link with the full acknowledgment that the syntax in that compiler plugin highlights one of the most troublesome aspects of Scala, namely the prevalent operator abuse; luckily that is supported in most IDEs, so you can command+click on <:< to figure out wtf it does…)

Re: IDE integration, the ideal solution there would have been to give the IDE the hooks it needs into the language syntax as part of the plug-in interface. Generally speaking I’d love if languages started to treat IDE integration as a core concern of the language itself rather than a cosmetic step on top, it would very seriously increase the usability of most languages - my language design thoughts have lately centered on this issue almost above all else, as I think it’s quite the failure of most newer languages. IDE issues are the biggest problem with Scala at the moment, otherwise I’d be pushing it a hell of a lot harder than I am already!

[Mr_Light]

@Riven

…
You can’t really do this with annotations, as you lack the ‘free style typing’ that you really need in these DSLs.
…

You miss the point where it doesn’t need to be a java sourcefile. The thing the plugin shows is simply a different view of your java source ala code folding or uml round tripping the compiler is only fed legal java code. The annotation is there to help the plugin and to allow programmers to differentiate between real/plain java code and this ‘view’.

@ewjordan

When I look at the pure Java examples that do what Cas wants, my eyes are attracted to everything but the “live” bits of code in there

Cas still lives in 1.4 given an advanced for loop, somehow I can’t imaging that that particular example isn’t that bad. Hell it all depends on if you care how the select is implemented.

@ewjordan

Perhaps I used the wrong wording: if anyone makes anything there will be other ppl who can do new and exciting things with it. Or; even I can imagine plenty of situations where you’d have overlap or where it becomes awkward let alone all the combinations I can’t imagine…

[quote] (I’m very aware of all the stuff you can do with annotations and bytecode manipulation now, and it’s all a real hassle to use).

What hassle pricisely?

[ewjordan]

@Mr_Light

What hassle pricisely?

(re: bytecode post-processing)
Mainly that it’s a separate build step, which can lead to some pain if you have to deal with a whole bunch of build files inside a large project. A very minor inconvenience, to be sure, and nothing that takes more than a little effort to get through, but the process of language improvement is largely about spotting minor inconveniences and removing them. (similar to the boilerplate issue)

Further, bytecode processing is a little weak since it has to operate at fairly restricted locations during the compile cycle (pretty much either before or after the source->bytecode translation). Scala’s compiler plugin architecture is a lot more flexible, allowing plugins to punch through and insert themselves at any of the various compilation/optimization phases, and even create their own hooks for other plugins to latch on to, which provides a lot of power to the plugin writers.

[Riven]

@Mr_Light

[quote]You can’t really do this with annotations, as you lack the ‘free style typing’ that you really need in these DSLs.

You miss the point where it doesn’t need to be a java sourcefile. The thing the plugin shows is simply a different view of your java source ala code folding or uml round tripping the compiler is only fed legal java code. The annotation is there to help the plugin and to allow programmers to differentiate between real/plain java code and this ‘view’.
[/quote]
Yeah, right. Changing the view of the source, while the real files are different… Suddenly you find yourself only being able to program in a specific IDE. You can’t copy and paste code around anymore. Your sourcecode repository will choke on it. It’s simply a really poor solution, if that… it’s a whole can of worms.

[Orangy_Tang]

Related, has anyone seen the list of proposed additions in Java7? Null safe handling looks like a practical piece of syntaxtic sugar (through the awesomely named “elvis operator”), and annotations on java types looks like giving us the handy-dandy @NotNull that’s been kicking around in Nice for ages.

In fact that’s a pretty big list - does anyone know of similar ones for java5 and 6 for comparison? (and I’m wondering if I missed anything cool that got drowned out in all the generics and annotations hype).

[princec]

I did see that list - although I did also read a very compelling white paper on how the @NotNull annotation should actually be @Null, as in the vast majority of cases people do not want null values allowed. Intuititively @NotNull is what you’d go for but practically you really want @Null.

Cas