Live data from Hacker News

Java Developers

nsainsbury.svbtle.com

251–260 of 321 posts

Re: Java Developers

#251

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…

I more or less agree with your post, but take issue with a few things:

- Maybe I come from a different kind of academia, but in my CS education they didn't force "large unnecessary abstractions". Mind you, they didn't teach Java, C++ or any particular language. Learning programming languages was something you did in special optional classes or on your own.

- It is fascinating and instructive to learn low-level languages such as assembly, which I enjoyed learning in my spare time, but I don't think that's "what the actually world needs". The world needs reliable, non-bugged software that does what we want and is easy to understand, maintain and extend. Certainly not something that would be helped by coding in assembly...

To clarify: I believe it's immensely instructive to learn about low-level stuff. It should probably be mandatory in a good CS education. But it's not a good idea, in general, to actually build programs by manipulating low-level language. Sometimes it can't be helped, of course, by I assume we're mainly discussing application software here.

Re: Java Developers

#252

Earlier quoted context omitted.

Google have issues with Oracle. Why not bless an alt-Java and give developers a clear signal. The end game should be Kotlin or Xtend or ? -> Dalvik/ART. Cut out Java.

Dart for the win

Dart is interesting but a little too Jave-ery in both syntax and tools - Dart Editor is Eclipse based. Also, not sure how committed Google is long-term.

Google's issue is too many languages and runtimes: Go, JS/ES6/V8, Dart/DartVM, Java/ART, PaNcl, RenderScript.

With the Material/Paper UI Google have given dev's a consistent, elegant unified surface. But Google should also be moving in the direction of an (elegant) unification under the hood. Java and JS are 20 years old - but are at the core of Google's platforms - Android and Chrome/OS. But what - Kotlin, Dart, ES6/7?

Re: Java Developers

#253

Earlier quoted context omitted.

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

Or, you know, use languages that take OO to its logical conclusion, like Ruby, Smalltalk, or the right answer in a concurrent environment, Erlang. People hate on OO either because they're being edgy or because they are frustrated with bad implementations of its ideas. OO is the correct way of thinking about things in the real world, because that is how disjoint systems communicate. Internal to an actor, use all the f…

I disagree OOP is the correct way of thinking about the real world, and I think the software industry is starting to realize it was an overblown fad too (and moving on to the next fad, of course), BUT...

... I agree Java is not a particularly good example of OOP. It amazes me that so many people complain about Java "forcing OOP on everything". If I read framework source code, I see very little OOP in there. It's mostly procedural-with-classes. Maybe we've redefined OOP to mean "whatever Java is doing". Which is nightmarish, the worst of all worlds.

Re: Java Developers

#254
post #248

Earlier quoted context omitted.

Ok - so in a web application I need routing/binding of controller functions to URLs/HTTP methods, the ability to interact with an RDBMS and parse a result-set into an intermediate abstraction, the ability to take in the results of a POST or PUT and parse it/validate it/sanitize it, the ability to emit JSON....and yet all of this functionality is baked into my web framework. I can either use a library for each one of…

I think the advantage of using each of those libraries instead of a single unifying framework is that you put them there and understand why they are there, instead of relying on defaults. Also, there is less risk of framework-induced coupling -- sure, many frameworks are configurable, but try to move away from their recommended components and you are asking for trouble...

Also, there is less risk of framework-induced coupling -- sure, many frameworks are configurable, but try to move away from their recommended components and you are asking for trouble...

Exactly. If you built your own system, choosing a good library for each major recurring task, then you inherently have both an understanding of how the overall system fits together and a degree of isolation between the libraries. If your requirements evolve beyond the scope of a library you’re using, or if a library loses popularity and is no longer maintained, you can probably swap in a replacement to serve an equivalent (or updated/expanded) role relatively easily.

Of course, the price you pay is that you do have to write some glue code to connect up the libraries where perhaps a framework would have provided that for you. This has potentially interesting implications for both the way good library APIs are designed and the scales of libraries that are or aren’t worth the overhead.

This also has huge implications for language design as a whole, and personally I think this is one of the reasons why Java is infamous for its verbosity and boilerplate. I also think it’s one of the reasons why common idioms from functional programming have increasingly been pushing into mainstream languages that aren’t necessarily functional programming specialists: functional idioms offer new forms of glue, and in particular, they are often well suited to writing “slightly customisable” algorithms and adapting more substantial pieces of code so they can be used together.

Re: Java Developers

#255

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

I've noticed that the combination of math and communication skills is pretty well correlated with producing clean designs and code. Data scientists probably have those skills more often than programmers, but I'd argue that it's the skills rather than the culture that account for the difference you are seeing.

Re: Java Developers

#256
post #157

Earlier quoted context omitted.

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…

You can define functions within the scope of another function in Python as well. It's up to the developer to keep it organized.

Re: Java Developers

#257
post #253

Earlier quoted context omitted.

Or, you know, use languages that take OO to its logical conclusion, like Ruby, Smalltalk, or the right answer in a concurrent environment, Erlang. People hate on OO either because they're being edgy or because they are frustrated with bad implementations of its ideas. OO is the correct way of thinking about things in the real world, because that is how disjoint systems communicate. Internal to an actor, use all the f…

I disagree OOP is the correct way of thinking about the real world, and I think the software industry is starting to realize it was an overblown fad too (and moving on to the next fad, of course), BUT... ... I agree Java is not a particularly good example of OOP. It amazes me that so many people complain about Java "forcing OOP on everything". If I read framework source code, I see very little OOP in there. It's most…

> It amazes me that so many people complain about Java "forcing OOP on everything". If I read framework source code, I see very little OOP in there. It's mostly procedural-with-classes. Maybe we've redefined OOP to mean "whatever Java is doing".

We kind of have, though it started pre-Java. "Procedural-with-classes" pretty much became "OO" from C++, and Java got it from there.

OO is a good way of approaching many real-world problem domains, but most OO programming languages implement OO in a way which has a significant impedance mismatch with the way in which OO is a good way of approaching real world problems.

I'm increasingly unconvinced that OOP (in terms of language features, even in the Ruby/Smalltalk sense, much less the Java/C++ sense) is actually an important tool in the mapping of OO thinking about systems to actual concrete programming, and that other approaches, like REST-based (not particularly HTTP-based, but the architectural style) SOA where the individual components are functional might be better -- traditional OOP, IMO, promotes tighter coupling than you real want in an OO system, and then requires elaborate patterns to mitigate that into slightly looser coupling than the language structures naturally promote.

Re: Java Developers

#258
post #242
post #192

Earlier quoted context omitted.

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.

It is central. Without polymorphism you don't have a way to abstract algorithms over types. So you just get ADTs as introduced by Mesa/Modula-2.

You can do OOP with only ad-hoc polymorphism, which is just method overloading, which is what Java and C++ do. Actual parametric polymorphism isn't necessary for OOP, and there are non-OOP languages that have it (e.g. SML has polymorphism but does not have objects).

So, polymorphism and object-orientation are orthogonal concerns. OOP is about encapsulation, inheritance, and modules that couple mutable state (attributes) and behavior (methods).

Re: Java Developers

#259
post #174
post #107

Earlier quoted context omitted.

Writing low-level code is important for writing the underlying libraries for those high-level languages, e.g. the run-time systems or the big integer routines.

It's also important due to it helping one understand everything that's going on under the hood in whatever high level language one's using

While it is important to know low level details if you are going to understand how the high level language is built, it is not necessarily important to know how the high level language works if such details don't readily aid you in your task.

It might be nice and it might be cool, but it doesn't matter so much. Or to put it another way, how many people learned how tracing JITs work to do JS form validation? Would it matter if I did/didn't know this? Would it make a better form validator? Eh.

There seems to be some limit to the benefit that knowing such LL details provides. It's icing, but it is most definitely not the cake, and when your time/budget/skills are limited, you want cake, not icing.

Re: Java Developers

#260
post #253

Earlier quoted context omitted.

Or, you know, use languages that take OO to its logical conclusion, like Ruby, Smalltalk, or the right answer in a concurrent environment, Erlang. People hate on OO either because they're being edgy or because they are frustrated with bad implementations of its ideas. OO is the correct way of thinking about things in the real world, because that is how disjoint systems communicate. Internal to an actor, use all the f…

I disagree OOP is the correct way of thinking about the real world, and I think the software industry is starting to realize it was an overblown fad too (and moving on to the next fad, of course), BUT... ... I agree Java is not a particularly good example of OOP. It amazes me that so many people complain about Java "forcing OOP on everything". If I read framework source code, I see very little OOP in there. It's most…

If you disagree, would you mind explaining your reasoning?

I suspect that we've started hitting the issue of "What, actually, is OOP?"

Post reply on HN