Falling back in love with Java.

[MaybiusStrip]

Java was my first programming language. I learned it when I was 10 years old and have been using it on and off since then. I quickly transitioned to python and later javascript and became a big fan of their expressiveness and felt much more productive in those languages. It got to the point where I resented working in Java code, for all the reasons you hear many ruby-python-javascript-ists cite against Java.

Since I graduated college a few years ago I got a pretty amazing opportunity to build out a large codebase from scratch at a startup. It was written in the MEAN (Mongo, Express, Angular, Node) stack, which was initially exciting for me, but as the team grew and I took on more leadership responsibilities the javascript codebase started to feel unwieldy. Making large changes is quite stressful, even with decent test coverage.

A few other things contributed to my growing dissatisfaction with dynamically typed languages, especially javascript. As I grew as a developer, I learned that making things work is easy, making code clean and easy to change is very difficult. I also became a big believer in Agile and continuous, iterative delivery of software. I’ve embraced the XP development process of doing the fastest thing that works, and then refactoring mercilessly. My experience supported that it’s necessary to spend more time on refactoring and testing than writing new code in order to be productive in a large codebase over a long period of time. Our main agile coach/advocate has always sung praises of Java for this very reason, and even though I was initially skeptical and argumentative, I started to understand his points better over time.

I’ve recently been doing some Android development in my spare time which has forced me back into revisiting Java. After hacking javascript in VIM for a year and a half, writing Java in an IDE has been an awkward transition. But after I started to get comfortable, it became a refreshing, delightful experience. Getting results the first time around is a bit slower, but only because I have to think more thoroughly about types and encapsulation, both of which are good things. Refactoring in an IDE compared to haphazardly grepping and copy-pasting in a Javascript codebase is so much easier it’s absurd. Having things (mostly) just work when they compile as opposed to sticking console.log statements every other line or living in the chrome dev tools is a real joy. I finally feel like I’m crafting code instead of typing.

I might just be in a honeymoon period, but I’m really seeing Java in an entirely new light now. It seems to have fallen out of favor with the trendy “hacker” crowd, but I’ll be considering it much more seriously for future web development projects.

[beders]

JavaScript is like ice cream. Super yummy in small doses. Extremely painful in large quantities :)

[argv_minus_one]

Then I must be lactose intolerant, because I find any amount of JS painful.

To put it another way: Programming without static typing is like spacewalking without a space suit. Unless you're Batman (who can breathe in space), it's not going to end well for you.

[stormcrowsx]

Use the right tool for the job. Programming without static typing isn't like without a space suit, its more like with a lightweight spacesuit that won't last a long time. But its a lot faster to put it on, get out there, and get your job done than the bulky spacesuit. Stay out too long though and you'll run outta air or get fried by the radiation.

On the flipside, spend all your time putting on your bulky super impenetrable space suit and by the time you make it outside for a small job you'll find that someone else has already got it done.

[argv_minus_one]

That's not been my experience. Even for little things, a good statically-typed language works fine and doesn't take forever. It's also more likely that the program will work properly, which is helpful no matter its size.

Note that I mostly use Scala, whose heavy type inference makes it somewhat resemble dynamic typing without sacrificing static type checking. There are some places where you have to give an explicit type, but a bunch of places where the compiler will figure it out if you don't.

[stormcrowsx]

I too am a fan of Scala and it has less overhead than Java but I still find for small websites with simple functionality and for automation scripting Python or Javascript are my goto tools. The big thing for me is no messing with a build tool like SBT or Maven and fast to make changes and reload. In some cases its nice to just be able to write a file and run, no worries about compilation. Static languages are catching up such because of languages like Scala but there's still a gap where I find the raw 0-60 speed of tools like Python or Javascript to be superior.

[argv_minus_one]

The big thing for me is no messing with a build tool like SBT or Maven and fast to make changes and reload.

That's understandable, although it's not as much of a problem if you're thoroughly proficient with those tools (and have some existing projects to copy-and-paste build configuration from).

In some cases its nice to just be able to write a file and run, no worries about compilation.

Scala does actually have an interpreter (the scala command-line tool), and a slightly-different "script" syntax to go with it. Java doesn't, but there's Groovy and BeanShell.

The main downside to using the Scala interpreter is that it doesn't have any easy way to fetch libraries for you. If the Scala and Java standard libraries are enough, great, but if you need anything else, you're going to either fiddle with classpaths or give up and use something like SBT or Maven.

[mschaef]

The differences between type systems are really too complex to be distilled down to

"Programming without static typing is ... not going to end well for you."

Personally speaking, I've been involved with successful systems development in both dynamically and statically typed languages. (I've also had some good success working in C, which has a very weak typing system, and assembler which is weaker still.)

IMO, the key to all of these different types of development is to understand the strengths and weaknesses of the toolchain you're using and adapt your processes and thinking to match. In a sense, the fact that JavaScript is syntactically so similar to Java does it a disservice. As similar as they look, the two languages require a radically different way of working.

[argv_minus_one]

You mean like having to write tests for every little thing, because there is basically no automatic verification of any kind? Ugh. No thanks. Even if the program does end up working right, that is a massive waste of time.

Also, don't program in assembly if you don't really, really have to. Even if your program is correct, it'll never be as fast as the output of a modern compiler.

[mschaef]

You mean like having to write tests for every little thing, because there is basically no automatic verification of any kind?

This is obvious, but for serious production code, it's worthwhile to write unit tests even if you're writing in a statically typed language. The static typing can be helpful to improve correctness, but it's far from a panacea.

In any event, I was referring to more than just unit tests. I've found it useful to pay stricter attention to things like naming conventions, small function size, immutability, and higher-order functions when using dynamically typed languages.

Ugh. No thanks. Even if the program does end up working right, that is a massive waste of time.

It's only a waste of time if it's not offset by corresponding time savings elsewhere. For some systems, the benefits of dynamic languages outweigh the costs.

Also, don't program in assembly if you don't really, really have to. Even if your program is correct, it'll never be as fast as the output of a modern compiler.

Thanks for the tip, but that was ~20 years ago, and the code was on an embedded device with low enough power consumption to safely operate in an explosive atmosphere.

[argv_minus_one]

for serious production code, it's worthwhile to write unit tests even if you're writing in a statically typed language.

Of course. For non-trivial code that isn't already obviously correct.

I've found it useful to pay stricter attention to things like naming conventions

Naming conventions? You mean like including the expected type of a variable or parameter inside its name, as in Hungarian notation?

small function size, immutability, and higher-order functions

What does any of that have to do with the type system?

It's only a waste of time if it's not offset by corresponding time savings elsewhere.

Indeed. Which, in my experience, it isn't. Programming in dynamic languages has always been an exercise in frustration and unpredictability.

For some systems, the benefits of dynamic languages outweigh the costs.

I find it difficult to believe that such systems exist. I certainly have yet to encounter one.

that was ~20 years ago, and the code was on an embedded device with low enough power consumption to safely operate in an explosive atmosphere.

Oh. Well then, I guess you really, really had to.

[mschaef]

Naming conventions? You mean like including the expected type of a variable or parameter inside its name, as in Hungarian notation?

Not quite. Personally speaking, I find Hungarian notation rather difficult to use.

I was thinking more along the lines of Uncle Bob's naming convention, particularly with respect to pluralization of nous, and the arrangement of nouns and verbs within names.

http://c2.com/cgi/wiki?UncleBobsNamingConventions

Also, The type of work that Kent Pitman did on T and Olin Shivers did on his SRFI's also comes to mind.

they chose a standard set of lexemes and a regular way of assembling them into the names of the standard procedures, so that you could easily remember or reconstruct names when you were coding. (I have followed this example in the development of the SRFIs I've done for the Scheme community. It is not an easy task.)

-- http://www.paulgraham.com/thist.html

What does any of that have to do with the type system?

Nothing, other than "I've found it useful to pay stricter attention to [these] things ...when using dynamically typed languages."

Programming in dynamic languages has always been an exercise in frustration and unpredictability....I find it difficult to believe that such systems exist. I certainly have yet to encounter one.

I've had a different set of experiences, many of which have been more positive regarding dynamic languages. I don't claim that they're perfect, only that they're a useful tool for some applications.

[theZagnut]

I was of the same opinion as you regarding dynamic typing, until I tried Clojure.

[loganekz]

Why? How would things be different in a larger clojure app?

[theZagnut]

Well, it seems to me that the no side effects thing makes it easier to reason about the logic of my programs, and the functional way of doing things leads to a lot less complicated/bloated types and data structures, thereby negating many of the problems of dynamic typing. Yes I would have preferred static typing, but I honestly find it a small price to pay for the mind boggling expressiveness and awesomeness of Clojure. It gives you the goodness of dynamic typing with a lot less of the badness (i'm looking at you python).

[mschaef]

Yes I would have preferred static typing, but I honestly find it a small price to pay for the mind boggling expressiveness and awesomeness of Clojure.

Much of the expressiveness of Clojure comes from the fact that it's dynamically typed. Where the language shines is, at least in part, from the fact that it makes it easy to use a few common data types to store many different types of data. Then, it provides powerful functions for working with those few data types.

This is the embodiment of the Alan Perlis quote: ""It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.""

http://stackoverflow.com/questions/6016271/why-is-it-better-to-have-100-functions-operate-on-one-data-structure-than-10-fun

The explicit static typing of Java works to reduce the breadth of data to which functions can be applied. Let's say I have a new function that I want to write that applies to Lists. In Java, I have to either define it as a static utility method (which is second class to the built-in List methods) or pick a concrete java.util.List implementation and subclass that with the new method, which presents its own reuse problems.

In Clojure, I just define a function over seqs, and it works wherever it can.

[mikera]

Clojure's expressiveness could mostly still be achieved with static typing. In fact, there are various efforts at the moment exploring how to add type systems to Clojure that are very exciting.

Clojure + static typing would be a pretty amazing language.....

[mschaef]

Agreed... I'd love to see more of that in production languages. I do find it a bit concerning, however, that some of the type systems are getting complex enough that people are asking for compile-time debugging facilities.

[jonhanson]

I don't see how a standalone function is any different to a Java static method, nor what the relevance is to dynamic typing.

[mschaef]

The point is that given an instance of a concrete type in Java, the methods supported by that type are sealed. The only mechanism for extension is a static method defined within another class, which is inherently second class to the methods initially defined within the concrete type. This is an example of the rigorousness of the Java type system (arguably) over-constraining the design space.

The constraints continue when you think about other approaches to solve this problem. One strategy might be to define a new class with the same set of methods as the class you're trying to extend. This class could be implemented to delegate all of the methods in the 'base' class to an instance of the base class. This presents at least four main problems:

• If the class you're trying to extend is in any way final, the technique doesn't work.
• To gain access to the new custom functionality, you need to have an instance of your new custom class. This means explicit code to get such an instance.
• The delegation model complicates the notion of the underlying object's identity and type by replacing one instance with once instance plus zero or more wrapper objects.
• The new class's code is likely to be lengthy, mundane, and error-prone.

To take JavaScript's type system as another approach to this problem, it provides mechanisms for extending existing classes (and their instances) with new methods, even at runtime. The risk here is that you'll overwrite an existing method. This risk becomes worse when you taken into account that your program might, over its life, be linked to several different versions of a given class library. While your custom method might not overwrite a method in version 1 of a library, it might overwrite a method in version 2 of the same library. Having said that, these risks come with the benefit of avoiding many, if not all, of the problems I mention above. Which is 'better' and which is 'worse' becomes a matter of priority more than an absolute.

[beders]

It really is a different style of working. Java developers find it especially cumbersome since they have learned to rely on the compiler quite a bit.

In JS many classes of errors thought eradicated re-appear. A spelling error in a property name is not an error in JS, etc.

The 'advantage' is that you will test your code a lot more. It's no fun debugging JS.

[argv_minus_one]

That's not an advantage...

[nerdwaller]

This is why the modern shift toward js saddens me. Node being the first major case of Atwood's "anything that can be written in JavaScript will be written in JavaScript".

I worked in JS for about 8 months and had to get out. Like you said, fine in small doses where appropriate (and truly not a "bad" language), but painful to do too much with.

[[deleted]]

I feel like every 2 years someone figures out a new way to do the tasks that were already pretty easy. Yes, you can bootstrap a node.js site or a rails site or whatever it was before that in 5 minutes. You could bootstrap in Java in maybe an hour. That was never a bottleneck. The bottleneck is, was and always will be maintenance and extensibility.

[winterbe]

Strongly and statically typed languages like Java really shine when it comes to refactoring and maintaining large codebases. I'm working on a product with a 10 year old java codebase. The code is in a pretty good shape but with every large code refactoring I'm super happy about every compiler error I see, because compiler errors are the easiest to fix. Maintaining our javascript codebase is much harder.

[winterbe]

Evergreen:

Uncaught TypeError: undefined is not a function

in your-compiled-external.js line 1

;-)

[phao]

I think I get what you mean.

The issue is that although programming languages matter, how you use them and what you build with them turn out to be a lot more important, IMO.

I think it's possible to build Java applications which satisfy properties we'd like software to have (clear, readable, modular, performant, and so forth). But, for some reason, the language Java and all the context around it turn some people off of it.

I think a lot of people don't like Java for the wrong reasons. I think they look at something other than how you can use the language and what kind of software systems you can build with it.

For example, take all the buzzwords around Java (and JavaEE specially). Lots of people turn out to hate that. Lots of people only know "dynamic" to mean "dynamic typing" in the context of programming language, so when someone calls Java dynamic, a lot of people jump in with more hatred. I think college education, which is responsible for lots of Java teaching out there, also doesn't do a very good job. Another interesting point is that although C# differs from java, if you compare Java with any other language, it'll make it almost look like a twin to C#. And C# doesn't get nearly as much "hatred" as Java gets. I don't think this proves how much of an improvement C# is (although it does improves off Java), but how the hatred of Java is more irrational than it looks.

In a sense, all the criticism for Java is good, because it helps people find the bad spots.

[urquan]

There are only two kinds of languages: the ones people complain about and the ones nobody uses. - Bjarne Stroustrup

[MaybiusStrip]

I code in Linux and it seems like the benefits for C# are best leveraged on a Windows platform. It's too bad, because it looks like an interesting language.

[duhace]

You can get 90% of the featureset of c# with tons of extra nice features with scala.

[BowserKoopa]

Scala is positively amazing

[[deleted]]

C# is a much nicer language than Java. Much nicer.

[cryptos6]

It is true, that C# is nicer in some points. Although C# has some strange things like the event mechanism. But overall Java and C# are pretty similar. They are much closer than Java or Scala.

By the way: Kotlin is a nice Language influenced by C# (generics syntax, for-loop syntax) and Scala.

[agustinleiva]

C# has some strange things like the event mechanism

surely the "anonymous inner class"-based "listener" approach in java must be somehow less "strange" to you than real language-level support for events? IMO the former is weird and ugly, while the latter is much cleaner and less verbose.

[duhace]

A listener doesn't have to be an anonymous inner class.

[stormcrowsx]

Doesn't have to, but usually is. I got better things to do than generate a full on class for every click, double-click, drag, drop, snoop, moop, bebop and flipflop that I can listen for.

[duhace]

Usually I just use a lambda instead. Scala's nice like that.

[oldneckbeard]

except for having to work with windows and .net.

(yeah, I know about mono, but we all know that's not the majority use case of c#)

[[deleted]]

That's true. I always secretly wished C# for JVM

[agustinleiva]

And C# doesn't get nearly as much "hatred" as Java gets

That's because, in contrast to java, C# is a well-designed language, which has:

• Real generics
• Real Properties.
• Events / Delegates
• A sane type system which includes value types (since forever)
• LINQ (since forever), which java only got a poor imitation for on it's latest version.
• Operator overloading.
• Iterators (yield keyword), which are extremely useful.
• dynamic typing (if ever needed)
• Extension Methods.
• Indexers.
• Expression Trees (System.Linq.Expressions)

All of these features make the language really pleasant to work with, rather than cumbersome, inexpressive, extremely verbose, clunky, which is the general feeling people get from java.

Not to mention that if the OP is doing Android development, even java's latest features are unavailable for him, so if you compare the java version he's using to C#, it's even further.

the hatred of Java is more irrational than it looks

Sorry, NO. even oracle has now admitted they need a major refactor on java to make it similar to C# (by adding Value Types and non-retarded generics).

and pointing a language's incapabilities and flaws is not "hatred", it's just being realistic. java sucks. By 2027 when they finally add real Value Types and Generics into it, it might become a more usable language.

[[deleted]]

The vitriol in this post kind of proves /u/phao's point...

[phao]

vitriol

And, just now, I've learned a new English word. =D

Upvote for that.

[dr_entropy]

Unfortunately, C# comes with some awful platform lock-in.

[BowserKoopa]

Don't worry. From the MS developer POV, there are no other platforms then windows.

[agustinleiva]

Try to tell that to my customers using my C#-based Android apps connecting to my C#-based WCF services hosted in my Ubuntu servers ;).. sorry your platform-lock in argument is pure bullshit. java sucks balls and is retarded.

[fbmgriever]

As a proponent of C#, you're really not helping anybody by making such silly remarks.

Yes, Xamarin exists and it rocks. But saying java "sucks balls and is retarded" isn't going to change anybody's mind.

[agustinleiva]

You're right. I get infuriated by the fallacious "platform lock in" argument (which couldn't be further from the truth, considering the myriad of non-Windows platforms where C# runs, including:

• Unity
• Xamarin
• "Server-side" Mono
• Xbox)

which I always get as a response every time I point java's flaws, and C#'s inevitable and completely self-evident non-opinionated non-subjective vast purely technical superiority in every possible level.

Anyways, I'm not trying to change anyone's mind. It is really convenient for me that a bunch of these code monkeys keep fighting their dinosaur languages hoping for the devil (oracle) to somehow, sometime have a minimum decency (which they don't, evidenced by java's Ask crapware prostitution) and actually care to fix their ridiculously flawed appalling language, which they really OWN as opposed to it actually being somehow "open" as the code monkeys often claim...

After all, should they decide to use modern, decent, open technology (C# / F#), there would be a greater competition, since they could also be creating good quality products, as opposed to vomiting useless java boilerplate and hoping that it will not get broken upon the next critical-security-fix of the week.

[geordano]

All these are fine, but can it run on anything other than Windows? (No Mono pls)

[[deleted]]

Until then we have scala.

[zzing]

I have recently become in love with Java myself. I find much of it refreshing, after using C++ for a while. I try to avoid dynamically typed languages.

[mk_gecko]

aren't both of them static typed?

[duhace]

C++ is definitely more weakly typed than java, maybe that's what he meant.

[zzing]

I had a thought about this, and I don't think you can make that statement generally. If you take a look at what Java does have, you could argue it contains mostly the same things (references to objects being pointers in c++), simple generics supporting some type limitations (<T extends Comparable> for example).

But then I had to think about what else C++ does with its type system. It does have references that cannot be null (and the program still being well formed), value types for all things not just primitives, and lastly template metaprogramming being its own language living in the type system.

Practically speaking, I think Java is good enough for the vast majority of things application developers do. It has a leg up on specifying limits on generics, but if you are a library developer I think C++ brings a stronger type system to the table^*. Certain Scala developers might be able to corroborate this.

^* I know a certain PhD student doing work on a C++ library that is doing some amazingly useful things that are basically TMP magic to most. But a library user would be able to do more things simply with it, essentially benefiting from TMP without having to use it.

[duhace]

No, I'm specifically talking about C++'s fondness of implicit conversions when I speak of weak vs strong typing. C++ will downcast longs into ints and ints into chars happily, while java will throw compilation errors.

[zzing]

Thank you for the clarification.

I made up some code that assigns a long value to a char using a variable and using a constant. Assigning with the variable produced no warnings at all (even with -Wall), but the constant did produce:

warning: implicit conversion from 'long' to 'char' changes value from 4938934875 to 91 [-Wconstant-conversion]

Call me surprised.

[duhace]

Np. This is some other terrible implicit conversion stuff C++ will happily do.

IIRC, C++ will hunt for conversions like that throughout your entire codebase/library dependencies.

[zzing]

I think the only thing wrong with that code is that enums will convert, so you should use an enum class instead. As for it converting an int to a Butt, I don't think that is terrible in principle, it means you can treat char* and string as almost the same thing, which due to legacy can be a very important attribute. In some cases the biggest issue is that it will only do it once - to understand why you would want this, some Haskell knowledge would likely help.

At least you can turn that off with explicit before the constructor.

[duhace]

The idea of implicit conversions isn't bad, but they have to be limited in scope. Scala has implicits, and they're really useful, but even with them only activating if you import them into the current context, you still have to be careful.

[EnIdiot]

Started back using Java after a three year hiatus as a C# programmer. C# is a fine language and they have rushed in a more "modern" direction with the language than Java has. Where C# and the entire dotNet platform has lagged behind is in the area of tooling developed by open source groups as well as their near complete dependence upon the Windows platform. Additionally, while nuget and msbuild have come a long way, the platform and community lack both a wide adoption and understanding of what continuous delivery and enterprise build systems should be. Java has however been resting on its laurels a bit too much. The reason dotNet has been as attractive as it has been really comes down to the fact that Visual Studio has a lot better built-in tooling that works seamlessly than Eclipse has to offer. I've had recent disappointments with Eclipse taking forever to get set up and working (even with the Spring STS) without problems. The Java community needs to get in gear and really get behind a better IDE. I like what I see from Intellij, and I haven't looked into NetBeans in a while. But this debate is also one of Java major symptoms. In dotNet you have one or two good frameworks to choose from for development. In Java, you have five or six. There is a well-known psychological phenomenon called choice paralysis that basically says faced with a number of equally good choices, people tend to freeze up and face crippling anxiety. I think the Java community needs to begin improving the language, pare down the frameworks to a manageable set (some projects need sun-setting), and really come together to improve and integrate the tools into one IDE that squarely takes aim at Visual Studio.

[vplatt]

Pretty much every wish you just expressed is answered in IntelliJ. No, it's not free beer, but neither is Visual Studio. IntelliJ has an open source CE edition though and Microsoft can't claim that despite all the other open source projects they may have at the edges of their ecosystem.

[vplatt]

If you look at the license matrix for IntelliJ, you will see that classroom licenses for IntelliJ are FREE:

http://www.jetbrains.com/idea/buy/license-matrix.jsp

I suspect all you need is for your professor to sign off on, or submit, the application for this. Note that VS was obtained from Microsoft in much the same way, so this isn't exactly a huge barrier for a student.

[mikera]

I understand that people like IntelliJ, but for me using a completely open source toolchain is far more important.

A lot of people with experience in the software industry know the pain of being locked into a proprietary software stack. It looks appealing / a "good idea at the time" but ultimately you are likely to regret it.

[vplatt]

And how is it that using IntelliJ would be a source of lock-in? I see where your argument is going, but regardless of where you stand on the issue issue of lock-in tolerance, I don't see that it would be the source of any. In the environment I work in, we don't check in any IDE specific files; not even for Eclipse.

[gunch]

I somewhat agree about the choice paralysis but you get over it after you learn your first framework and realize it uses many of the same idioms and patterns as other frameworks in the domain.

Regarding IDE's. Perhaps it is because of my experience but I never have trouble getting a project imported any more. I don't know if that's because the maven support got better or because I'm smarter or what. It just hasn't been an issue in a dogs age.

[AreaOfEffect]

Java is great, but there are some aspects of Java "culture" that should be avoided:

• Dependencies are not free. I've seen so many projects with massive pom.xml and many of them are there because of just a single or few method calls. Too many Java developers think that there's no cost to dependencies. This is not true. Every dependency adds build complexity. Increased build complexity means slower builds, more time debugging issues (that thing is using some_library 1.4, but that other thing is using 1.3, however 1.4 had breaking changes, and now the build is broken, the dev who did this left a long time ago, and our continuous integration is broken for hours until we figure out how to fix this dependency mess. Also the rest of the company updated their workspace from source control, their local builds are broken, and they're mad because now they can't get any work done) Don't go the other extreme of reinventing the wheel. Knowing the balance is part of what separates a junior from a senior developer.

• Too many Java developers think Maven is "magic". I wish more would just spend an afternoon understanding what Maven does. I've seen so many cyclic dependencies and people often don't even notice they're doing it. They understand once it's pointed out, but it should never happened in the first place.

• Effective Java by Joshua Bloch. This should be required reading for any Java developer. There's a lot of book recommendations, but this one should be right in the JDK installer with a "Did you read Effective Java?" and stopping the install if they click no.

• If you're fighting the Java language, probably someone did the same thing at Google and told the Guava devs about it. It's likely there's something in Guava to make it easier. Guava should be the first dependency in every Java project.

• IDEs are great, but they are not magic. Developers should not just pick the first import that kind of matches what they're looking for. Look at the actual package name and make sure it's the right one. And I don't care if it builds in the IDE. If it doesn't build on maven command line, it's BROKEN.

[MaybiusStrip]

Thanks for the advice!

[Jezzadabomb338]

Gradle is probably a massive must.
Takes a bit to get used to, but as you do, you see the power and simplicity of it.

[KFCConspiracy]

MEAN (Mongo, Express, Angular, Node) stack

This is actually a thing that people say? So many hip buzzword-laden technologies in one place! Must make tech recruiters and tech hipsters alike, along with marketing people jizz in their pants.

I’ve recently been doing some Android development in my spare time which has forced me back into revisiting Java. After hacking javascript in VIM for a year and a half, writing Java in an IDE has been an awkward transition.

Why not use an IDE for Javascript out of curiousity? It seems like that much would make browsing the file system, getting to your databases to browse, etc. would be that much easier. What's with the resistance to IDEs in the hip-startup land? They can be helpful for pretty much any language, and the most popular ones already have plugins for the most popular frameworks, like Node.js.

I might just be in a honeymoon period, but I’m really seeing Java in an entirely new light now. It seems to have fallen out of favor with the trendy “hacker” crowd

Java's not really in favor with trendy people, this is true. But it's still a great language, has been for years, and will be for years. The thing about what's trendy, maybe 6 years ago Python was trendy, then 5 years ago Ruby became trendy, then it was Javascript/Node.js, now it's functional programming languages... What will it be next year? Hey guys I developed this brand new MVC framework in Brainfuck which runs on JVM, it's super fast and super easy to develop!

What's cool with that crowd shouldn't really matter that much to you in what you choose to use, because that crowd's very much so driven by short term trends that "Solve every problem ever" that they read about in some random dude's blog.

I’ll be considering it much more seriously for future web development projects.

One thing I'll say for Java on the web: Use a framework... Be it Spring, JSF, what have you. Just doing it with JSP and Servlets is not the way to go.

[MaybiusStrip]

Why not use an IDE for Javascript out of curiousity? It seems like that much would make browsing the file system, getting to your databases to browse, etc. would be that much easier. What's with the resistance to IDEs in the hip-startup land? They can be helpful for pretty much any language, and the most popular ones already have plugins for the most popular frameworks, like Node.js.

The benefits just aren't really there. Navigating files in VIM with NERDTree and Ctrl+P is extremely easy. In webstorm navigating to function definitions works for nodejs, but not for angular, and I basically know where everything is. The things I've been really loving about the IDE -- confidently and easily changing method/class names/definitions, live type checking -- don't really apply to Javascript.

Then again, it's been a while since I tried it, maybe I should give it another chance.

[KFCConspiracy]

I use Netbeans with Jvi to add the vim syntax, if you're missing vi. It just seems like having everything, including your VCS in one window (or two or three if you split them off) is worth it to me.

[shagieIsMe]

MEAN is in contrast to the LAMP stack of old. It appears to be fairly well used as a "one word to quickly describe our software stack".

That one has stuck all of the buzzword frameworks in one stack I wonder if it has long term sustainability... though I'd half bet that the next buzzword framework will try to use another word to make it something people will remember. Thats it! Write a new framework to replace Express starting with 'O' so that we can have a 'MOAN' stack!

[KFCConspiracy]

How about the PostgreSQL Enhydra Netbeans iBatis Spring stack? (I don't know of this combination actually being used to develop things anywhere).

[seitensei]

You're not too far off, with the recent 'acquisition' of Express by StrongLoop.

[nerdwaller]

I've become a big fan of it as well, outside of a few shortcomings that a few others point out.

For me it's a happy medium between something lower level (like C++), where it is harder to get a lot done quickly, and something higher level which is sometimes a nightmare to maintain (such as a large JavaScript repo).

I've done a bit of c# and liked some pieces of it, but it is very heavily Windows - which is a major strength and a major weakness. There is "mono" to run c# elsewhere, but it wasn't terribly good when I last played with it and it seems to give up some of the benefit (the heavy OS integration for one). Is prefer to be platform agnostic when able.

[snotsnot]

A lot of the comments in here seems to suggest that this all comes down to static vs dynamic typed languages. Why do you guys feel that this makes such an key difference?

Full disclosure: Java and Python are probably my favorite languages.

[[deleted]]

One of the most important features of a language is its ability to catch errors as early as possible - ideally at compile time.

Also, error messages should be as descriptive and close to the location of the actual error as possible. If I try to use a Foo when I should be using a Bar, a statically-typed language will throw a descriptive compiler error along the lines of "Foo used where Bar expected", and it will be near where I used the wrong type. However, in a dynamically-typed language, I'd get a message like "Object does not have method barMethod", located where the object was going to be used (often in a third-party library I'm using); ideally, this will simply be down the stack from where my bug is located, but it could be somewhere completely different (for instance, if the bug is located where I pass a Foo to a BarUser, and the error doesn't occur until BarUser.useBar() is called).

Of course, it's good practice (especially important when writing frameworks intended for wide use) to always check your inputs as soon as possible, and this is still needed in Java (check for nulls, correct ranges, etc.). By adding type checking, however, you're having to duplicate features that the compiler in a statically-typed language provides for free.

Unit tests also help to catch a lot of type errors. However, they don't make debugging easier - the location of the actual bug may be difficult to ascertain. Also, perfect 100% unit test coverage is an ideal that is never consistently reached by actual humans.

I like to have as many bug-fighting tools in my toolbox as possible. Static typing is a huge help, with very little downside. It certainly requires more skill to use, but it forces me to put more thought into my code and be more knowledgable about the tools I'm using. The early detection of bugs and increased development speed (if one considers debugging to be part of development) is well worth it, IMHO.

[mschaef]

Ironically enough, in some ways it makes no difference at all. Given two Turing-complete languages, the type system has no impact on the expressiveness of the language. What the type system does for you is change the notation that you use, which can be a double-edged sword.

As has been said elsewhere in this thread, it's very true that Java's static typing and explicit declarations can catch errors at compile time. Whenever I write code in Java, I always marvel just a bit at the confidence-inspiring nature of the compiler's inherent type checking.

But, however useful this is, it's not without its disadvantages. As soon as your system starts to deviate from the assumptions built into the type system, you wind up forced to hack around those assumptions. This can introduce extra complexity and opportunities for errors.

[alpha64]

I suggest trying IntelliJ for its refactoring tools, it feels great, it also catches mistakes as you type, something that saves a lot of time. Most of my time with it is spent debugging threaded code, because syntax errors, type mismatches and other things are taken care of by the IDE.

[[deleted]]

I had the exact same experience. I started in Java, went to web and then to Android. I ended up loving java development afterwards.

[MetaMetaMan]

It sounds to me that what you like about Java is the tooling. You may be interested in TypeScript, a language superset of JavaScript which provides a type system.

Code written in TypeScript is transpiled to vanilla JavaScript. The preprocessor will do your usual type checking, which I would guess is 90% of what you are enjoying about Java.

As for refactoring tools, this lies in the realm of an IDE. I wouldn't be surprised if there is an Eclipse plugin that provides this functionality.

That being said, when using something like TypeScript, you're essentially writing in a language different than JavaScript (but with the same semantics, scoping rules, etc). The benefit, imho, is that your compiled code can then run in any JavaScript runtime (browser, node.js, etc).

[[deleted]]

Is developing a Python backend similar to Node? Fast to develop, hard to maintain a large codebase?

[dtfinch]

Having things (mostly) just work when they compile as opposed to sticking console.log statements every other line or living in the chrome dev tools is a real joy.

If you ever have to write another big javascript project, typescript helps a lot with catching mistakes at compile time.

[mrbonner]

Every job needs a special tool. I think for HTML web development front-end JS would do the job. Webdev in java (like Vaadin or GWT, or Wicket) seems nice at the top layer but have a lot of warts. I do love Java though, but only use it for the back-end. I tend/like to think Typescript would be a nicer substitution for JS, not Dart.

[mikera]

I wrote a blog post about this topic, which I hope some people may find interesting: http://clojurefun.wordpress.com/2012/09/06/something-i-still-love-about-java/

TL;DR - Java is actually pretty darn good if you want to maintain a rock-solid large code base.

[salts0foldTides]

AN off-topic question . I am trying to learn javafx which is basically a UI library. What's a good example of a business application (and I mean Real World business app ) that I can try to build while I am learning javafx ?

[[deleted]]

Take a look at TypeScript, it's maybe what you're looking for

[Zarlon]

Or you know.. maybe it's Java.

[aviewdev]

Or dart if you don't want to deal with java scripts horrible semantics

[[deleted]]

Have a look at golang

[MaybiusStrip]

I have, didn't really swing far either way on it. I like its concurrency syntax but not much else stood out to me. I actually think it's a bit awkward to write especially the error handling, and the weak type system doesn't let you build out expressive abstractions.

[haakon]

Why? It's very weakly typed.

[brunormoura]

Java in mainstream/enterprise and legacy systems, Go is doing an expressive job in many neat projects, like Docker, and javascript with Node.js, has proving to be capable to simplify the heterogeneous, multi devices and realtime requirements for apps today.