JavaLanguage

ThoughtStorms Wiki

ProgrammingLanguage that I don't like much.

Why do I hate this stupid language?

Watch RichHickey's take down on DeathBySpecificity

See LackOfLiterals

And JavaNamespacesForIdiots

Update, September 2004 : I wonder if I'm wrong about Java

Not that it doesn't suck to have to write, of course. It does. But I'm concerned by the degree to which Java is basically taking over. When I try to explain why Java is so popular my usual answer is "it's the libraries, not the language itself" People choose Java because there's already such a large community of people writing libraries for everything you can think of. So the platform is very healthy, and all those libraries can be combined.

Which is all very true. And merely an example of run-away PositiveFeedback plus ReedsLaw as all those libraries can be combined in various ways.

But then Java advocates are always on about how Java scales better for large scale systems. And my usual answer to that is "pshaw! Go read SituatedSoftware. And anyway, I can't see any real reason why Java scales up better than any other ObjectOriented language like, say, (picking entirely at random :-), PythonLanguage.

But now I wonder ... what about all those libraries? Is it only run-away positive feedback? Or is there something about the language that encourages libraries to flourish? Could there even be something about the restrictions that make it more likely that libraries can be used together, which in turn gives ReedsLaw a helping-hand, which in turn feeds back into the exploding popularity of the language.

It's not that I can think of any particular reason this might be so. But there just is the evidence right in front of my eyes ... Troubling.

See also : TheArchitectureOfParticipation, ProgrammingLanguagePlatformWar

The old stuff ...

Oli said (over on TypesOfProgrammingLanguages, but refactored here) : While I may have gone off Java as an appropriate language in which to develop bespoke web applications ... it's still a beautiful OO language if that's what you need.

Clearly, I approve of the first statement. What do you think of replacing it with? Can you recommend that alternative to local authorities or are they locked-in to APLAWS / Java for the next generation?

Beautiful language? Java is not a beautiful OO language. SmallTalk is a beautiful OO language. And by all accounts so is RubyLanguage. (PythonLanguage can be, but isn't necessarily OO so purists will complain.) One of the insidious myths of our time is that Java defines OO and that Java techniques, and the patterns that are needed to work with it, are what counts as OO.

What Java is, is a minor variant on C++ with a decent garbage collector. As such, it's an OK systems programming language (as long as the system you want to program is the JRE); and can be nicer than C++ or C for C++ programmers writing desktop applications. Everything else is controversial.

But really I'm a rank amateur at Java dissing compared to the beautiful rhetoric of JackHerrington of the CodeGenerationNetwork :

The reality is that the history of Java is a litany of failure. It never worked on toasters. So they tried Applets. Now if you read "Bitter Java" Applets are listed as an anti-pattern. So they tried the desktop with Swing, and NOBODY shipped any of that. The only shipping Swing apps are Java IDEs.

So they tried the Web Server, and have basically hyped that to the point where they showed a perceived success. Sun was talking about Java 'Enterprise Applications' on the server when there was no justification or history behind it. Publishing white papers that said that Java scaled better than PHP when there was no evidence to support that, and when in fact, it was quite the contrary in reality.

Now that Microsoft has come along with .NET you see Sun trying to swing the Java community back to being interested in mobile devices. So this optimal 'enterprise language' is now the best for small 'mobile computing' applications and games programming.

We have come full circle! This toaster language grew wings and became an amazing enterprise applications language, but then back to being a toaster language. Without ever making substantive changes to syntax! Quite amazing.

Seriously. You can't just go around quoting the Sun Java hype machine and spouting their silliness about being scalable, or being the 'optimal enterprise application development environment', or the language being capable of doing things other languages just can't. It's all just hype and as engineers we should look past the hype and work on FACTS. We owe that much to our customers.

(http://blogs.law.harvard.edu/philg/comments?u=philg&p=1948&link=http%3A%2F%2Fblogs.law.harvard.edu%2Fphilg%2F2003%2F09%2F23#a1948))

Via PhilipGreenspun dissing Java : http://blogs.law.harvard.edu/philg/2003/09/20#a1762))

I'm not just repeating the above because it's beautiful. There's also an interesting point. BjarneStroustrup, suggests that the virtue of C++ is that it's a small language that keeps all the specifics in libraries. (Maybe http://www.artima.com/intv/elegance.html) Maybe) Java's ability to be a great toaster language and enterprise server language is that it's inherited that philosophy. (Compare GrowingAProgrammingLanguage)

The spirit shared by C, C++ and Java : http://www.artima.com/cppsource/spiritofc.html

In those same comments to PhilipGreenspun above, I said :

Java is the peacock's tail of programming tools. It doesn't exist to make life easier, it exists to filter out the unfit and reveal the smartest, hardest working programmers. (HandicapPrinciple)

I'd "hire" Java programmers in an instant. Just, having hired them, require them to build in Python.

As to the posts about Java vs scripting scalability, consider this : AolServer and TCL scale to a pretty large number of users. Given that web traffic is distributed according to a power-law, the number of sites that need to scale larger than any scripted solution can handle, is miniscule.

Writing these kind of exotic systems requires special techniques and tools, but so does writing massively parallel scientific applications. I'd suggest both are areas that you might choose to specialize in, but aren't a necessary part of everyday web / internet work. And tools for them probably don't need to be part of the core curriculum.

See also SituatedSoftware, for this argument taken to it's logical conclusion, application sizes distribute according to a power-law, so only a few applications need to be really big.

PhilJones

2008 : It's over in enterprise "web" applications : http://andigutmans.blogspot.com/2008/03/java-is-losing-battle-for-modern-web.html

Java by it's cover : http://www.paulgraham.com/javacover.html

Hundred year language : http://www.paulgraham.com/hundred.html

Why it's better than .Net : http://www.manageability.org/manageabilityWiki/WhyJavaIsBetterThanDotNet

BruceEckel on it's future : http://mindview.net/WebLog/log-0055

A "Java hataz debunked" piece which is pretty well debunked itself in the comments. : http://www.sys-con.com/story/feedback.cfm?storyid=46095

Verbose : http://www.cabochon.com/~stevey/blog-rants/lisp-wins.html

Quora Answer : Is Java a good language for web development? Why or why not?

Jul 13, 2011

I voted up Anon's critique because it shouldn't have been downvoted / hidden.

In my experience Java has been a pain in the proverbial for web development. The combination of static typing, explicit compilation stage, XML config. files and, yes, verbosity all count against it.

But ... the truth about Java is that it's all about the tools and environment. I've written Python / Django in Emacs on an Asus netbook and it was OK. There's no way I could write a Java web-app under similar circumstances.

If you like Eclipse, have a machine capable of running it fast enough, the right plugins and the rest of your environment set up right (don't ask me how), then you can probably make Java work as well as anything else.

But why do you WANT to use Java over the one of Ruby / Python / Perl / PHP / Javascript / Erlang / Smalltalk? The only reason is if you already have a Java system you need your back-end to connect with. Or there's a special library that's only available in Java that's not available elsewhere.

Does Java dumb down programmers? I'm thinking of Joel Spolsky's essay.

Sep 8, 2018 https://www.quora.com//Does-Java-dumb-down-programmers-Im-thinking-of-Joel-Spolskys-essay/answer/Phil-Jones-He-Him

Joel's essay is more subtle than that.

What he is pointing out is that there was a moment when computer science degrees seemed to be getting more focused on a particular kind of software development : Java-style, object-oriented application programming. Which was seen as what industry wanted.

And that this was missing some important challenges to thinking; eg. using pointers and higher-order functions, things that were about juggling multiple levels of indirection / abstraction which were essential skills for programmers to get.

Now, I agree with Spolsky entirely that this juggling of multiple levels of abstraction is very much one of the major skills of a programmer. And, indeed, fluency in juggling layers of abstraction is one of the things that separates good -> better programmers from "OK" programmers.

And I think he has a reasonable point that both pointers and higher-order functions are two places where you are confronted with juggling these layers of abstraction and just have to start groking that fairly early in a computer science course.

Now. that doesn't mean that there is nowhere else, eg. when using Java to write application software in the real world, that you won't also find yourself having to do this. But maybe there's nothing so obviously like it as part of the standard curriculum, or "toy" or teaching examples for Java-style OO.

Maybe some of the more complex Patterns do. Something simple like Singleton doesn't, but maybe Bridge Pattern pushes in the right direction. If everyone was learning to think and reason about Patterns with a fairly high level of competence / fluency then I could imagine that they could teach the same general lesson.

OTOH, in many places, Patterns are offered as the kind of opposite. As some kind of rote-learned formula that students pick up without understanding

At the same time, we should remember that people have always complained that easy and practical languages tend to dumb down computer science. I went to college in an age when professors would sneer that my generation who had grown up on 8-bit computers were "BASIC damaged". BASIC was another language that, by being too easy, allegedly prevented us from really understanding.

At the time, I laughed right back at them. But 30 years later, and a bit more circumspect, I have some sympathy. Obviously it's a truism that when things are hard people have to be tougher. And the challenge is to know when the trade-off is worth it or not.

I can certainly think of things that I do now understand that I would have benefited from understanding twenty years earlier but which I missed out on. And perhaps if I'd had one of those hardcore MIT-style Scheme based courses, perhaps I would have.

For example, I did a bit of OO in Smalltalk (still quite exotic in the 80s). But even as I understood inheritance and overriding, I didn't fully grok the more general sense of polymorphism. Or know how to reason about it detached from the idea of inheritance. I wrote terrible C++ in the early 90s because I didn't have a proper feeling for it. And just imagined that OO gave me certain things by magic that it didn't. (I had very brittle, inflexible class hierarchies and wasted lots of time re-writing them.)

Spolsky's essay is valuable. But what's valuable is not "Java makes you dumb" but suggesting that pointer arithmetic and higher-order functions share this common characteristic of helping you practice juggling levels of abstraction.

Are there issues with Java?

Jul 25, 2019 https://www.quora.com//Are-there-issues-with-Java/answer/Phil-Jones-He-Him

Widget myWidget = new Widget();

Java really doesn't grok the concept of "Don't Repeat Yourself".

And seems to delight in gratuitous verbosity.

Widget(int x, int y, int z) {

\\tthis.x = x;

\\tthis.y = y;

\\tthis.z = z;

}

Haskell can do the same thing with better type-safety in a single line :

data Widget = Int Int Int

Checked exceptions suck. They force you to try to handle a problem exactly where you don't know what you want to do with it, because you are deep within a library and have no idea what the overall context is.

The only sane thing to do with an exception is to throw it upwards to someone who might know what to do with it. But being forced to deal with it down there creates strong incentives to just eat the exception (ignore it or turn it into some magic return value that no one knows about.)

The right thing would have been to continue to have the exception in the method signature, but not force every method to wrap a use of an exception-thowing method in a try. Instead just have the compiler force the "main" or similar top-level function to do something about the potential exceptions bubbling up. Not require every single layer of callers to have to deal with them.

As Steve Yegge once pointed out, Java's real problem is the difficulty of constructing complex data literals. If you want to make several layers of nested lists / maps in Clojure EDN you can just write things like

[{:a [1 2 3] :b [4 5 6]}

{:a [5 6 7] :b [9 8 7]}]

etc.

In Java, trying to represent complex data becomes exponentially painful the more layers deep you want to go. The symptom of this problem is the reliance on external XML files for any kind of complex data literals that need to be brought into your program. XML is another horribly verbose, human-hostile language. And having to manage dependent external files and to use libraries for reading and extracting XML makes Java truly one of the most laborious languages to do real work with.

Unlike C++ which has ordinary functions with function pointers. And Smalltalk with codeblocks that work as lambdas. Java really is the "Kingdom of Nouns". Which adds a whole new layer of complexity / verbosity, as every time you want to send a method as an argument to a "higher level" method, you need to wrap it up in an object and a class.

Yes, some of this is now being addressed. But features added to languages 25 years into their life are rarely an elegant fit, and you can't rely on legacy code to be using them.

The philosophy that classes are the only mechanism necessary for organizing modularity in code leads to absurd kludges like "Singleton Pattern" which allows you to use classes to emulate what any sensible language would handle using a distinct "module" mechanism. Combine that with the insistence that each class must have its own separate file whose name and position in the file system reflect the qualified class-name, and you explode even quite small programs into a ravioli of thousands of files, pretty much obliging you to use a heavy and complicated IDE, just to manage them all.

Finally, I have a broader critique of OO languages, which I develop more fully here : what's wrong with OO . But in summary, the main feature of OO is that your system is a network of communicating objects. But no OO language, not even Smalltalk, has any in-language mechanism for talking about a network of communicating objects. There no elegant, declarative way to say "here's a bunch of objects and how they are wired together". All you can do is imperatively create and wire them up. In some obscure place in your code's flow of control.

But OO is desperately crying out for a high-level overview of a network of objects. As I put it before, "Somewhere deep in the heart of the UML is a good intuition, struggling to find a viable implementation."

You might say it's unfair for calling out Java specifically for this lack, because even Smalltalk lacks it. Nevertheless, Java has been the flagship "mainstream" OO language for 20 years. A huge amount of Java code is dedicated to getting round this lack. Eg. all those Factory patterns etc. are basically just ways to encapsulate the "declare the network of objects" in a single place. Things like the UML have been developed. Various tools and front-ends. All to compensate for what Java should have had from the beginning. A convenient declarative syntax for "a network of objects wired together".