Don't Look Back!



  • So, don't look back. Stop envying .NET developers. With Java 8, we will not need LINQ or any API that tries to imitate LINQ on the grounds of "unified querying", which is a better sounding name for what is really the "query target impedance mismatch". We need true SQL for relational database querying, and we need the Java 8 Streams API for functional transformations of in-memory collections. That's it. Go Java 8!



  • Why is this in General and not WTF?

    I'd make fun of the article, but the guy who writes the very first comment does a pretty good job:

    Haha. I love this.

    So, you're claiming that LINQ is badly designed because of the method names?

    And you're also claiming that java 8 (which is still unreleased to this day) will make developers "stop envying" .Net because of this useless LINQ COPYCAT they implemented, which only covers Linq-To-Objects, by the way, and is nowhere near the beauty and simplicity of having a SINGLE API to query EVERTHING?

    see LINQ-to-Objects LINQ-to-Entities LINQ-to-XML etc....

    and you're recommending java developers that Hibernate is equivalent to LINQ-to-Entities and the like, and effectively stating that now developers should learn, code and maintain using 2 different APIs depending on the data source (DataBase versus in-Memory collections).

    I'm sorry, I can't help thinking all of this is completely ridiculous.



  •  It is not completely ridiculous.



  • @Nagesh said:

    It is not completely ridiculous.
    +1 Very effective rebuttal of the counter-arguements. Excellent display of rhetorical skill. Would read again.

     



  •  Thank You! It is always nice to get a fan.

    @HardwareGeek said:

    @Nagesh said:

    It is not completely ridiculous.
    +1 Very effective rebuttal of the counter-arguements. Excellent display of rhetorical skill. Would read again.

     

     



  • @Nagesh said:

    Thank You! It is always nice to get a fan.
     



  • @Nagesh said:

    Filed under: java8 is the future now.
    Yes, in the future, Java 8 will be now; but for now, it remains in the future.



  • @HardwareGeek said:

    @Nagesh said:

    Filed under: java8 is the future now.
    Yes, in the future, Java 8 will be now; but for now, it remains in the future.


    But will it be The Future Soon?



  • Why the fuck would you link to the Wiki page of a song instead of THE ACTUAL SONG!? Grr.


  • Considered Harmful

    @Ben L. said:

    @HardwareGeek said:

    @Nagesh said:

    Filed under: java8 is the future now.
    Yes, in the future, Java 8 will be now; but for now, it remains in the future.


    But will it be The Future Soon?

    When will then be now?



  • @blakeyrat said:

    Why the fuck would you link to the Wiki page of a song instead of THE ACTUAL SONG!? Grr.

    Why the fuck would you link to the YouTube video of a song instead of THE ACTUAL SONG‽ Grr.



  • @Nagesh said:

    So, don't look back. Stop envying .NET developers. With Java 8, we will not need LINQ or any API that tries to imitate LINQ on the grounds of "unified querying", which is a better sounding name for what is really the "query target impedance mismatch". We need true SQL for relational database querying, and we need the Java 8 Streams API for functional transformations of in-memory collections. That's it. Go Java 8!

     

     

    My favourite thing about Java is how almost every single thing in the base class library is done so shoddily somebody else has come along and built something better. JODA Dates, Apache Collections, and who knows what else all do the same thing as the BCL but they do it better. 

     

    My favourite part is that they decided to call a Enumerator a stream for no good reason. so now there will be java.util.Stream representing "Streams of elements" (what the hell? That's an Enumerator or a Generator, call it that) as well as java.io.Stream.. oh, let's not forget java.nio.channels.Channel, which does pretty much the same thing as java.io.Stream (but not java.util.Stream, that's different) but it does it within the "new I/O" API...

     

    On the bright side, after two tries they might have made their DateTime handling less dumb. java.util.Date to java.util.Calendar and now Instant, DateTimeFormatter,LocalDate,TemporalAdjuster, YearMonth, MonthDay, and Year classes... There is in fact an entire Temporal package, which I find hilarious. And naturally, there is a ChronoField enumeration which implements the TemporalField interface, as well as a ChronoUnit enum that implements the TemporalUnit interface. but that is so obvious, it's like a hallmark of any date handling API,and not at all a ridiculous, short-sighted overengineering of something as they've done with every attempt to redo the API so far. It's a good thing they made the TemporalUnit and TemporalField interfaces. After all we might need an implementation that isn't chronologic..?

     

    the javax.script package looks useful for scripting java programs with javascript.... Though I've gotten the same ability in C# by just compiling .cs files to assemblies and using reflection to instantiate classes that implement API interfaces.

     

    Java 8 Streams, which are just Enumerators/Generators with a stupid name I've never heard used for the concept, appear useful.

     

    I don't think Java 8 will have "Stream methods", though. You'd have to build a new Stream-implementing-class instance and return that, which isn't really worth the overhead, so most of them will end up returning a full collection and converting that into a Stream and using that for whatever querying was in place. Maybe Java will have Generators... Streamers... or whatever they end up calling them, in Java 9 in another 10 years. In the meantime, I'llgo ahead and use the C# Compiler as a Service and utilize new metaprogramming techniques that are available with Roslyn.

     


     



  • @Nagesh said:

    Thank You! It is always nice to get a fan.
    In that case, enjoy:




  • @Ben L. said:

    @blakeyrat said:
    Why the fuck would you link to the Wiki page of a song instead of THE ACTUAL SONG!? Grr.

    Why the fuck would you link to the YouTube video of a song instead of THE ACTUAL SONG‽ Grr.

    I feel mildly guilty that I like his opening band more than him. At least for live shows.


Log in to reply