Live data from Hacker News

Java Developers

nsainsbury.svbtle.com

151–160 of 321 posts

Re: Java Developers

#151

I agree with much of the article (also as being a java developer for the last 17 years). However, I don't think the problem ie necessarily Java Developers - I think they were just early adopters of the larger problem: Frameworks. Too much software these days relies on frameworks in order to 'get things done'. The knock on effect is that developers don't have to think as much about how things work (technical debt is a…

Unless you're writing something very simple, you're going to end up re-inventing portions of a framework in order to do what you need to do anyway. In which case you're going to be wasting time. If you're trying to write a complex web application it isn't a good use of your time to implement templating/declarative views/JSON serializers/etc in a low-level language. It's not laziness - it's efficiency.

Low level systems programming is good for low level systems code - code where you have to interact with hardware directly or quasi-directly. If you're doing anything higher-level, like, as I saw here recently, a web framework in assembler, it is certainly a good intellectual exercise. But it stops there. You're going to again and again find that you want a lot of the functionality that a modern, higher-level web framework provides without having to implement it yourself.

Good programmers exist at every level of abstraction. The question isn't whether or not you're using frameworks and a high-level language but whether you're maximizing your language and your toolset and creating the most elegant, bug-free code you can with your time.

I do agree with the author's sentiments about OO, but that's just because I started to use Scala and I've started to really become allergic to state and mutability, recognizing that your code is so much easier to understand and write when you put all your state in one place - like the RDBMS or the filesystem - and your code doesn't need to worry about its own state.

OO works fine for plenty of people as long as you can design your object graph in a way that's not too convoluted, littered with useless or empty classes, and doesn't have too much concurrency.

Re: Java Developers

#152
post #42

> 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…

> Because that's what people use to write real programs. Many people said the same of GOTO statements a generation ago.

I don't believe the parent of your post meant to say that nothing ever changes ;) Personally I think Java is a good, first language to learn. It's quite simple and easy to get started with. I'm not saying Java exclusively mind you, but that it is one decent language to start with.

As for the OP, I disagree. There are tons of good Java projects out there and there are tons of crappy Java projects out there ... just like pretty much every language ever invented.

Re: Java Developers

#153
post #33

I agree with much of the article (also as being a java developer for the last 17 years). However, I don't think the problem ie necessarily Java Developers - I think they were just early adopters of the larger problem: Frameworks. Too much software these days relies on frameworks in order to 'get things done'. The knock on effect is that developers don't have to think as much about how things work (technical debt is a…

Assembly, and Low Level Coding is the exact opposite of solving 'real' problems. Your going low level to create problems that didn't exist, as opposed to working on the core issue(often business related) your software is trying to solve. Languages should allow you to focus on creating software that fixes a real world problem, as fast and cleanly as you can. That doesn't include bit flipping, or bit operators or anyth…

There are many goals and many problems. "People" should use the right tool for the job. I don't want to try to write performance critical code or low-level code (OS level, drivers, critical libraries) in a language that seems almost designed to resist my efforts. Similarly, most people don't want to write business critical processing in C.

Re: Java Developers

#154
post #99

Earlier quoted context omitted.

The key selling point of functional languages is not lambdas, but immutable state and referential transparency. People read "advantages of functional programming" and think "anonymous functions" and "they're talking about scary Haskell" which is wrong. Although lambdas are a big improvement to Java, they are not helping enough to make the language more functional. Java is built upon mutable state to its very core, an…

> The key selling point of functional languages is not lambdas, but immutable state and referential transparency. Not everyone agrees, evidently! In his influential paper, Hughes argues that higher-order functions and laziness are key to functional programming.

Hughes didn't disagree with what I said; I would contend that higher-order functions and laziness only improve modularity iff the language was referentially transparent in the first place. The assumption that the theoretical FP language he discusses is referentially transparent is found on page 2 of Hughes' paper.

Java's lambdas only serve to reduce boilerplate; everything done with Java's lambdas was long possible using anonymous classes. Theoretically, they do nothing to present the advantages discussed by Hughes [1].

Hughes also didn't talk about laziness-by-default: his argument still holds if laziness is available somehow (which it is in many FP languages).

[1]: Of course, lambdas might improve the style and expressivity of idiomatic Java enough to make up some ground.

Re: Java Developers

#155
post #132

Earlier quoted context omitted.

CLOS is a layer on top of CL, it's optional. Also, LISPs are as verbose as you want them too. If you identify boilerplate you macro it away. It's part of the culture. Some systems (php/symfony2, eclipse/emf) go out of their way to generate unnecessary temporary files, templates and such but it's still cumbersome. To be honest, CL shows its age (mapc, mapl, do, dotimes, loop ...), more functional approaches like sml a…

Talk about workarounds.

Lisp macros ? (first-class and generic, not bad for a workaround)

Re: Java Developers

#156

Earlier quoted context omitted.

> OO actually works well for scaling complexity, much better than toy immutable functions do. Sure, but the problem is that OO is frequently applied where you don't need scalability, and then OO becomes the complexity that needs to be scaled. A low-hanging example of this is the singleton pattern, and the Wikipedia section titled "Example of use with the Abstract Factory pattern" saves me from having to bother making…

If you get good at programming, you actually know when to apply these patterns (and many others not in the GoF bible). And of course, I mix OOP and FP styles all the time, I'm not a purist by any means (a guy who does F# once commented on how FP my C# code looked).

> If you get good at programming...

This is a very important point (hopefully more "when" than "if"). I'm really tired of seeing naive programmers throw the handful of design patterns they know at every problem, not because the abstraction is a fit, but because their toolbox simply doesn't have that many tools.

Re: Java Developers

#157

I agree with much of the article (also as being a java developer for the last 17 years). However, I don't think the problem ie necessarily Java Developers - I think they were just early adopters of the larger problem: Frameworks. Too much software these days relies on frameworks in order to 'get things done'. The knock on effect is that developers don't have to think as much about how things work (technical debt is a…

Interesting! The most important difference between frameworks and libraries seems to be the "don't call me, I'll call you" pattern. Frameworks call your code, while libraries get called by your code. It's easy to see why "don't call me, I'll call you" leads to unreadable code. A piece of code is readable if you can understand how it works, not just what it does, and a big part of "how it works" is figuring out the co…

Strange, since I started using Django a while ago, I would say it encourages me to keep my own code a lot more organized. Are Java frameworks so much different?

As for functional programming, I only mix bits and pieces here and there. One thing I find quite discouraging about JavaScript, is that (in the code I have been reading) you can define a function within another function, and pass that on to other parts of the program. I have found it really difficult to work out what is going on in the code. In a basic Python script, define the functions at the top then write something to call them at the bottom. Its easy to see where the code starts and ends - well a whole lot easier than looking for function definitions within other function definitions. It just seems unorganized to me. I know that it is supposed to be a benefit of functional programming that you can do so many things with functions, but I find it makes debugging difficult, especially at the start. Is Haskell better at keeping the code organized? I have never used it.

Re: Java Developers

#158

I've been a java developer for over 10 years (8 professionally). I've worked as a consultant on large government projects, using legacy frameworks like Struts/Tiles and being forced to use older versions of Java. I've worked for tech-startups being able to use new and hot tech. like Cassandra, jdk8, and the play-framework. And in between I've hacked on a ton of personal projects, including tech like gwt, mongodb, and…

I can say the same re your experience, but I kind of experience the same thing he links to with Gradle and really despise it. Handling the constant Groovy errors and Gradle errors, and spending my life digging through their docs for a language and a build system I couldn't care less about really depresses me when I'm a Java expert. Give me a stack trace and I'll have the problem fixed in five minutes with unit tests and UI automation tests done later that day.

But give me a gradle error and I'm stuck in their docs all day, you might have a solution this week. And by the way it breaks automatically all the time as Android Studio and the android tools plugins and all the rest version up. I wish we could have just stuck with Ant and Eclipse for Android, which are known evils. Instead every update of Studio and Gradle someone on the team has to draw the short straw and try, then either give everyone else the OK or tell them to stay the hell away from that version.

Re: Java Developers

#159
post #126

Earlier quoted context omitted.

I think I already mentioned why Linux distros build the entire chain from source: they provide support for it, they need to be able to patch it and they can't take responsibility for binaries built in an unknown environment. However, I don't understand why you mix two things: maven concept and design (which is fine) with what I criticized: a build tool that depends on everything that it intends to build in the first…

Bootstrapping any tool is going to look that way. To compile gcc you need a C compiler don't you?

Yes, but gcc requires gcc and THAT is. gcc does not require KDE and apache to build (which is like Maven dependency chain looks like).

Re: Java Developers

#160
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.

Doesn't change the point. It's called JAVA but with lazy streams and closures, everything Java culture built prior that will be moot and that's what the article is pointing at. Same thing happened in PHP land, people say PHP is great now, but what is PHP ? PHP5, which is a perlish javaesque thing ? or the regex craze html implicit template system that was PHP4 ? ... OOP is too verbose by it's essence compared to clos…

> Same thing happened in PHP land, people say PHP is great now, but what is PHP ? PHP5, which is a perlish javaesque thing ? or the regex craze html implicit template system that was PHP4 ? ...

Get the facts straight please.

As much as I don't like everything about PHP, PHP means PHP5 and it has been like that for a few years.

Post reply on HN