Get the default value by type

Lingerance

Y'know, you could also concatinate the ascii code for each character into one long string (with like a 6 character cutoff) and then turn those into a long, divide by a standard number to get it down to an int and then switch on that value.Of course, you would have false positives from similar strings, but that's a problem for the next developer.

... or you could jsut use the hash functions provided.

And NOT reinvent it? What MADNESS is this? THIS ISN'T SPARTA.

Someone_You_Know

@Jonathan said:

@Someone You Know said:
In Java, you can only switch on primitive types. (Strings are not primitives in Java.)
Java's switch statements assign an integer constant to each case value, so that the whole thing can be optimized into a lookup table of instruction pointers. There is no obvious way to do this for a Java Object that will both a) always work the way you want it to and b) be faster than a series of if statements, especially if the runtime type of the object is not known at compile time. Thus, switching on an Object would just be syntactic sugar, which the language designers apparently felt was not worth the effort.

Java 7 will have switching on strings.

Proposal: Strings in Switch

That's a proposal to include String switching in Java 7, not a statement that it will actually occur. There have been similar proposals for this feature pretty much every time there's been a new version of the language.

bstorer

@Someone You Know said:

@Jonathan said:
@Someone You Know said:
In Java, you can only switch on primitive types. (Strings are not primitives in Java.)
Java's switch statements assign an integer constant to each case value, so that the whole thing can be optimized into a lookup table of instruction pointers. There is no obvious way to do this for a Java Object that will both a) always work the way you want it to and b) be faster than a series of if statements, especially if the runtime type of the object is not known at compile time. Thus, switching on an Object would just be syntactic sugar, which the language designers apparently felt was not worth the effort.

Java 7 will have switching on strings.

Proposal: Strings in Switch

That's a proposal to include String switching in Java 7, not a statement that it will actually occur. There have been similar proposals for this feature pretty much every time there's been a new version of the language.

He's right, though; he just sucks at linking. Switching on String was accepted for Project Coin, which is the small language changes for Java 7.

Someone_You_Know

@bstorer said:

He's right, though; he just sucks at linking. Switching on String was accepted for Project Coin, which is the small language changes for Java 7.

I stand corrected. But take a look at this (emphasis mine):

@joe darcy said:

Instead, a switch should occur on a predictable and fast 
integer (or long) function value computed from the string.  The most 
natural choice for this function is String.hashCode, but other functions 
could also be used either alone or in conjunction with hashCode.  (The 
specification of String.hashCode is assume to be stable at this point.)  
If all the string labels have different lengths, String.length() could 
be used instead of hashCode.  Generally a String.equals() check will be 
needed to verify the candidate string's identity in addition to the 
evaluation of the screening function because multiple string inputs

could evaluate to the same result.

Since there exist multiple Strings that have different values but the same String.hashCode() value, the hashCode value alone can't be used as a switch constant. This guy proposes using String.equals() as well (presumably only if the hashCode values are equal). Is this really going to provide a significant performance increase over a series of if/else statements? If it doesn't, then this is like Java generics all over again — a feature that everyone wants, but when it's finally implemented, it's done in such a way that it's little more than syntactic sugar.

If you're going to go down that road — using a switch constant that may be the same for value-distinct switch values — why not allow switching on all Objects?

Xyro

@Someone You Know said:

If it doesn't, then this is like Java generics all over again — a feature that everyone wants, but when it's finally implemented, it's done in such a way that it's little more than syntactic sugar.

You say that like it's a bad thing. All languages are is syntacitc sugar. It's truly an unfortunate thing that Java's designers likes their coffee black. Ideally, the language should be doing the hard work for me. Why should I have to waste my time typing out chucks of ugly else-if blocks? Why should I have to declare an abstract method abstract when it's obviously abstract because it has no body? Why should I have to explicitly declare the class and method signature of a single-method interface? Come on, language, work with me!

I agree with you that core Java objects shouldn't be blessed though, String in particular. Why can't I overload my operators? And another aspect of Project Coin will be blessing their Collections Framework. Nice, but not nice enough.

Something I was thinking about earlier today, at least core old Java stuff isn't written in the modern idiomatic verbosity that is so popular. Instead of "System.out.println(object)" you'd have something like "System.getSystem().getStandardOutput().getPrinter().printLine(object)". How enterprisey.

Ah well. This is why I use Perl when I can.

bstorer

@Someone You Know said:

Since there exist multiple Strings that have different values but the same String.hashCode() value, the hashCode value alone can't be used as a switch constant. This guy proposes using String.equals() as well (presumably only if the hashCode values are equal). Is this really going to provide a significant performance increase over a series of if/else statements? If it doesn't, then this is like Java generics all over again — a feature that everyone wants, but when it's finally implemented, it's done in such a way that it's little more than syntactic sugar.

The reasoning is that the likelihood of two of the possible switch cases having the same hashCode is appreciably small, and the compiler can add additional checks in that case. For example, it'd be faster to check length or the character at a given index that they don't have in common.

But the problem with that line of reasoning is that the String to switch on is not deterministic. What if a hash collision occurs with that string and one of the cases? What if I switch on "variants" and it sends me to the case for "gelato" (an actual hash collision, by the way)? This wouldn't happen often, but can you imagine trying to track down a bug in your application caused by the fact that switching on Strings uses a heuristic?

So in essence, it becomes syntactic sugar. Is that a bad thing? No, not really. I think a switch is slightly more expressive than a series of if/else statements. Switches have the added benefit of allowing flow-down, but I'd argue that is more often bug-inducing than it is an improvement.

@Someone You Know said:

If you're going to go down that road — using a switch constant that may be the same for value-distinct switch values — why not allow switching on all Objects?

Yes, why not indeed? I look forward to that being added in Java 38. And then maybe in Java 65 they'll get ranges.

bstorer

@Xyro said:

I agree with you that core Java objects shouldn't be blessed though, String in particular. Why can't I overload my operators? And another aspect of Project Coin will be blessing their Collections Framework. Nice, but not nice enough.

This is such a common problem with Java's evolution. Every change is done after years of begging from the developers, and they always go just far enough to hush the crowd for a while. And, more often than not, they do them the wrong way.@Xyro said:

Something I was thinking about earlier today, at least core old Java stuff isn't written in the modern idiomatic verbosity that is so popular. Instead of "System.out.println(object)" you'd have something like "System.getSystem().getStandardOutput().getPrinter().printLine(object)". How enterprisey.

You're just going to let the printLine function decide what end-of-line character to use? What if I want to use a different one?!

System.getSystem().getStandardOutput().getPrinter().printLine(object, new EndOfLineSettings(EndOfLineSettings.SYSTEM_DEFAULT));

Someone_You_Know

@Xyro said:

@Someone You Know said:
If it doesn't, then this is like Java generics all over again — a feature that everyone wants, but when it's finally implemented, it's done in such a way that it's little more than syntactic sugar.
You say that like it's a bad thing. All languages are is syntacitc sugar. It's truly an unfortunate thing that Java's designers likes their coffee black. Ideally, the language should be doing the hard work for me. Why should I have to waste my time typing out chucks of ugly else-if blocks? Why should I have to declare an abstract method abstract when it's obviously abstract because it has no body? Why should I have to explicitly declare the class and method signature of a single-method interface? Come on, language, work with me!

I suppose I was using "syntactic sugar" as more of a relative term. Switch statements can be implemented in such a way that they're just more "sugary" if/else statements, or they can be implemented in such a way that they actually provide a performance benefit. Java's primitive-type switch statement does this, but the proposed method for implementing a String switch statement cannot possibly do it as well.

@Xyro said:

I agree with you that core Java objects shouldn't be blessed though, String in particular. Why can't I overload my operators? And another aspect of Project Coin will be blessing their Collections Framework. Nice, but not nice enough.

"Nice, but not nice enough" was essentially the unofficial subtitle for Java 5. This sort of thing is why people like C# better.

Someone_You_Know

@bstorer said:

But the problem with that line of reasoning is that the String to switch on is not deterministic. What if a hash collision occurs with that string and one of the cases? What if I switch on "variants" and it sends me to the case for "gelato" (an actual hash collision, by the way)? This wouldn't happen often, but can you imagine trying to track down a bug in your application caused by the fact that switching on Strings uses a heuristic?

I've got a bit of a sweet tooth. I'd much rather be taken to the case for "gelato" than "variants". Though that conclusion is based on imperfect information, since I have no idea what variants taste like; I generally don't go out for dessert with VB programmers.

@bstorer (in a different post, so don't get confused) said:

This is such a common problem with Java's evolution. Every change is done after years of begging from the developers, and they always go just far enough to hush the crowd for a while. And, more often than not, they do them the wrong way.

The issue is that the metric they use for making design decisions for the language is to choose the alternative that generates the greatest number of angry blog posts. They haven't yet come up with a reliable method for determining which angry blog posts are written by people who know what they're talking about, so a run of bad luck has produced terrible design decisions. Java 8 will include a whole API for judging the sanity of an angry blog post, but the current proposals all have it extending java.util.Random.

Xyro

@Someone You Know said:

This sort of thing is why people like C# better.

Give it a few more years. Being a NIH clone of Java, it had the benefit of learning from many of Java's mistakes, but it still suffers from the same fundamental design limitations.

For example, you still can't (easily) do (true) functional programming in C# any more than you can Java, despite both having pretty much all the necessary internal components required. A more simple example would be the designers' blind spot towards double/dynamic dispatch. (That is, for example, choosing at runtime between someMethod(A object) and someMethod(B object) where B is a subclass of A.) Or how about argument objects that represent the arguments of a call (like Javascript's apply() or Perl's Parcels) in order to create one's own dispatch system.

The designer's may not see a need for such things, but I suspect that's only because they don't understand how useful they are...

Xyro

@Someone You Know said:

The issue is that the metric they use for making design decisions for the language is to choose the alternative that generates the greatest number of angry blog posts. They haven't yet come up with a reliable method for determining which angry blog posts are written by people who know what they're talking about, so a run of bad luck has produced terrible design decisions. Java 8 will include a whole API for judging the sanity of an angry blog post, but the current proposals all have it extending java.util.Random.

Indeed, the API will be a monstrous set of interfaces and a few abstract classes for convenience, but it will take 2-3 years until a decent implementation is created by the Apache Foundation...

bstorer

@Xyro said:

@Someone You Know said:
The issue is that the metric they use for making design decisions for the language is to choose the alternative that generates the greatest number of angry blog posts. They haven't yet come up with a reliable method for determining which angry blog posts are written by people who know what they're talking about, so a run of bad luck has produced terrible design decisions. Java 8 will include a whole API for judging the sanity of an angry blog post, but the current proposals all have it extending java.util.Random.
Indeed, the API will be a monstrous set of interfaces and a few abstract classes for convenience, but it will take 2-3 years until a decent implementation is created by the Apache Foundation...

Sure, if you consider 30,000 lines of XML configuration to be a decent implementation.

Xyro

@bstorer said:

Sure, if you consider 30,000 lines of XML configuration to be a decent implementation.

@/etc/apache/floogergurdy/local/config/xml/config.xml said:

<post xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/angry-blog-post.xsd" version="1.0">  <configurationOptionAppenderSetting>0</configurationOptionAppenderSetting>  <configurationOutputFunctionStreamer>1</configurationOutputFunctionStreamer>  <atLeastItWillBeMultiPlatform>Y</atLeastItWillBeMultiPlatform>  </post>

morbiuswilters

@bstorer said:

@Xyro said:
@Someone You Know said:
The issue is that the metric they use for making design decisions for the language is to choose the alternative that generates the greatest number of angry blog posts. They haven't yet come up with a reliable method for determining which angry blog posts are written by people who know what they're talking about, so a run of bad luck has produced terrible design decisions. Java 8 will include a whole API for judging the sanity of an angry blog post, but the current proposals all have it extending java.util.Random.
Indeed, the API will be a monstrous set of interfaces and a few abstract classes for convenience, but it will take 2-3 years until a decent implementation is created by the Apache Foundation...
Sure, if you consider 30,000 lines of XML configuration to be a decent implementation.

Which is why the Apache Foundation is proud to announce Apache Splot: a new project that generates FloogerGurdy config files for you. Its config files only run around 25,000 lines but give you access to over 70% of the most commonly-used FloogerGurdy features.

Still not satisfied? Then you'll love Ghiz: an easy-to-use XML templating language that makes creating Splot config files fast and fun! Ghiz has bindings for all of the popular languages, including: JDK 1.4+ (Sun reference implementation), OpenJDK 7+ and Erlang!

bstorer

@morbiuswilters said:

@bstorer said:
@Xyro said:
@Someone You Know said:
The issue is that the metric they use for making design decisions for the language is to choose the alternative that generates the greatest number of angry blog posts. They haven't yet come up with a reliable method for determining which angry blog posts are written by people who know what they're talking about, so a run of bad luck has produced terrible design decisions. Java 8 will include a whole API for judging the sanity of an angry blog post, but the current proposals all have it extending java.util.Random.
Indeed, the API will be a monstrous set of interfaces and a few abstract classes for convenience, but it will take 2-3 years until a decent implementation is created by the Apache Foundation...
Sure, if you consider 30,000 lines of XML configuration to be a decent implementation.
Which is why the Apache Foundation is proud to announce Apache Splot: a new project that generates FloogerGurdy config files for you. Its config files only run around 25,000 lines but give you access to over 70% of the most commonly-used FloogerGurdy features.
Still not satisfied? Then you'll love Ghiz: an easy-to-use XML templating language that makes creating Splot config files fast and fun! Ghiz has bindings for all of the popular languages, including: JDK 1.4+ (Sun reference implementation), OpenJDK 7+ and Erlang!

Awesome! Ghiz sounds a like it does the exact same thing Apache Kapow does, only with the added benefits of being newer and requiring that I purchase a new set of O'Reilly books. I hear they went with a dung beetle for the cover!

Xyro

@morbiuswilters said:

@bstorer said:
@Xyro said:
@Someone You Know said:
The issue is that the metric they use for making design decisions for the language is to choose the alternative that generates the greatest number of angry blog posts. They haven't yet come up with a reliable method for determining which angry blog posts are written by people who know what they're talking about, so a run of bad luck has produced terrible design decisions. Java 8 will include a whole API for judging the sanity of an angry blog post, but the current proposals all have it extending java.util.Random.
Indeed, the API will be a monstrous set of interfaces and a few abstract classes for convenience, but it will take 2-3 years until a decent implementation is created by the Apache Foundation...
Sure, if you consider 30,000 lines of XML configuration to be a decent implementation.
Which is why the Apache Foundation is proud to announce Apache Splot: a new project that generates FloogerGurdy config files for you. Its config files only run around 25,000 lines but give you access to over 70% of the most commonly-used FloogerGurdy features.

Still not satisfied? Then you'll love Ghiz: an easy-to-use XML templating language that makes creating Splot config files fast and fun! Ghiz has bindings for all of the popular languages, including: JDK 1.4+ (Sun reference implementation), OpenJDK 7+ and Erlang!

And then Google will release Gravey, which is a competitor-but-we-still-like-you-guys to Apache Ghiz. It's features include an English-like API, full support for generics, and a perpetual beta status. It's actually a very good library for Splot generation, which is important because Google's upcoming Gohnny (pronounced "johnny") library will be using splotfiles for its config generation generation. The best part about Gravey? No XML! Just hundreds of lines of very readable Java that you have to hand type and recompile when you need something changed.

The Gohnny library is pretty nice, as it adds in all the fundamentals that Java designers left out in the core API, such as closures, predicates, and dynamic code generation. Unfortunately, it will not run on GWT. For that, you'll need the Gets spin-off library which contains about 80% of the features of Gohnny. Gets is perfect for the splotfile developer on the go!

Xyro

...and in a few years the users will start calling themselves "splotfile engineers" and "splotfile architects". Man, I'm in a bad mood today.

Lorne Kates

@Xyro said:

And then Google will release Gravey, which is a competitor-but-we-still-like-you-guys to Apache Ghiz. It's features include an English-like API, full support for generics, and a perpetual beta status. It's actually a very good library for Splot generation, which is important because Google's upcoming Gohnny
(pronounced "johnny") library will be using splotfiles for its config generation generation. The best part about Gravey? No XML! Just hundreds of lines of very readable Java that you have to hand type and recompile when you need something changed.
The Gohnny library is pretty nice, as it adds in all the fundamentals that Java designers left out in the core API, such as closures, predicates, and dynamic code generation. Unfortunately, it will not run on GWT. For that, you'll need the Gets spin-off library which contains about 80% of the features of Gohnny. Gets is perfect for the splotfile developer on the go!

I'm still waiting for my office to get a bulk license for MSGhiz 2010. It's just like Apache Ghiz, but with a GUI and fewer options.

We're still working with MSGhiz 2003. It handles GhizX controls ok, but they don't support MS's new OpenGhiz format.

bstorer

@Xyro said:

@morbiuswilters said:
@bstorer said:
@Xyro said:
@Someone You Know said:
The issue is that the metric they use for making design decisions for the language is to choose the alternative that generates the greatest number of angry blog posts. They haven't yet come up with a reliable method for determining which angry blog posts are written by people who know what they're talking about, so a run of bad luck has produced terrible design decisions. Java 8 will include a whole API for judging the sanity of an angry blog post, but the current proposals all have it extending java.util.Random.
Indeed, the API will be a monstrous set of interfaces and a few abstract classes for convenience, but it will take 2-3 years until a decent implementation is created by the Apache Foundation...
Sure, if you consider 30,000 lines of XML configuration to be a decent implementation.
Which is why the Apache Foundation is proud to announce Apache Splot: a new project that generates FloogerGurdy config files for you. Its config files only run around 25,000 lines but give you access to over 70% of the most commonly-used FloogerGurdy features.

Still not satisfied? Then you'll love Ghiz: an easy-to-use XML templating language that makes creating Splot config files fast and fun! Ghiz has bindings for all of the popular languages, including: JDK 1.4+ (Sun reference implementation), OpenJDK 7+ and Erlang!
And then Google will release Gravey, which is a competitor-but-we-still-like-you-guys to Apache Ghiz. It's features include an English-like API, full support for generics, and a perpetual beta status. It's actually a very good library for Splot generation, which is important because Google's upcoming Gohnny (pronounced "johnny") library will be using splotfiles for its config generation generation. The best part about Gravey? No XML! Just hundreds of lines of very readable Java that you have to hand type and recompile when you need something changed.
The Gohnny library is pretty nice, as it adds in all the fundamentals that Java designers left out in the core API, such as closures, predicates, and dynamic code generation. Unfortunately, it will not run on GWT. For that, you'll need the Gets spin-off library which contains about 80% of the features of Gohnny. Gets is perfect for the splotfile developer on the go!

Yeah, and now Sun has released JSR62187: JGGCI (Java™ Gets GSCI (Gravey SFGCI (Splot FloogerGurdy Configuration Interface) Configuration Interface) Configuration Interface) Configuration Interface Generation API Specification. It outlines a new way to configure Gets code using simple annotations that will be available in Java 11. In the meantime, they've written a library that is compatible with JDK 1.4 or newer to fill the gap. And the best news is that there's a plugin for Eclipse to design JGSCICG visually. It only requires 800GB of RAM, and takes just over two years to open.

ender

@Lorne Kates said:

We're still working with MSGhiz 2003. It handles GhizX controls ok, but they don't support MS's new OpenGhiz format.

Is it that hard to install the converter? It may lose an attribute here or there, but most people won't notice anyway.

Xyro

@Lorne Kates said:

I'm still waiting for my office to get a bulk license for MSGhiz 2010. It's just like Apache Ghiz, but with a GUI and fewer options.
We're still working with MSGhiz 2003. It handles GhizX controls ok, but they don't support MS's new OpenGhiz format.

Psh, don't be such an M$ drone. Free your mind and download YAGP (Yet Another Ghiz Processor) from the SourceForge page. It's totally Free, it works with most of the OpenGhiz spec, and it usually compiles. It uses an out-of-date libpiss .18, but you can find that on the 'net, too. YAGP also features a great command line interface, but if GUIs are your thing, I think it has an X/Motif GUI. I dunno, I never use it. Just a simple yagp -p 12 -d -c ~/.yagp/config.xml -xvf infile.splot > outfile.xml and there you go!

Lorne Kates

@ender said:

@Lorne Kates said:
We're still working with MSGhiz 2003. It handles GhizX controls ok, but they don't support MS's new OpenGhiz format.
Is it that hard to install the converter? It may lose an attribute here or there, but most people won't notice anyway.

Oh no no, you're thinking of OO.oGhiz (OGhiz is Not Ghiz), the open source version of Ghiz. I'm talking about Microsoft's closed-sourced version of OO.oGhiz-- OpenGhiz.

@Xyro said:

@Someone You Know said:
This sort of thing is why people like C# better.
Give it a few more years. Being a NIH clone of Java, it had the benefit of learning from many of Java's mistakes, but it still suffers from the same fundamental design limitations.

That's retarded. Because C# (which, by the way, can only implement what's in the .NET CLR spec, which the C# team doesn't own) doesn't implement a very specific kind of double dispatch, it's a "NIH clone of Java?"

It's got a whole dynamic runtime now FFS. It literally has dynamic dispatch and type coercion. Either you know nothing about C# or you know nothing about Java, or both.

blakeyrat

Well, that broke the mood.

dhromed

@bstorer said:

System.getSystem().getStandardOutput().getPrinter().printLine(object, new EndOfLineSettings(EndOfLineSettings.SYSTEM_DEFAULT));

Sir, it's not hyperbole wit if it's actually more terse than common .Net code.

morbiuswilters

@bstorer said:

@Xyro said:
@morbiuswilters said:
@bstorer said:
@Xyro said:
@Someone You Know said:
The issue is that the metric they use for making design decisions for the language is to choose the alternative that generates the greatest number of angry blog posts. They haven't yet come up with a reliable method for determining which angry blog posts are written by people who know what they're talking about, so a run of bad luck has produced terrible design decisions. Java 8 will include a whole API for judging the sanity of an angry blog post, but the current proposals all have it extending java.util.Random.
Indeed, the API will be a monstrous set of interfaces and a few abstract classes for convenience, but it will take 2-3 years until a decent implementation is created by the Apache Foundation...
Sure, if you consider 30,000 lines of XML configuration to be a decent implementation.
Which is why the Apache Foundation is proud to announce Apache Splot: a new project that generates FloogerGurdy config files for you. Its config files only run around 25,000 lines but give you access to over 70% of the most commonly-used FloogerGurdy features.

Still not satisfied? Then you'll love Ghiz: an easy-to-use XML templating language that makes creating Splot config files fast and fun! Ghiz has bindings for all of the popular languages, including: JDK 1.4+ (Sun reference implementation), OpenJDK 7+ and Erlang!
And then Google will release Gravey, which is a competitor-but-we-still-like-you-guys to Apache Ghiz. It's features include an English-like API, full support for generics, and a perpetual beta status. It's actually a very good library for Splot generation, which is important because Google's upcoming Gohnny (pronounced "johnny") library will be using splotfiles for its config generation generation. The best part about Gravey? No XML! Just hundreds of lines of very readable Java that you have to hand type and recompile when you need something changed.
The Gohnny library is pretty nice, as it adds in all the fundamentals that Java designers left out in the core API, such as closures, predicates, and dynamic code generation. Unfortunately, it will not run on GWT. For that, you'll need the Gets spin-off library which contains about 80% of the features of Gohnny. Gets is perfect for the splotfile developer on the go!
Yeah, and now Sun has released JSR62187: JGGCI (Java™ Gets GSCI (Gravey SFGCI (Splot FloogerGurdy Configuration Interface) Configuration Interface) Configuration Interface) Configuration Interface Generation API Specification. It outlines a new way to configure Gets code using simple annotations that will be available in Java 11. In the meantime, they've written a library that is compatible with JDK 1.4 or newer to fill the gap. And the best news is that there's a plugin for Eclipse to design JGSCICG visually. It only requires 800GB of RAM, and takes just over two years to open.

Sun is making exciting advances in the real of Virtual Programming, which I'm beta testing right now. Donning a standard virtual reality helmet and motion-tracking clothing, you can enter a VR world where you can create entire enterprise applications without writing a single line of Java or XML. Instead, you interact with virtual objects which are virtualized representations of business logic components. The components take the form of paper-thin cards about the size of an iPod. By carefully stacking the components end-on-end, you can build complete enterprise applications without writing a single line of Java or XML! It's so easy, even the CEO could write every single application your company will ever need, letting him fire all of you worthless, non-value-added, keyboard-jockey drones!

For example, I'm currently writing a form that lets salaried employees request Paid Time Off. By simply stacking ten thousand of these cards on-end to construct a large pyramid, I have created an enterprise application that collects 5 pieces of information from the user via a web form, then submits that data to HR in an email which will be read and transferred to an Excel spreadsheet by a data entry clerk. All without writing a single line of Java or XML! (Excluding the XML configuration files for the virtual reality helmet, of course).

Best of all, to make the transition easier for experienced Java developers the simulation places you in a familiar surroundings! Namely, on the deck of a rocking boat caught in a tropical storm and hurricane-force winds where you cheerfully stack business logic components end-on-end as Somali pirates hold an AK-47 to your wife's head and periodically whip you. This technology is going to revolutionize enterprise application development, all without making you write a single line of Java or XML! It should hit the market in 3 to 5 years, when the first draft of the specification finishes printing. The functionality is being packaged as an Eclipse plug-in that should see release sometime in 2020, when it is expected 128-bit CPUs will be widespread, permitting Eclipse to address all of the needed memory.

bstorer

@Lorne Kates said:

@Xyro said:
And then Google will release Gravey, which is a competitor-but-we-still-like-you-guys to Apache Ghiz. It's features include an English-like API, full support for generics, and a perpetual beta status. It's actually a very good library for Splot generation, which is important because Google's upcoming Gohnny
(pronounced "johnny") library will be using splotfiles for its config generation generation. The best part about Gravey? No XML! Just hundreds of lines of very readable Java that you have to hand type and recompile when you need something changed.
The Gohnny library is pretty nice, as it adds in all the fundamentals that Java designers left out in the core API, such as closures, predicates, and dynamic code generation. Unfortunately, it will not run on GWT. For that, you'll need the Gets spin-off library which contains about 80% of the features of Gohnny. Gets is perfect for the splotfile developer on the go!

I'm still waiting for my office to get a bulk license for MSGhiz 2010. It's just like Apache Ghiz, but with a GUI and fewer options.
We're still working with MSGhiz 2003. It handles GhizX controls ok, but they don't support MS's new OpenGhiz format.

Bah, MSGhiz sucks. It only works with SQL Server and IIS out of the box. You're better off going with NGhiz. Sure, MSGhiz 2010 will be great when it finally comes up, but it won't work in Mono, you'll need a new version of .NET, and it requires EF 27, the lead developer of which hasn't even been conceived yet. Just stick to NGhiz until MS finally gets LINQ-to-Splot out the door.

bstorer

@morbiuswilters said:

@bstorer said:
@Xyro said:
@morbiuswilters said:
@bstorer said:
@Xyro said:
@Someone You Know said:
The issue is that the metric they use for making design decisions for the language is to choose the alternative that generates the greatest number of angry blog posts. They haven't yet come up with a reliable method for determining which angry blog posts are written by people who know what they're talking about, so a run of bad luck has produced terrible design decisions. Java 8 will include a whole API for judging the sanity of an angry blog post, but the current proposals all have it extending java.util.Random.
Indeed, the API will be a monstrous set of interfaces and a few abstract classes for convenience, but it will take 2-3 years until a decent implementation is created by the Apache Foundation...
Sure, if you consider 30,000 lines of XML configuration to be a decent implementation.
Which is why the Apache Foundation is proud to announce Apache Splot: a new project that generates FloogerGurdy config files for you. Its config files only run around 25,000 lines but give you access to over 70% of the most commonly-used FloogerGurdy features.

Still not satisfied? Then you'll love Ghiz: an easy-to-use XML templating language that makes creating Splot config files fast and fun! Ghiz has bindings for all of the popular languages, including: JDK 1.4+ (Sun reference implementation), OpenJDK 7+ and Erlang!
And then Google will release Gravey, which is a competitor-but-we-still-like-you-guys to Apache Ghiz. It's features include an English-like API, full support for generics, and a perpetual beta status. It's actually a very good library for Splot generation, which is important because Google's upcoming Gohnny (pronounced "johnny") library will be using splotfiles for its config generation generation. The best part about Gravey? No XML! Just hundreds of lines of very readable Java that you have to hand type and recompile when you need something changed.
The Gohnny library is pretty nice, as it adds in all the fundamentals that Java designers left out in the core API, such as closures, predicates, and dynamic code generation. Unfortunately, it will not run on GWT. For that, you'll need the Gets spin-off library which contains about 80% of the features of Gohnny. Gets is perfect for the splotfile developer on the go!
Yeah, and now Sun has released JSR62187: JGGCI (Java™ Gets GSCI (Gravey SFGCI (Splot FloogerGurdy Configuration Interface) Configuration Interface) Configuration Interface) Configuration Interface Generation API Specification. It outlines a new way to configure Gets code using simple annotations that will be available in Java 11. In the meantime, they've written a library that is compatible with JDK 1.4 or newer to fill the gap. And the best news is that there's a plugin for Eclipse to design JGSCICG visually. It only requires 800GB of RAM, and takes just over two years to open.
Sun is making exciting advances in the real of Virtual Programming, which I'm beta testing right now. Donning a standard virtual reality helmet and motion-tracking clothing, you can enter a VR world where you can create entire enterprise applications without writing a single line of Java or XML. Instead, you interact with virtual objects which are virtualized representations of business logic components. The components take the form of paper-thin cards about the size of an iPod. By carefully stacking the components end-on-end, you can build complete enterprise applications without writing a single line of Java or XML! It's so easy, even the CEO could write every single application your company will ever need, letting him fire all of you worthless, non-value-added, keyboard-jockey drones!

For example, I'm currently writing a form that lets salaried employees request Paid Time Off. By simply stacking ten thousand of these cards on-end to construct a large pyramid, I have created an enterprise application that collects 5 pieces of information from the user via a web form, then submits that data to HR in an email which will be read and transferred to an Excel spreadsheet by a data entry clerk. All without writing a single line of Java or XML! (Excluding the XML configuration files for the virtual reality helmet, of course).
Best of all, to make the transition easier for experienced Java developers the simulation places you in a familiar surroundings! Namely, on the deck of a rocking boat caught in a tropical storm and hurricane-force winds where you cheerfully stack business logic components end-on-end as Somali pirates hold an AK-47 to your wife's head and periodically whip you. This technology is going to revolutionize enterprise application development, all without making you write a single line of Java or XML! It should hit the market in 3 to 5 years, when the first draft of the specification finishes printing. The functionality is being packaged as an Eclipse plug-in that should see release sometime in 2020, when it is expected 128-bit CPUs will be widespread, permitting Eclipse to address all of the needed memory.

Oh, you're in the beta, too? Have you seen the latest build? It finally implements most of the card-stacking rules. For example, blue cards cannot be stacked onto the long edge of a red card, because that would be a bad practice. Cards can be placed at practically any angle which is divisable by 90, but they plan to improve that to 45 in a later version! Some of the cards are considered primitive, which means you can manipulate them directly with your hands; all other cards can only be manipulated using a pair of tongs, which is kinda confusing at first, but eventually you'll lose the will to care. There are drawbacks to those primitive cards, though, such as the fact that you can't stack them with non-primitive cards. You have to box them first, which literally means constructing a box out of cards and putting the primitive card inside.

Also, instead of using the VR system's built-in rendering, they've made it cross platform, which means it will work on any virtual system. In the interest of having a consistent viewing experience, they've designed to the lowest system, which is the Nintendo Virutal Boy. The simplicity of coding on a display of red line art is refreshing. Sure, there's some difficulty recognizing the colors of the non-red cards, but color is easy to determine by right-clicking (just make a fist with your right hand, and punch yourself in the dick) on each card to bring up its properties window. Then you just choose Card Properties -> Physical -> Optical -> Show All and it'll give you the color in either CMYK or CIE XYZ format. Don't you love how they give you options instead of just forcing you to use one specific color model?

In fact, most of the biggest improvements are about flexibility. For example, now you get to specify the angle of each corner of each card you use. Be careful to make sure they add up to exactly 360.0f, though, or your display device may blind you with a dazzling flare of white light. Also, negative angles may result in dazzling white light. Or angles greater than 180 degrees. Or non-numeric input. Those sorts of things are the exception, though, and you really shouldn't do anything so silly as attempt to create a card without first donning a pair of sunglasses. Anyway, in order to create each card, you use the DefaultSystemCardFactory, which is literally a virtual paper mill you have to work in to turn a virtual tree into a card. If you don't want to work in a paper mill, there are a variety of other factories available, such as dog food factory or bloody anus factory, where you are virtually raped in the ass. That last one is by far the most popular with Java developers.

Lorne Kates

@bstorer said:

Some of the cards are considered primitive, which means you can manipulate them directly with your hands; all other cards can only be manipulated using a pair of tongs, which is kinda confusing at first, but eventually you'll lose the will to care.

Why don't you just take the hash-code of the non-primative card, and then you can manipulate the hash-code with your hands? Sure, there's the occasional hash-collision, which I think results in your virtual intestines being pulled out of your real genitals, but that can be caught with an exception.

I'm just dissapointed at the growing complexity of the card-stacking system. Some of us on the beta-tester forums are planning a way to abstract the interface, so you can virtually-virtually handle the virtual programming.

Xyro

@bstorer said:

Cards can be placed at practically any angle which is divisable by 90, but they plan to improve that to 45 in a later version!

Ugh, Microsoft's ActiveVirtualVirtualX cards can only be divisible by 30, making them incompatible with the future OpenCards system.
@Lorne Kates said:

Some of us on the beta-tester forums are planning a way to abstract the interface, so you can virtually-virtually handle the virtual programming.

If it becomes popular enough, then Oracle will release virtual JSR8.8931e5 which imposes a mostly compatible set of virtual API interfaces with a half-baked virtual reference implementation which then gets improved by Apache and then Google and it all starts anew...

It's the circle of life...

The circle of madness...

Someone_You_Know

I've created a monster.

wrack

@Someone You Know said:

I've created a monster.

You should be proud.

Lorne Kates

@Someone You Know said:

I've created a monster.

I've created a monster with Ghiz. I have "Crush" working, but I can't implement "Maim" or "Kill". plz send the codes!

bstorer

@Someone You Know said:

I've created a monster.

In your defense, Sun started it.

amischiefr

@bstorer said:

@Xyro said:
...it will take 2-3 years until a decent implementation is created by Spring ~~the Apache Foundation~~...
Sure, if you consider 30,000 lines of XML configuration to be a decent implementation.

FTFY

I don't know why the folks at Spring love XML configuration files so much.

Xyro

@bstorer said:

@Someone You Know said:
I've created a monster.
In your defense, Sun started it.

You fools! Don't you see?? THE MONSTER LIVES INSIDE US ALL!!

dhromed

@Xyro said:

You fools! Don't you see?? THE MONSTER LIVES INSIDE US ALL!!

So... is that HAS-A or IS-A?

Someone_You_Know

@dhromed said:

@Xyro said:
You fools! Don't you see?? THE MONSTER LIVES INSIDE US ALL!!

So... is that HAS-A or IS-A?

Okay, never mind. I don't want to marry you anymore anyway.

>: (

morbiuswilters

@dhromed said:

@Xyro said:
You fools! Don't you see?? THE MONSTER LIVES INSIDE US ALL!!

So... is that HAS-A or IS-A?

If we could rate comments, I would give this one 5 huge, throbbing dicks.

morbiuswilters

@amischiefr said:

@bstorer said:
@Xyro said:
...it will take 2-3 years until a decent implementation is created by Spring ~~the Apache Foundation~~...
Sure, if you consider 30,000 lines of XML configuration to be a decent implementation.

FTFY
I don't know why the folks at Spring love XML configuration files so much.

It's not just Spring; Tomcat is the same way. Actually, every Java server app is.

Xyro

@dhromed said:

So... is that HAS-A or IS-A?

HAS-A, but life uses a dynamic language that can expose certain public attributes in an IS-A manner. Specifically, it binds HAS-A attributes and functions that can be directly callable as if inherited from an IS-A parent.

For example, in life's dynamic language version 1.5:

attribute evil: IS-A collection<verbs>; //.. predicates removed for brevity attribute good: IS-A collection<verbs>; //.. predicates removed for brevity attribute name: IS-A string; class human: IS-A animal; HAS-A name, good, evil { constructor = function(name) { // automatically sets member name evil.add(new monster()); log("Hello, I am ${name}"); } get:evil = function() { log("Warning: bad things are about to happen."); return evil; } } class monster: IS-A evil { program_in_xml =function() { log("Programming in XML because I'm a monster."); } } var develop_software_with(developer IS-A human) =function()
{ if (developer HAS-A evil AND developer.program_in_xml) { // language will automatically determine that a human // developer has this function available. developer.program_in_xml(); } else { log("${developer.name} likes writing good code."); } } var johndoe = new human("John Doe"); develop_software_with(johndoe); // The log will output the following: // Hello, I am John Doe // Warning: bad things are about to happen. // Programming in XML because I'm a monster.

Here, the human object does not directly declare or inherit the program_in_xml function, but it gains this function from having evil. It's a pretty sweet language.

dhromed

@morbiuswilters said:

If we could rate comments, I would give this one 5 huge, throbbing dicks.

Is that good or bad?

bstorer

@dhromed said:

@morbiuswilters said:
If we could rate comments, I would give this one 5 huge, throbbing dicks.

Is that good or bad?

That depends. Are they throbbing with rage or lust?

Xyro

@bstorer said:

@dhromed said:
@morbiuswilters said:
If we could rate comments, I would give this one 5 huge, throbbing dicks.
Is that good or bad?
That depends. Are they throbbing with rage or lust?

Probably blood.

bstorer

@Xyro said:

@bstorer said:
@dhromed said:
@morbiuswilters said:
If we could rate comments, I would give this one 5 huge, throbbing dicks.
Is that good or bad?
That depends. Are they throbbing with rage or lust?
Probably blood.

Okay, bloodrage or bloodlust?

dhromed

@bstorer said:

Okay, bloodrage or bloodlust?

I suspect dicks with +10 aggro.

That is a frightening visual indeed.

PJH

@dhromed said:

@bstorer said:
Okay, bloodrage or bloodlust?

I suspect dicks with +10 aggro.

Jonathan

@JohnWestMinor said:

Y'know, you could also concatinate the ascii code for each character into one long string (with like a 6 character cutoff) and then turn those into a long, divide by a standard number to get it down to an int and then switch on that value.Of course, you would have false positives from similar strings, but that's a problem for the next developer.

In the given case after checking for a null value or empty string, you can switch on the first character of the string since they are unique.

You still have the problem of false positives but the solution is to use the original calls to String.equals() for each case in the switch. This is how it will be implemented behind the scene when switching on strings.

So the given case could be coded like below. A better solution would be to use enumerations.

public Object getDefaultValue(String strType) {
  if(strType==null || strType.equals(""))
   return null;

  switch(strType.charAt(0)) {

  case 'S':

  if(strType.equals("STRING"))
   return "";

  break;

  case 'I':

  if(strType.equals("INTEGER"))
   return new Integer(0);

  break;

  case 'F':

  if(strType.equals("FLOATING"))
   return new Float(0.0f);

  break;

  case 'D':

  case 'T':

  if(strType.equals("DATE") || strType.equals("TIMESTAMP"))
   return new java.util.Date();

  break;

  case 'B':

  if(strType.equals("BOOLEAN"))
   return new Boolean(true);

  break;

  case 'G':

  if(strType.equals("GUID"))
   return "";

  break;

  case 'O':

  if(strType.equals("OBJECT"))
   return new Object();

  break;

  }

  return null;
 }

Jonathan

@Someone You Know said:

@joe darcy said:
Instead, a switch should occur on a predictable and fast 
integer (or long) function value computed from the string.  The most 
natural choice for this function is String.hashCode, but other functions 
could also be used either alone or in conjunction with hashCode.  (The 
specification of String.hashCode is assume to be stable at this point.)  
If all the string labels have different lengths, String.length() could 
be used instead of hashCode.  Generally a String.equals() check will be 
needed to verify the candidate string's identity in addition to the 
evaluation of the screening function because multiple string inputs 
could evaluate to the same result.
Since there exist multiple Strings that have different values but the same String.hashCode() value, the hashCode value alone can't be used as a switch constant. This guy proposes using String.equals() as well (presumably only if the hashCode values are equal). Is this really going to provide a significant performance increase over a series of if/else statements? If it doesn't, then this is like Java generics all over again — a feature that everyone wants, but when it's finally implemented, it's done in such a way that it's little more than syntactic sugar.
If you're going to go down that road — using a switch constant that may be the same for value-distinct switch values — why not allow switching on all Objects?

The only way to check what value a string has is to check each character in the string, and String.equals() is the most efficient way to do that. There is no getting around the fact that efficient switching on strings requires calling String.equals(). Putting those calls as the second stage inside a switch statement adds efficiency by reducing the number of calls to String.equals() down to one or only a few.

The reason switching on strings was added and not switching on other classes is because the string class is immutable and String.equals() is known to have no side effects.