JavaLanguage

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".