Live data from Hacker News

Why and how I write Java

stevewedig.com

41–50 of 67 posts

Re: Why and how I write Java

#41

A little surprised Spring is not mentioned. Composition in Java is a nightmare without Spring, and you can do some really interesting things in configuration that would take you days of writing initialization code in very little time. If not for Spring, I'm not sure I would want to construct things in Java at all.

Because he doesn't use Spring, he uses GWT.

Re: Why and how I write Java

#42

I think one thing that this post touches on is the effectiveness of Java as a programming language for large projects. Although personally I've moved on to Python since it greatly simplifies web-related tasks, a lot of our legacy projects are in Java and I still hear plenty of people sipping the Java haterade. So I thought I'd share some of the most common things I hear. Only my grandpa writes in Java anymore. I hire…

I wish folks would stop writing Java dev tools in Java. Maven would be 2X faster, eclipse wouldnt pause 2 seconds after every context menu is requested.

I find that the Java community seems fine with this, but wehen you have been doing this stuff for decades, Eclipse slowing me down on nearly every click and keystroke is NOT ok.

Im fine with Java, I just dont want to use Java to make java apps anymore.

Re: Why and how I write Java

#43

Having been exposed to OCaml, I'm starting to think that if you have null references, you don't really have static typing. I guess I'll have to look at guava, but it can only help so much in interacting with other code.

As a rubyist by day this is the thing I find so exciting about Haskell. I write dynamically-typed code all day, and the most common bugs are not because of passing an Apple to an Orange interface—that just isn't very common—it's because of cascading nulls. Of course Java's static checks are worth something , but not much more than the most cursory of checks that my basic test coverage does in Ruby.

My takeaway from looking into OCaml was that pattern-matching with exhaustiveness checking was the jewel, as contrasted with primitive C-style if/else chaining or switches.

Re: Why and how I write Java

#44

I think one thing that this post touches on is the effectiveness of Java as a programming language for large projects. Although personally I've moved on to Python since it greatly simplifies web-related tasks, a lot of our legacy projects are in Java and I still hear plenty of people sipping the Java haterade. So I thought I'd share some of the most common things I hear. Only my grandpa writes in Java anymore. I hire…

I wish folks would stop writing Java dev tools in Java. Maven would be 2X faster, eclipse wouldnt pause 2 seconds after every context menu is requested. I find that the Java community seems fine with this, but wehen you have been doing this stuff for decades, Eclipse slowing me down on nearly every click and keystroke is NOT ok. Im fine with Java, I just dont want to use Java to make java apps anymore.

Intellij is written in Java, and it runs fine. The set of all Java applications is not comprised solely of Eclipse.

Re: Why and how I write Java

#45
post #15

> With Java I have one language that can target servers, Android, and browsers via Google Web Toolkit (GWT). Credibility shot. He's a fan of GWT. That explains a lot.

I really like GWT. I will be writing some posts that will go into more detail.

I gave up on GWT ~3 years ago, so some of this might have changed since then, but here is my list of things that annoyed me:

* Compilation speed. Even when I dug into the compiler to increase parallelization, it was still dog slow. Yes, running in hosted mode helps, but compiles were still frequent enough that we'd have coffee breaks simply to wait for the compiler to finish.

* Testing. GWTTestCase never worked right for me. And tests that don't run in pure Java are, again, slow. We got around it by writing a Java agent to transform the bytecode at classload time to intercept all of GWT's native methods, but this was a huge PITA.

* Doesn't play well with others. The way that GWT loads makes it difficult to use on concert with other front-end frameworks/technology.

* The inability to embed structured data in the page. The serialization in GWT's RPC is fantastic. Embedding type-unsafe JSON for reference data in a page seemed wrong. But GWT didn't give any supported way to serialize and deserialize outside of an RPC call. We eventually figured it out, but the solution involved having to sometimes include unused code in a RemoteService to ensure that the deserialization code was compiled in, which always felt hackish).

Still, for what it was, GWT was always impressive. It's performance always beat what we were able to achieve with hand-coded JavaScript. Chrome has somewhat lessened the need to write high-performance JavaScript, but it's still impressive that GWT's generated code was that fast. And I've yet to encounter another RTE that was as easy to use and "just worked" as well as GWT's RTE. Every time I'm asked to do something with CKEditor or any of the native JavaScript options, I always wish that it was possible to use GWT's editor outside of a GWT application.

Re: Why and how I write Java

#46

Having been exposed to OCaml, I'm starting to think that if you have null references, you don't really have static typing. I guess I'll have to look at guava, but it can only help so much in interacting with other code.

As a rubyist by day this is the thing I find so exciting about Haskell. I write dynamically-typed code all day, and the most common bugs are not because of passing an Apple to an Orange interface—that just isn't very common—it's because of cascading nulls. Of course Java's static checks are worth something , but not much more than the most cursory of checks that my basic test coverage does in Ruby.

Ruby could really use optional typing, like what PHP and Clojure have.

Re: Why and how I write Java

#47

I think one thing that this post touches on is the effectiveness of Java as a programming language for large projects. Although personally I've moved on to Python since it greatly simplifies web-related tasks, a lot of our legacy projects are in Java and I still hear plenty of people sipping the Java haterade. So I thought I'd share some of the most common things I hear. Only my grandpa writes in Java anymore. I hire…

I think one thing that this post touches on is the effectiveness of Java as a programming language for large projects.

I agree that Java has its uses, but I've always thought that this was one of the weaker ones. Java's poor syntactical support for clarifying abstractions like lambdas or rich data structures like hashmaps makes small projects larger than they need to be. The answer isn't to find a way to manage large projects; it's to find a way to make them smaller. Size is poison, and automated refactoring is no cure.

Re: Why and how I write Java

#48

Do you use a framework for routing and handling HTTP requests, or just servlets? What about accessing the database, if any? I assume you're not using Java EE. EDIT: For iOS, http://j2objc.org/ can help you share code between platforms, but you'll still do the UI and other platform-specific things in ObjC.

If you're looking for a small and simple HTTP framework in Java, I've been working on one that I think is really nice (you might think the exact opposite): https://github.com/dkuntz2/java-httpserver

Re: Why and how I write Java

#49
post #35
post #30

For me, this was the most amazing thing about this post: "Programming with explicit memory management: This bucket includes C, C++, Rust, D, etc. I haven’t needed to explicitly manage memory, so I haven’t used these." I guess I'm just old.

Maybe I am too, but that phrase just bugged me. Surely there are other reasons to use these tools than just "explicit memory management?" I suppose I could say, "I haven't used any JVM languages, because I haven't felt the need to gouge my eyes out over memory errors I can't control."

> Surely there are other reasons to use these tools than just "explicit memory management?"

Sure, though he does mention he's biased by the projects he works on (generally web apps/services -- not device drivers, image processing, realtime anything, etc.).

> I suppose I could say, "I haven't used any JVM languages, because I haven't felt the need to gouge my eyes out over memory errors I can't control."

The phrase that bugged you wasn't cast as an insult, though, and yours is... mysterious; Java's GC is quite stable, so any memory-related errors are under the coder's control. "Memory errors" being basically just "using too much memory", as I've never seen any other type of memory error in Java.

Maybe you could say "I haven't used any JVM languages, because I've never felt the need for automated memory management"? That assumes Java has nothing else to offer.

Re: Why and how I write Java

#50
post #43

Earlier quoted context omitted.

As a rubyist by day this is the thing I find so exciting about Haskell. I write dynamically-typed code all day, and the most common bugs are not because of passing an Apple to an Orange interface—that just isn't very common—it's because of cascading nulls. Of course Java's static checks are worth something , but not much more than the most cursory of checks that my basic test coverage does in Ruby.

My takeaway from looking into OCaml was that pattern-matching with exhaustiveness checking was the jewel, as contrasted with primitive C-style if/else chaining or switches.

Right, exhaustiveness checking is how the compiler makes sure you handle missing values (option types) correctly. I guess you could say that's one of the bigger payoffs.
Post reply on HN