Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Like Java (2014)

blog.plover.com

Post reply on HN
Print view View original

31–40 of 152 posts

Re: Why I Like Java (2014)

#31

Post by the_af »

CraneWorm wrote: post #17

> Different languages have different failure modes. With Perl, the project might fail because you designed and implemented a pile of shit, but there is a clever workaround for any problem, so you might be able to keep it going long enough to hand it off to someone else, and then when it fails it will be their fault, not yours. With Haskell someone probably should have been fired in the first month for choosing to do…

The author makes it really hard to judge his tone, but I don't think you're reading it right. For example, if you peruse his other articles, it's clear he really likes Haskell (he certainly doesn't consider it evil).

I can't say I understand every one of his assertions, and trying to be funny/sarcastic makes it hard to truly understand the point of his article, which I think is: Java lacks focus and is a verbose language, and therefore you should probably pick something else to solve interview challenges. I tend to agree.

Re: Why I Like Java (2014)

#32

Post by StevePerkins »

jordanpg wrote: post #2

> write a program that copies standard input to standard output This is pretty trivial in Java, just as in other languages. But most people don't ever need to learn the low level `System` methods needed to do it. To me, this highlights the difference between a comprehensive approach to learning a language and a more piecemeal one. I learned Java by reading the canonical books from cover to cover, like Effective Java.…

"protected" should be obvious, if you've worked on any non-trivial Java codebase. However, I've been working with Java for over 20 years now, and don't think I have ever actually used "volatile" once. The only reason I know anything about it is because I read "Java Concurrency in Practice" once upon a time, and have a really good memory.

In my experience with concurrent code in the business world, it's more common to enforce immutability rather than try to manage state updates. On the RARE occasions to the contrary (e.g. a "tripwire" flag of some kind?), accuracy is more important that maximum performance, so you would use an atomic class or something synchronized.

Really, I think this example more than anything else just shows that technical interviewing is a speed-dating crapshoot. You just have to interview at enough places to find an opportunity you're excited about, and where you happened to not stumble across any interviewer's personal bugaboos that don't match up with you.

Re: Why I Like Java (2014)

#33

Post by sirwhinesalot »

CraneWorm wrote: post #17

> Different languages have different failure modes. With Perl, the project might fail because you designed and implemented a pile of shit, but there is a clever workaround for any problem, so you might be able to keep it going long enough to hand it off to someone else, and then when it fails it will be their fault, not yours. With Haskell someone probably should have been fired in the first month for choosing to do…

I think you misunderstood his post...

Re: Why I Like Java (2014)

#34

Post by nicoburns »

da39a3ee wrote: post #22

I’ve recently joined a company using Java. I’m open minded, and know that there are lots of good things about the JVM and the modern Java language. However one thing I hate is the complete disregard for command line UX. People writing Java command line tools seem to think it’s absolutely fine to spew 1000 lines of unformatted informational messages and non actionable warnings with bizarre indentation and not to provi…

> It’s like they just view the terminal as some sort of obscure log file that no-one’s likely to look at.

From what I’ve seen of Java developers it’s more likely that they see it as an IDE pane that has filtering capabilities built in.

Re: Why I Like Java (2014)

#35

Post by gmueckl »

zozbot234 wrote: post #8
ysleepy wrote: post #5

Yeah, keep writing perl and spout cynicism about everything. I feel like they are chasing a aesthetic of conciseness, their perfect little haskell program, not recognizing that regularity and good api design are much more important. What is beautiful for a 100loc program becomes ugly and wrong for a 100kloc program. Other aspects become much more important. I'm not a huge fan of go, but it proved there is a necessity…

The notion that languages focused on writing large-scale programs must be "boring" seems a bit silly. What these languages need is lots of ways to define sensible modularity boundaries, and the "boring" aesthetic (or lack thereof, rather) can really get in the way of that.

TL/DR: it's about readability and clarity of unfamiliar code.

One problem of large codebases is that they tend to be team efforts. Given a a sufficiently large and flexible language, each team member will find their own style and idioms for their code. This creates the subtle problem that team members are unfamiliar with each other's styles and when they touch the same pieces of code, they each extend the subset of used language features by whatever is required for their favorite idioms. Eventually, the resulting code gets too elaborate for its own good and maintainability goes down. A boring, simplified language ideally constrains the team to use more or less the same patterns and idioms and this side-steps the problem.

Re: Why I Like Java (2014)

#36

Post by nicoburns »

zozbot234 wrote: post #10
pie_flavor wrote: post #4

Earlier quoted context omitted.

Volatile is specifically C's thread safety. AtomicInteger and ReentrantLock (aka mutex) are what a thread safe person should know.

volatile has nothing to do with thread safety or the memory model in modern C. It's strictly for access to memory-mapped resources, where common assumptions relied-on by optimizers may fail. It should never be used for multithreading, use proper atomics and other provided facilities instead.

Correct, but it’s worth noting that ‘volatile’ in Java does provide atomicity.

Re: Why I Like Java (2014)

#37

Post by mindcrime »

kingkongjaffa wrote: post #12
smoyer wrote: post #11

You can write a pretty trivial Java program to copy stdin to stdout but Java is still one of the enterprise languages and people writing enterprise applications don't tend to write this type of software (but they do tend to have log4j vulnerabilities). The strengths of Java are its mature dependency management system(s), its comprehensive standard library and the vast ecosystem of third-party libraries. A better test…

People say this but where do you find libs for Java? Python has pip, JS/Node has NPM

In Java-land most people build and do dependency management with Maven or Gradle. In either case, these tools can pull from repositories based on the Maven format. The vast majority of popular libraries are in repo "Maven Central" and "just work" if added to your dependency list. A number of smaller, more specialized repos also exist, and it's trivial to add additional repos to your Maven/Gradle config as well.

You can search for libraries on mvnrepository.com, or your IDE can search the index. Also most libraries will include a section in the documentation that shows the details of the blob you have to put in your pom.xml / build.gradle file.

Re: Why I Like Java (2014)

#38

Post by [deleted] »

pie_flavor wrote: post #4
MrBuddyCasino wrote: post #3

Earlier quoted context omitted.

Maybe thats the difference between "having mastered something" and "doing something a long time"? I cannot imagine an experienced Java programmer that doesn't know what "protected" means, its use is fundamental and pervasive. As for "volatile", idk - not knowing it hints at that person not having a concept of thread-safety. I'd expect someone who claims to be a senior to maybe not give me the memory model implication…

Volatile is specifically C's thread safety. AtomicInteger and ReentrantLock (aka mutex) are what a thread safe person should know.

[deleted]

Re: Why I Like Java (2014)

#39

Post by mi_lk »

smrtinsert wrote: post #28
mi_lk wrote: post #7

tangent: what are some modern java OSS codebases that you would recommend to read?

What do you want to do?

Want to pick up some modern Java(11+?) best practices in general since my knowledge is mostly stuck in Java 7/8. Would appreciate recs on codebases, books, talks, etc.

Re: Why I Like Java (2014)

#40

Post by nanis »

CraneWorm wrote: post #17

> Different languages have different failure modes. With Perl, the project might fail because you designed and implemented a pile of shit, but there is a clever workaround for any problem, so you might be able to keep it going long enough to hand it off to someone else, and then when it fails it will be their fault, not yours. With Haskell someone probably should have been fired in the first month for choosing to do…

The author is MJD. He is, among other things, the author of one of the best functional programming books[1].

> I was a professional Java programmer for three years (in a different organization), and I have meant for some time to write up my thoughts about it. I am often very bitter and sarcastic, and I willingly admit that I am relentlessly negative and disagreeable, so it can be hard to tell when I am in earnest about liking something. I once tried to write a complimentary article about Blosxom, which has generated my blog since 2006, and I completely failed; people thought I was being critical, and I had to write a followup article to clarify, and people still thought I was dissing Blosxom. Because this article about Java might be confused with sarcastic criticism, I must state clearly that everything in this article about Java is in earnest, and should be taken at face value. Including:

> I really like Java

> ...

> So yes, I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product. It was pleasant to not have to worry about whether I was doing a good job, or whether I might be writing something hard to understand or to maintain. The code was ridiculously verbose, of course, but that was not my fault. It was all out of my hands.

[1]: https://hop.perl.plover.com/

Post reply on HN