The Artima Developer Community
Sponsored Link

Weblogs Forum
Java 7: Too Little, Too Late?

64 replies on 5 pages. Most recent reply: Jan 30, 2012 10:07 AM by Steve Carmeli

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 64 replies on 5 pages [ « | 1 2 3 4 5 | » ]
S. Ochsenreither

Posts: 2
Nickname: 74073
Registered: Nov, 2010

Re: Java 7: Too Little, Too Late? Posted: Aug 12, 2011 1:01 AM
Reply to this message Reply
Advertisement
Sorry for that. I posted assuming that my name would appear instead of the number. I fixed my profile now.

I intend to keep writing about Scala related topics I'm interested in.

See also the first post on the blog ... I'm not really a "Scala fanboy", I have a huge list of things in the language which annoy me, but I think Scala is the only chance the JVM ecosystem got to close the gap to the state of the art.

I see it very pragmatic: I don't want to write Java code until retirement, so my question is "what's necessary to prevent that?" and do what I think is the best.

Bárður Árantsson

Posts: 5
Nickname: somebody
Registered: May, 2007

Re: Java 7: Too Little, Too Late? Posted: Aug 12, 2011 9:48 AM
Reply to this message Reply
> @Bárður Árantsson
>
> whose name is also tricky to partition via a simplistic
>
>
> _.startsWith("A")

Heh. Actually, my name isn't that special aside from a few ISO-8859-1 characters. I've found that real world entities (addresses, age groups, names, etc.) are always much more complicated than people think. It's only when you're forced to work with them (the entities, that is) that you realize just how messy these things are.

>
> Could you please give some good examples of the inline
> lambdas that you have used? Thanks.

Sure, here's a few from a project I'm doing in Haskell:

(\s -> (setL cssCommandsForClient commandsChan' s, ())
(\_ -> (ClientSessionState st' commandsChan', ())
(\m -> (M.insert sessionId sessionRef m, ())
(\i -> return (Panel i, PanelState ())
(\i -> (i,v))

(That's just a small random sampling, I'm not sure how much sense they make of of context.)

The key point is that the stuff they do actually isn't very complicated, but if I were forced to name them, I'd actually have trouble coming up with sensible names that are actually shorter and/or more descriptive than the lambdas themselves. The other key thing is that the actual structures that I'm transmogrifying don't actually have any names, they're purely intermediate structures until they actually end up in a concrete (named) data type.

Bárður Árantsson

Posts: 5
Nickname: somebody
Registered: May, 2007

Re: Java 7: Too Little, Too Late? Posted: Aug 12, 2011 10:04 AM
Reply to this message Reply
Meh, "out of context" not "of of context".

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Java 7: Too Little, Too Late? Posted: Aug 12, 2011 1:30 PM
Reply to this message Reply
> Switch statements are, in general, something to avoid. (e.g. http://c2.com/cgi/wiki?SwitchStatementsSmell)

> Making switch statements easier to use just makes them more likely to be used, which is not progress. Use polymorphism instead.

OK, so I'm five days late.

I have a hard time agreeing that "switch statements are, in general, something to avoid." I *do* agree that certain uses of switch statements are, in general, something to avoid. But since I learned that early on, I don't use switch statements to fake polymorphism.

There aren't very many times I'd use a string in a switch statement, though, because odds are the string is used to denote some kind of type that could be modeled polymorphically.

Fred Finkelstein

Posts: 48
Nickname: marsilya
Registered: Jun, 2008

Re: Java 7: Too Little, Too Late? Posted: Aug 12, 2011 3:25 PM
Reply to this message Reply
Switch statements were problem in java? I think if this is your biggest problem then you are a very happy man! Java solved some of the biggest issues in programming field: Garbage collection, pointer issues, simplicity, and will always represent a major milestone in computer science history. And you talking about switch statements, excuse me, but I cannot believe it.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Java 7: Too Little, Too Late? Posted: Aug 12, 2011 6:10 PM
Reply to this message Reply
> Java
> solved some of the biggest issues in programming field:
> Garbage collection, pointer issues, simplicity, and will
> always represent a major milestone in computer science
> history.

Java didn't solve any of these problems, those solutions all existed several years before Sun's Marketing Department got behind them. It may well be that Java *popularized* garbage collection, the policy of not trusting programmers to handle pointer arithmetic because "math is hard," a standard threading model, standard types based on 32 bit architectures when 64 bit architectures were just around the corner, and OOP. But Java did not advance the state of the art in any way.

Fred Finkelstein

Posts: 48
Nickname: marsilya
Registered: Jun, 2008

Re: Java 7: Too Little, Too Late? Posted: Aug 13, 2011 8:02 AM
Reply to this message Reply
>> Java didn't solve any of these problems, those solutions
>> all existed several years before Sun's Marketing
>> Department got behind them.
>> Java didn't solve any of these problems, those solutions >> all existed several years before Sun's Marketing
>> Department got behind them. It may well be that Java
>> *popularized* garbage collection, the policy of not


true, but as you said - Sun made popularized it and made it industrial-strength and delivered it for free so that everyone could use it. That's why you are now as a programmer able to find a job where you not have to deal with pointer arithmetic and such low level stuff. Microsoft copied Java and c# was born. Now you have even more options to program in a decent programming language/environment.


>> trusting programmers to handle pointer arithmetic
>> because "math is hard," a standard threading model,
>> standard types based on 32 bit architectures when 64 bit
>> architectures were just around the corner, and OOP. But
>> Java did not advance the state of the art in any way.


When a machine can do pointer arithmetic why should I do it? It's obviously a waste of time. I don't want to waste my mind for such low-level things like that. If you want to do it, just do it. But you can also solve sudoku puzzle. That's wasting your time. Maybe you become smarter. But you just don't solve any interesting problem.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Java 7: Too Little, Too Late? Posted: Aug 13, 2011 9:36 AM
Reply to this message Reply
@Max

We are basically in agreement. Switching on Strings is indicative that you should consider polymorphism instead. At a minimum, consider using an Enum.

@Bardur

I really like your observation that good in-line closures are where you "have trouble coming up with sensible names that are actually shorter and/or more descriptive than the lambdas themselves". IMO, this would make a good chapter in some upcoming "Effective Scala" type of book.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Java 7: Too Little, Too Late? Posted: Aug 14, 2011 9:16 AM
Reply to this message Reply
Yes, I'll concede that Java *probably* advanced the "state of practice" (i.e., what programmers actually do, compared to what research has already been done). I say probably because langauges like Perl, Tcl and Python already existed and had many of these features, so I'm not entirely sure if they had already made their mark when Java came along.

> When a machine can do pointer arithmetic why should I do it?

I resent the language designers telling me that some topic is off limits because it's too hard for the average Joe; especially a topic like pointer arithmetic which, in fact, is super-easy. Or operator overloading (especially given the fact that Java overloads the + operator for strings).

One of the original justifications for Java's limitations was that they led to a simpler language. That may have been true fifteen years ago, but the Java of today has as much cruft as any language I've ever seen, and still ties your hands on "difficult" subjects ("difficult" being defined by the Language Committee, not real world use).

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Java 7: Too Little, Too Late? Posted: Aug 14, 2011 9:25 AM
Reply to this message Reply
People often say that Java's big strength is the large number of third party libraries out there. But given that those programmers can't be trusted with pointer arithmetic, I'm not sure I trust those libraries to do what they're designed for. Especially given that one of the JSPs recently stated that there were several bugs in the Java standard library related to incorrect use of try ... finally.

Another thing that rankles me is that, although Java was marketed as "the successor to C++" it did not solve a number of standing issues in C++ and it repeated a number of mistakes that C++ had already learned from by the time Java was released. In other words, Gosling doesn't appear to have actually spent the time to read the 200 page book The Design & Evolution of C++. If he had, I would have taken his work more seriously.

I believe that Java's main success stems from mundane things, such as offering a cross-platform networking library.

Fred Finkelstein

Posts: 48
Nickname: marsilya
Registered: Jun, 2008

Re: Java 7: Too Little, Too Late? Posted: Aug 14, 2011 11:12 AM
Reply to this message Reply
>> People often say that Java's big strength is the
>> large number of third party libraries out there.
>> But given that those programmers can't be trusted
>> with pointer arithmetic, I'm not sure I trust those


trusted with pointer arithmetic? Same issue as with guns: you can trust people and give them guns, but they can do dangerous things with them. Even if <i>you</i> don't do dangerous things you can be seriously hurt by someone who does!
It's best not to give them the guns (not all Americans understand this argument but I hope that they will some day). Also an issue with pointers is: If it goes wrong your program just gives this error:


Program terminated with signal 11, Segmentation fault.


So now, have fun with gdb. I'm not that masochistic kind of guy.


>> libraries to do what they're designed for. Especially
>> given that one of the JSPs recently stated that there
>> were several bugs in the Java standard library related
>> to incorrect use of try ... finally.


Java rocks. There are more than 500.000 web sites using J2EE. Now it's your turn.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Java 7: Too Little, Too Late? Posted: Aug 15, 2011 9:07 AM
Reply to this message Reply
> trusted with pointer arithmetic? Same issue as with guns:
> you can trust people and give them guns, but they can do
> dangerous things with them. Even if <i>you</i> don't do
> dangerous things you can be seriously hurt by someone who
> does!

I've never believed the "I'm not a moron, just the other guys are" argument. But assuming it's true, then it supports my argument: there may well be "more than 500.000 web sites using J2EE" but if the programmers who wrote those sites are all morons, then I suspect that those sites are bug-riddled.

It reminds me of the PHP library I once saw that generated GUIDs by (1) generating a random number, and (2) formatting it as a GUID. At first I was appalled, until I realized I can't expect a PHP programmer to know that generating a GUID is harder than that ( http://blogs.msdn.com/b/oldnewthing/archive/2008/06/27/8659071.aspx ).

Java code almost always gets try ... finally wrong (eg., that JSP saying the Java standard library had it wrong something like 1/3 of the time), gets error handling wrong "it's easier to have four nested try ... catch blocks, with subtle interactions between them and the nested finally blocks than to use error codes!"), more often than not creates object oriented spaghetti by requiring OOP even in cases where OOP simply doesn't make sense ( http://www.johndcook.com/blog/2011/07/19/you-wanted-banana/ ), often uses threads for no apparent reason (and, of course, has a mediocre threading model carved in stone), is incredibly verbose for what's actually done, and offers such a poor GUI library "out of the box" that several projects have gone through the trouble of replacing it. J2EE code has more of these problems than generic Java code, and adds its own issues as well.

I can respect people who pick a language that handles the details (Python), looks at problems differently (Erlang), improves on C++ (D), etc. But I have a hard time getting interested in a language that -- successfully! -- was marketed as "you can program in it, but we took out the hard parts." Programmers who have selected that language over others are not programmers I want as coworkers ( http://article.gmane.org/gmane.comp.version-control.git/57918 ).

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Java 7: Too Little, Too Late? Posted: Aug 16, 2011 5:03 AM
Reply to this message Reply
For a much more pro-Java view of why Java was a success, see Josh Bloch's talk from OSCON Java 2011. ""Java: The Good, Bad, and Ugly Parts"


http://www.youtube.com/watch?v=hcY8cYfAEwU

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Java 7: Too Little, Too Late? Posted: Aug 19, 2011 6:24 PM
Reply to this message Reply
> I believe that Java's main success stems from mundane
> things, such as offering a cross-platform networking
> library.

By and large, java's success is due to tomcat/jasper/websphere/jsp/struts/etc. IOW, Big Corp intranet apps. It's the current COBOL, and treats data just like COBOL has since the 60s. sad, sad, sad.

And let's not forget that oak was designed to run set-top boxes and the like. That very low level architectural decision still permeates the language.

Fred Finkelstein

Posts: 48
Nickname: marsilya
Registered: Jun, 2008

Re: Java 7: Too Little, Too Late? Posted: Aug 20, 2011 1:02 AM
Reply to this message Reply
>> By and large, java's success is due to tomcat/jasper
>> /websphere/jsp/struts/etc. IOW, Big Corp intranet apps.
>> It's the current COBOL, and treats data just like COBOL
>> has since the 60s. sad, sad, sad.


what do you mean by: treats data like COBOL? That sounds very vague to me, if you could explain please?
I personally think it's fun writing java code and don't feel sad. Great standard library, tons of useful java code/libraries online, huge community..
Of course you can use or implement java libraries with another jvm-language (like scala) too. So this is due to jvm and not to java language. In general software reuse is great - no need to invent the wheel over and over again. So I think jvm usage (of languages like scala) is great because valuable and proven java libraries can be used. This is a major progress in software development.

Flat View: This topic has 64 replies on 5 pages [ « | 1  2  3  4  5 | » ]
Topic: WebSockets: A Glimpse of the Future Previous Topic   Next Topic Topic: First Impression: Scala Goodies

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use