Java Developers • Hacker News Board

Re: Java Developers

#201

Post by michaelochurch » Tue, Jul 22, 2014, 2:48 PM UTC

One problem with Java is the 15+ years of bad taste. Design patterns are "revenge of the not-nerds". It's "I don't know what a monad is and don't care to learn, but I'm going to make you feel the way I do when I see math by renaming the sine function to VibratorVisitorFactory."

Moreover, Big Software is generally a bad idea. There are occasions where large programs are a good idea, but the default should be small, composable units. Scripting and batch jobs aren't "baby coding". They should be the default unless you need a long-running server process. Most programs (over 90%) should be doing one thing and doing it well. The problem is that people don't code this way because it's better for enterprise managers' and architects' careers to say they oversaw gigantic, overarching software projects.

I've actually noticed that data scientists, while their line-by-line coding skills aren't as good as a professional software engineer's, are usually much better designers (and far better communicators) than Java engineers. Sure, R is janky and Python has ugly corner cases, but data scientists write programs to do specific tasks and generally are good at keeping code small (because they have a personal responsibility for the code-- if they can't read it, it's basically lost-- not experienced by "architects" who can hire maintenance engineers to clean up their messes). You don't see the enterprise "software for software's sake" problem.

The result of Big Software tends to be Java Shop Politics, as described here: http://michaelochurch.wordpress.com/2012/04/13/java-shop-pol... . It's not the fault of Java. It's just a bad way of writing software.

Re: Java Developers

#202

Post by djulius » Tue, Jul 22, 2014, 2:50 PM UTC

ffriend wrote: post #117

seanmcdirmid wrote: post #15

> The OO craze has a part to play in this madness as well. More and more developers are stepping back and realising that as a programming paradigm, OO is actually pretty shit. Once real systems (like UI frameworks) are written with FP, we can compare apples to apples. Until then...wtf? OO actually works well for scaling complexity, much better than toy immutable functions do. > Even today you’ll still find a strong b…

> Once real systems (like UI frameworks) are written with FP, we can compare apples to apples. Until then...wtf? OO actually works well for scaling complexity, much better than toy immutable functions do. Seems like we are working on very different kinds of systems. Right now I'm working on Hadoop-based data pipeline. While Hadoop itself is mostly written in Java, many recent tools like Spark or Kafka are created in…

For scientific computation, libraries such as JAMA or la4j performs much faster than scipy on matrix operations or common linear algebra operations : http://martin-thoma.com/matrix-multiplication-python-java-cp... https://code.google.com/p/java-matrix-benchmark/wiki/Runtime...

Re: Java Developers

#203

Post by revscat » Tue, Jul 22, 2014, 2:51 PM UTC

pjmlp wrote: post #75

Java is not the problem, enterprise architects are. If anything, Java allowed the so called architects a much easier path to such crazy skyscrapper designs than any enterprise language before it. So of course they went crazy with Java, and later on C#, because it was so easy to do so, without being caught in core dumps and similar issues. Anyone complaining about enterprise Java, just needs to go back a few decades t…

> I cannot agree more.

At this moment I have an interface open with the following signature:

     public interface ClientBenefitOrder extends Internationalizable, CBMEntity, Enableable, Deletable, Comparable, ClientOwned

This is entire application suffers from Enterprise Architechtitus, and like OP I have encountered that far too often for it to be a simple mistake. There is a cultural tendency in Java land towards overengineered solutions. It's pervasive. It also makes for bad code.

Re: Java Developers

#204

Post by jdennaho » Tue, Jul 22, 2014, 2:53 PM UTC

I've worked with java for 10 years now... I have seen some shit let me tell you.

Re: Java Developers

#205

Post by revscat » Tue, Jul 22, 2014, 2:55 PM UTC

hrjet wrote: post #122

dmacvicar wrote: post #65

Earlier quoted context omitted.

There are several examples of simple libraries in Java that makes you realize it is possible to provide solutions to problems without the "culture" that predominates the ecosystem. For example Simple ( http://simple.sourceforge.net ) is a great XML serialization framework that does very well what it is supposed to do. And there are others I haven't used, but you look at the API and think, this is what I want. I was v…

Just had a look at jDBI and it doesn't exactly look like a simple library to me. There's a lot of run-time annotation processing. Have a look at jOOQ if you haven't seen it yet. There is a pre-compilation stage which generates DAO for you and they can then be used with static type guarantees.

That pre-compilation step, though... How does that play with the IDE? I'm looking into various (more) modern ORM/DB-talky-to-things, and checked out jOOQ but was turned off by that pre-compilation step. I like having my errors bright and red when I type.

I also don't like code generation. I'm not closed-minded to it, just don't like it if I can avoid it.

Re: Java Developers

#206

Post by mike_hearn » Tue, Jul 22, 2014, 2:56 PM UTC

alexfarran wrote: post #128

mike_hearn wrote: post #83

Earlier quoted context omitted.

I worked at Google for a long time. The most problematic language at Google was (by far) Python. Mostly because tools that would start out as small Python scripts would evolve to become large Python codebases that ended up being unmaintainable. There were several examples of unmanageable Python codebases at Google that got rewritten in C++ or Java. I'm struggling to think of examples of code going in the opposite dir…

That's a really useful insight. What particular problems did you run across in Python that Java/C++ handled better?

It's hard for someone who was not the author to dive in to the middle of the code and understand it, debug it or upgrade it, due to the lack of explicit types.

Additionally there static analysis was limited to lint and refactoring tools didn't exist, or at least nobody seemed to use them (I never used PyCharm but I heard it can do some cool stuff).

Also for whatever reason these codebases often weren't very well structured and there was a common tendency to define configuration files that were themselves Python, resulting in the codebase spilling out into things that were theoretically just static data, complicating unit testing.

Re: Java Developers

#207

Post by hibikir » Tue, Jul 22, 2014, 3:01 PM UTC

dmacvicar wrote: post #68

_pmf_ wrote: post #41

Earlier quoted context omitted.

> Because languages like Scala and Clojure are rapidly taking over from Java in the enterprise space Let's see how much of the momentum these languages keep after Java 8. Default methods, the new stream API and lamdas provide much what most developers need without introducing baroque features and orthogonal infrastructure.

I did the two FP courses from Mr. Odersky using Scala as the main language and then continued playing with the language for small experiments. While the language is awesome in general, I would not recommend it at work.

The secret of Scala is that it can be used in a wide variety of ways by a wide variety of teams. Yes, you can end up hiring people that would rather work in Haskell, or those that hate the type system and would rather code in Clojure. I've seen people that attempted to make Scala look like Java, or even Javascript. My current team, working in Scala, has had plenty of people like that. But the fact that you can get too academic with Scala does not mean you have to.

Some parts of our codebase really work better with said academic style, so we keep them. In others, the type system was used in ways that did not make any sense, and were rewritten.

Scala's strength is precisely that it can look like anything you want. If you are not interested in said freedom, then sure, avoid Scala at work. But for us, using the style that works better in each part of the system without actually having to change languages is extremely powerful.

Re: Java Developers

#208

Post by agumonkey » Tue, Jul 22, 2014, 3:02 PM UTC

kasey_junk wrote: post #196

adwn wrote: post #189

Earlier quoted context omitted.

I thought the central point of OOP was to encapsulate functions ("methods") and the data ("objects") they operate on, thereby providing a way to structure code? That's why it's called "Object Oriented Programming" and not "Polymorphism X Y". Wikipedia at least seems to agree with me.

I think one problem that people have when they are talking about object oriented (or FP for that matter), is that there isn't a clear definition around what it means. Most developers agree that it is some mix of encapsulation, polymorphism and inheritance. There is a lot of disagreement about which of those is more important. For me polymorphism is the most important, encapsulation is useful sometimes, and inheritanc…

I had that revelation at my college Lab, teacher discussing why OOP was such a beautiful thing, none of them could agree on definition of OOP nor the qualities.

FP is smaller and stricter, it's almost formally defined (you have denotational semantics for FP VM for what it's worth).

Re: Java Developers

#209

Post by kaonashi » Tue, Jul 22, 2014, 3:02 PM UTC

kyllo wrote: post #192

pjmlp wrote: post #170

Earlier quoted context omitted.

Yes. Type classes is a way of doing polymorphism in Haskell, the central point of OO.

OO is more general than that, it's just a general paradigm for code reuse. Polymorphism is one of many forms of code reuse (allowing functions to accept multiple type signatures). I wouldn't call it the "central point" because polymorphism can be done without OOP, and OOP can be done without polymorphism.

What you're saying is that traditional OO conflates polymorphism with encapsulation and inheritance, creating one big complexity murder-death-ball; whereas Haskell lets you have these things a-la carte, so you can deploy them as needed.

Re: Java Developers

#210

Post by nick_riviera » Tue, Jul 22, 2014, 3:03 PM UTC

mike_hearn wrote: post #198

nick_riviera wrote: post #108

Earlier quoted context omitted.

Mainly FXML (I hate XAML as well) but it's better than Swing.

How would you prefer to define UI layouts? Some other DSL? A binary format?

Another DSL. Structural DSL like this:

   form {
      input {
         name = "bob"
         label = "Bob"
      }
      button {
          action = #{bean.submit}
      }
   }

I've actually wrote a C code generator DSL over the top of Win32 many years ago that did this so the financial app I was working on so we didn't have to write millions of dialogs in win32 loops.