I wish there was something like this for all languages. I know Java, but there are often occasions when something isn't working that I didn't write and don't have a clue about how to fix, but just need the basics to get started, and I can probably work it out by myself (e.g. our Wordpress site when the other two guys with experience in PHP leave).
Programing syntax isn't usually the difficult part once you know two or three languages.
> Java - the programming language that most seem to despise with great passion.
Is that really true though? Anecdotally it seems lots of big firms are using Java8 even more often, as sidetracks to Go/Scala/C++* seem to be coming back.
Big firms like to use it, but most developers who work there probably don't; they just suck it up and do it for the paycheck. Source: am a developer at a big firm being forced to use Java.
For what it's worth, I'm in the process of converting one of our components from JavaScript to Java because it is incredibly fragile, difficult to modify, and everyone hates working with it. Not everyone is forced to use Java.
I really like Java actually, although we do make use of things like Lombok pretty heavily to reduce the boilerplate, enforce using inheritance very sparsely, and use immutable value types wherever possible (although sadly this is the part that gets ignored most often) - doing those things greatly improves the experience of using Java.
This is great. I've always envisioned something like "Java for Node developers", having learned Java coming from Node, with great reward and enjoyment. Java is a great and powerful ecosystem and even a fun language when not written in the absurd 2000s "enterprise" style.
I keep wanting to like Java, but they insist on everything being done the hard way compared to C#.
Sure, you want to provide a bunch of different readers, and let people put them together however you want.
But compare the example there of using a BufferedReader in a loop to read in a file, and compare to the equivalent in C# - File.ReadLines (which gives you an IEnumerable<string>) or even File.ReadAllLines (which gives you a string[]). 99% of the time that's all you want, and yet Java makes you do the work yourself rather than just giving you a utility method.
There is a utility method `Files.readAllLines` [1] (even since Java 7) which gives you a List<String>. Since Java 8 there is even a lazy variant `Files.lines()` [2], which returns a Stream<String>. Though you gotta be a bit careful with that last one and be sure to close the underlying reader, as mentioned in the docs.
I don't know Java gets such a bad rap from the current generation. If I had my way (which I rarely do) I'd start any new server-side project on Java with Spring Boot. Everything about the stack is so fine-tuned and battle-tested. There's libs for everything under the sun. I can follow every stack trace even in a multi-threaded environment. Debuggers are extremely dependable. The IDEs are top notch. I know it's verbose and I prefer it that way. You spend more time reading code than writing and I'd rather see it all spelled out than encoded in punctuation marks. Otherwise, I'd go back to Perl.
You can get a running webapp within minutes. The caution is, you would have limited information on what's going on in the background. Great for those who already know Spring and its inner workings because it's convenient - but could be detrimental on a beginner if you don't take the effort later to learn the inner workings.
I was very enthusiastic about Java from 1995 to about 2000 or so - then it seemed to become dominated by an "enterprise" outlook and rampant over-abstractionism.
Java is permanently associated in my mind with hammer factories:
I used to work on this treadmill, it sucked I agree.
Nowadays I still write Java, but it's much more pleasant, all deployed to the cloud, no messing around with application containers and all the Java EE stuff.
It's nice, it works, it's simple. Granted, I'm fortunate enough to not have to maintain legacy Java applications so my perspective has been skewed somewhat, but I think it's worth mentioning that "modern Java" has moved a long way from what it used to be.
See, you got off the train at peak abstraction crazy. I don't blame you for the association given what you saw then, but there's no reason that you have to write Java that way, and most people don't anymore.
Just forget that EJB, Websphere, Weblogic, JTA, CORBA, and a few other things ever existed, and having a positive feeling about Java should cause little cognitive dissonance.
I was too young to see the EJB fad and when people made all of these decisions to use things like WebSphere. Did they make any sense in their own time? Today they seem remarkably silly. Especially WebSphere, which is so horribly slow and broken I don't understand why anyone would have chosen to use it besides "nobody got fired for choosing IBM."
Well people still choose bloated and horribly slow text editors and claim they are amazing because zillions of plugins and customizations are available.
Websphere was similarly popular because it could integrate with 100s of frameworks that developers/enterprises might be using in their applications.
So it still makes sense in same way when now people claim web apps/wrappers are solution to all client side software and if it feels bloated and slow, tough luck, "Why don't you upgrade to some over-spec'd machines?"
Hard to say... it was a comparatively darker time for information availability. Other odd, awkward, over-puffed products like ATG Dyanmo, Plumtree, Interwoven, etc., were killing it in the market too.
I was really green in enterprise software then, and Websphere's suggestion of useful clustering, configuration management, managed pooling, etc., seemed tantalizing. (Look how long it takes to start up--it must be doing useful and complicated stuff!) That said, it didn't take all that long for Tomcat, JBoss, and others to eat its lunch on projects not rolling along on enormous sunk costs into IBM tech.
I never actually dug into EJBs or wacky things like container-managed Javamail. Some colleagues did. They spent a lot of time struggling with the tooling.
And now I'm just remembering VisualAge for Java. /shudder/
No. I mean, there are still people in the industry today who think Java EE is the greatest, but I recall it making no sense the first time I saw it. The Java app server space was fractious at the time and I spent a lot of time with ATG Dynamo which was proprietary but had a fantastic design for the time and was very innovative. J2EE felt like a big step back. It got some adoption from IT architects who only know how to follow trends, but most of us just spent some time in the wilderness until Spring came along to rescue us.
I think not much has changed since then in terms of usability. I use Java at work daily and most programmers suffers from same thoughts as it was decades back. It is always writing frameworks and not straightforward code for requirements at hand. They believe it is their moral responsibility to write abstract solutions framework for problems of future programmers.
EJB and XML may be little old and unfashionable but in its place Spring-Everything* is there. And now Spring annotation turdlets are sprinkled all over the newly fangled Cloud Microservices in Java.
I don't think I'd start "any" server-side project with Java; I think it's a question of whether you really want the JVM or not. The JVM is awesome but smaller projects might find it too heavy for their use/deployment case.
But yeah, Java is great. Definitely seems underrated in the popularity department.
Oh, that looks nice, but I was speaking less about the language and more about the JVM itself.
I mean, if you're in that small scale range where you're running project off of a small server or VPS that may not have that much RAM to play with, the JVM I think starts to make less sense. You don't need the super-scaling performance of the JVM because you won’t have the load, and the RAM that would be spent on the JVM heap is better spent in that case on other things (e.g. database caching, if you are so small and cheap that your DB runs on the same machine as the http/app server).
Java using a large amount of ram is a myth. Let me explain the difference between JVM and other GC'ed languages that makes this appear to be the case.
So almost all "web" languages use garbage collection. This reason Java appears to use more ram is, paradoxically because it has a better garbage collector.
The best time to do garbage collection is never. Even if you do it concurrently it uses CPU time. Java is very good about avoiding collecting garbage until the heap is huge. Other languages (by default) use less ram because they run garbage collection a lot more often.
So why do they run GC so much more other than Java? Because their garbage collectors are slower and not as concurrent. Almost all garbage collectors pause execution and even the ones that don't still affect performance. You don't want pauses more than some tens of milliseconds really ever.
Garbage collection time depends on how much garbage you have, so languages with inferior collectors need to keep the heap small to avoid long collection times. Since Java's GC is so fast the heap can be allowed to build to many gigabytes before garbage collection times are an issue.
Turning down the heap size will make Java GC more often and behave more like other languages. Compared to dynamic languages Java itself is very memory efficient. It's just the longer GC interval that makes this appear otherwise.
I don’t know about C#, but the JVM usually has steeper recommended memory requirements than Python or other scripting languages.
It may not be a fair rap, but you can see where it comes from if you imagine that lots of people had their introduction to webapps in the form of LAMP shared hosting stacks.
I'm working with both right now getting some API's up and running. Even if Java has moved away from the crazy levels of abstraction years ago, golang is still years ahead.
In my brief recent return to Java, it still doesn't seem to reach out to the programmer to make the common case easy.
IDEA is phenomenal. Netbeans is just OK, and Eclipse was awful all the times I tried it. Bloated UI, slow startup, and difficult to configure. Maybe things have changed since I've used it, but at the time, it was agonizing.
The current version of Eclipse is quite fast even when dealing with large code bases.
Configuration is easy; there are a zillion options under preferences but the search filter makes it easy to find what you need.
Startup times are irrelevant. Start the IDE once when you boot the OS and leave it running. It consumes minimal system resources just sitting there until you need it.
100% agree. I don't buy the verbosity argument one bit. Yes it's more verbose than a dynamically typed language but it's not like you get nothing in return for that verbosity. When working with serious, mission-critical code, the verbosity (and accompanying clarity) is a godsend.
The only part of writing/maintaining code that I've found easier/more pleasant with dynamically typed languages is writing unit tests (due to the fact that mocking an object is as simple as just declaring a hash literal or JSON object). On the other hand, I find that I need to write extra unit tests to verify integrity that would be be verified at compile time in a strongly typed language like Java.
I would strongly recommend people check out DropWizard. It's an opinionated framework for writing Java servers that comes with a handpicked stack. It has many of the convention driven advantages of e.g. Rails but fundamentally you're still writing code in Java (or another JVM language like Kotlin).
> I find that I need to write extra unit tests to verify integrity that would be be verified at compile time in a strongly typed language like Java.
This is so true and I'm surprised I don't see it mentioned more often.
Sure, mocking stuff is way easier in JavaScript, but you end up writing tons of tests to prevent the kind of regressions a smart IDE would be screaming about in a strongly typed language.
I'd go further and say the techniques that trade-off clarity for making unit tests easier to write (e.g. dependency injection) are often a bad idea. We shouldn't let the tail wag the dog.
For beginners (who this micro-guide is aimed at), a big part of it is that the activation energy is pretty high - there are lots of things to know and there are many ways to do things. Finding recent and accurate information is harder - there's 20-odd years worth of it out there. Even in this write-up, there's some questionable advice - the beginner answer to 'writing a clientside UI in Java' is 'don't use Java'.
This is normal for any mature, widely used technology - Rails comes to mind as a smaller variant of the same problem. It's a lot easier to try out go or node - there's less stuff.
The example also shows how ridiculous many syntax highlighting schemes are. So much emphasis is put on boilerplate; the identifiers (which I'm usually looking for in code) almost fade into background.
Personally, I quite like Java. Or, I'd put it somewhere in the category of 'good/proper languages'. Although I view C# as a straightforward upgrade. But hey, it's pretty often I have to work in PHP or R or JavaScript. A few months of that and I'll beg for a chance to work in Java with its sensible collections, its mostly-not-broken type system, and its integers.
However, I do think a lot of the library ecosystem that goes with Java it pretty poor, and I don't think I could ever work with Spring again.
This gist of Java frameworks for me is that they miss the essential problems and important uses and instead construct a massive tower of nonsense around the trivialities.
(I am, however, quite happy with Guava and Joda Time, and if I thought that dependency injection frameworks were useful then Guice is certainly superior to Spring.)
So here's my anecdote illustrating the dark side of Java.
Once upon a time, I needed to parse a CSV with a header row. The project I was working in used Spring, so I decided to try the Spring library. Configuring it to fetch the bean, put it in the right place, and set the header row switch to true took slightly more lines of XML than the lines of code you'd need to write a CSV parser from scratch, but hey at least I didn't need to think about quoting.
After a year or so, we are updating to a newer version of Spring. They have removed the header-row switch from their CSV parser, and replaced it with some sort of general parser extension abstraction. To parse a CSV with a header, I now have to write a class implementing their parser interface, register it with Spring, then write another 10 lines or so of hideous XML to slot it into the right place.
"Properly commenting code is so often overlooked when developing software and it is a damn shame".
I'd change that to, "commenting code that is self-explanatory is so often overused when developing software and it is a damn shame"
In the very same article, there's a function with the following JavaDoc description "A simple add implementation that performs addition on two integer values". Nothing I can't get from actually "knowing how to read code".
67 comments
[ 3.0 ms ] story [ 147 ms ] threadPrograming syntax isn't usually the difficult part once you know two or three languages.
Is that really true though? Anecdotally it seems lots of big firms are using Java8 even more often, as sidetracks to Go/Scala/C++* seem to be coming back.
I really like Java actually, although we do make use of things like Lombok pretty heavily to reduce the boilerplate, enforce using inheritance very sparsely, and use immutable value types wherever possible (although sadly this is the part that gets ignored most often) - doing those things greatly improves the experience of using Java.
http://robovm.mobidevelop.com/
https://software.intel.com/en-us/multi-os-engine
http://gluonhq.com/products/mobile/
https://www.codenameone.com/
> Is that really true though?
one data point: yes
Sure, you want to provide a bunch of different readers, and let people put them together however you want.
But compare the example there of using a BufferedReader in a loop to read in a file, and compare to the equivalent in C# - File.ReadLines (which gives you an IEnumerable<string>) or even File.ReadAllLines (which gives you a string[]). 99% of the time that's all you want, and yet Java makes you do the work yourself rather than just giving you a utility method.
I get your sentiment though.
[1]: https://docs.oracle.com/javase/7/docs/api/java/nio/file/File... [2]: https://docs.oracle.com/javase/8/docs/api/java/nio/file/File...
https://projects.spring.io/spring-boot/
You can get a running webapp within minutes. The caution is, you would have limited information on what's going on in the background. Great for those who already know Spring and its inner workings because it's convenient - but could be detrimental on a beginner if you don't take the effort later to learn the inner workings.
Thanks.
https://www.udacity.com/course/java-programming-basics--ud28...
Java is permanently associated in my mind with hammer factories:
http://discuss.joelonsoftware.com/default.asp?joel.3.219431....
Nowadays I still write Java, but it's much more pleasant, all deployed to the cloud, no messing around with application containers and all the Java EE stuff.
It's nice, it works, it's simple. Granted, I'm fortunate enough to not have to maintain legacy Java applications so my perspective has been skewed somewhat, but I think it's worth mentioning that "modern Java" has moved a long way from what it used to be.
Websphere was similarly popular because it could integrate with 100s of frameworks that developers/enterprises might be using in their applications.
So it still makes sense in same way when now people claim web apps/wrappers are solution to all client side software and if it feels bloated and slow, tough luck, "Why don't you upgrade to some over-spec'd machines?"
I was really green in enterprise software then, and Websphere's suggestion of useful clustering, configuration management, managed pooling, etc., seemed tantalizing. (Look how long it takes to start up--it must be doing useful and complicated stuff!) That said, it didn't take all that long for Tomcat, JBoss, and others to eat its lunch on projects not rolling along on enormous sunk costs into IBM tech.
I never actually dug into EJBs or wacky things like container-managed Javamail. Some colleagues did. They spent a lot of time struggling with the tooling.
And now I'm just remembering VisualAge for Java. /shudder/
EJB and XML may be little old and unfashionable but in its place Spring-Everything* is there. And now Spring annotation turdlets are sprinkled all over the newly fangled Cloud Microservices in Java.
But yeah, Java is great. Definitely seems underrated in the popularity department.
http://sparkjava.com/
It just works, if a little unfortunately named, but you can get a nice little application up and running quite quickly.
I mean, if you're in that small scale range where you're running project off of a small server or VPS that may not have that much RAM to play with, the JVM I think starts to make less sense. You don't need the super-scaling performance of the JVM because you won’t have the load, and the RAM that would be spent on the JVM heap is better spent in that case on other things (e.g. database caching, if you are so small and cheap that your DB runs on the same machine as the http/app server).
So almost all "web" languages use garbage collection. This reason Java appears to use more ram is, paradoxically because it has a better garbage collector.
The best time to do garbage collection is never. Even if you do it concurrently it uses CPU time. Java is very good about avoiding collecting garbage until the heap is huge. Other languages (by default) use less ram because they run garbage collection a lot more often.
So why do they run GC so much more other than Java? Because their garbage collectors are slower and not as concurrent. Almost all garbage collectors pause execution and even the ones that don't still affect performance. You don't want pauses more than some tens of milliseconds really ever.
Garbage collection time depends on how much garbage you have, so languages with inferior collectors need to keep the heap small to avoid long collection times. Since Java's GC is so fast the heap can be allowed to build to many gigabytes before garbage collection times are an issue.
Turning down the heap size will make Java GC more often and behave more like other languages. Compared to dynamic languages Java itself is very memory efficient. It's just the longer GC interval that makes this appear otherwise.
The only popular languages that don't need a runtime installed are c/c++ and golang.
It may not be a fair rap, but you can see where it comes from if you imagine that lots of people had their introduction to webapps in the form of LAMP shared hosting stacks.
In my brief recent return to Java, it still doesn't seem to reach out to the programmer to make the common case easy.
You mean like using go generate instead of proper generics?
IDEA is phenomenal. Netbeans is just OK, and Eclipse was awful all the times I tried it. Bloated UI, slow startup, and difficult to configure. Maybe things have changed since I've used it, but at the time, it was agonizing.
Configuration is easy; there are a zillion options under preferences but the search filter makes it easy to find what you need.
Startup times are irrelevant. Start the IDE once when you boot the OS and leave it running. It consumes minimal system resources just sitting there until you need it.
The only part of writing/maintaining code that I've found easier/more pleasant with dynamically typed languages is writing unit tests (due to the fact that mocking an object is as simple as just declaring a hash literal or JSON object). On the other hand, I find that I need to write extra unit tests to verify integrity that would be be verified at compile time in a strongly typed language like Java.
I would strongly recommend people check out DropWizard. It's an opinionated framework for writing Java servers that comes with a handpicked stack. It has many of the convention driven advantages of e.g. Rails but fundamentally you're still writing code in Java (or another JVM language like Kotlin).
This is so true and I'm surprised I don't see it mentioned more often.
Sure, mocking stuff is way easier in JavaScript, but you end up writing tons of tests to prevent the kind of regressions a smart IDE would be screaming about in a strongly typed language.
This is normal for any mature, widely used technology - Rails comes to mind as a smaller variant of the same problem. It's a lot easier to try out go or node - there's less stuff.
Im convinced that most of the people who dislike Java are either riding the hype train or inexperienced with the pitfalls of various languages.
The whole startup culture is biased against Java which is ironic because many tech titans use it as their main language.
For example:
https://www.zeroequalsfalse.press/2017/06/22/java/output.png
- The author and date are redundant, these are typically stored in source control
- The program itself should already be a class, specifying a containing class and function shouldn't be necessary.
- Public (or private) should be default.
- Make returning void a default, and stop asking developers to unnecessarily define it.
- 'System' is a vague word with many possibilities. It can man: OS kernel, services, OS, VM, stdlib, and many others.
The entire example except 'print("hello")' is wasted tokens and noise.
Package private is a reasonable choice for the default access modifier. Changing the default to be public or private wouldn't improve the language.
Ack, but it's a strange culture that does so.
So you can omit 'public' or 'private' as keywords and the function / method will be package-private?
However, I do think a lot of the library ecosystem that goes with Java it pretty poor, and I don't think I could ever work with Spring again.
This gist of Java frameworks for me is that they miss the essential problems and important uses and instead construct a massive tower of nonsense around the trivialities.
(I am, however, quite happy with Guava and Joda Time, and if I thought that dependency injection frameworks were useful then Guice is certainly superior to Spring.)
So here's my anecdote illustrating the dark side of Java.
Once upon a time, I needed to parse a CSV with a header row. The project I was working in used Spring, so I decided to try the Spring library. Configuring it to fetch the bean, put it in the right place, and set the header row switch to true took slightly more lines of XML than the lines of code you'd need to write a CSV parser from scratch, but hey at least I didn't need to think about quoting.
After a year or so, we are updating to a newer version of Spring. They have removed the header-row switch from their CSV parser, and replaced it with some sort of general parser extension abstraction. To parse a CSV with a header, I now have to write a class implementing their parser interface, register it with Spring, then write another 10 lines or so of hideous XML to slot it into the right place.
Just...what the hell?
Bean Validation can piss off too.
I'd change that to, "commenting code that is self-explanatory is so often overused when developing software and it is a damn shame"
In the very same article, there's a function with the following JavaDoc description "A simple add implementation that performs addition on two integer values". Nothing I can't get from actually "knowing how to read code".