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.
Why and how I write Java
41–50 of 67 posts
Re: Why and how I write Java
#42I 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 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
#43Having 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.
Re: Why and how I write Java
#44I 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
#45> 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.
* 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
#46Having 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.
Re: Why and how I write Java
#47I 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 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
#48Do 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.
Re: Why and how I write Java
#49For 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."
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
#50Earlier 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.