Live data from Hacker News

Java Developers

nsainsbury.svbtle.com

231–240 of 321 posts

Re: Java Developers

#231
post #92
post #4

Earlier quoted context omitted.

Isn't it just a little sad that the biggest selling point of a language is that mediocre developers won't cause too many problems with it?

It's not sad, because most developers are mediocre. It may not apply to you, but if you work in the industry long enough you realize that very few of your colleagues are good/great. And there's nothing wrong with that, but if you want to build systems that have to be maintained over multiple years, you somehow have to compensate for that. Java is one compensation.

Exactly. By definition, most developers are mediocre, and thats okay. Platform stability and limiting complexity is really important in the long run, so (luckily, imho) C++ and Scala are non-starters.

Re: Java Developers

#235
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

Who gives a shit? Computers are cheap, programmers are expensive. You're probably deploying onto Amazon anyways, so don't kid yourself.

In the vast majority of cases, it doesn't help your average coder one bit to know about whether or not a particular type of shift on their platform is arithmetic or logical, or how their cache is structured (again, running in a VM, lolzors).

There are cases where it matters--and surprise surprise, most of us don't work in those fields.

Re: Java Developers

#236

Earlier quoted context omitted.

> I don't see the need of it if you already have a class-based system. Like in Java? new Object() { void foo() {}}.foo(); // Works Ooops. The point about XML is so stale already that I won't even bother commenting on it.

You seem to be stuck in the topic of how useful structural typing is. Which I agree with.

Eh what? No. I couldn't care less about structural types.

I care about simple, consistent rules. "X is a type, you can use it wherever you want" is one.

"X is a type, but there is also Y, which you can't really express in position A and B unlike X, but can only use it if you carefully avoid doing things #1 to #4" isn't one.

Re: Java Developers

#237
Not only Java. I die a little every time I see a PHP application trying to cargo-cult common Java overdesign patterns because "that's how 'Enterprise' apps are built".

Re: Java Developers

#238
post #169

Earlier quoted context omitted.

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

No, faced with the fact that CLOS is also verbose, although in a language that is all about closures, you started to present workarounds how to simplify its verbosity.

I don't find CLOS verbose. Private slots by default, accessors as option ... I find LISPs quite succint in general, sure lots of parens, but usually the bare minimum of information is required. This contrasts with the large amount of useless code you can see in Java class definition that amount to nothing (setting fields, toString, manual get/set).

Re: Java Developers

#239

Earlier quoted context omitted.

It seems that you argue for subtyping for the sake of subtyping. Up to you man. Peace.

I don't read it that way. One way of viewing nouns in English is as a hierarchy. At the top of the hierarchy you have "thing", and as you descend the pyramid you get more and more specific. "What is that thing?" -> "What is that animal?" -> "What is that mammal?" -> "What is that ungulate?", etc. There are times when it is appropriate to use "animal", and times when it is appropriate to use "ungulate". It depends on…

This kind of metaphor is why object systems go so epically wrong. You just want the minimum set of objects that you need to express the problem. In my experience, any attempt to map that to natural language taxonomies leads to a large number of object subtypes that just exist to name things, not DO things.

When dealing with OOP, I stick with patterns and keep everything else as flat as possible.

Re: Java Developers

#240

I think most of the problems are caused by enterprise, enterprise frameworks, and the sheer age of Java. There's a lot of technical debt built up and a lot of enterprisey frameworks that are way over engineered. I use Java, but I tend to do low level stuff, stick to basic I/O, Guava, etc. I think the article is right in one important aspect: the way Sun built Java was to pretend as if everything should be a competiti…

Java is not designed to solve programming problems, it's designed to solve organizational problems. And it does a pretty good job. That's why you see lean startups shunning it then slowly migrating when their company gets too big.
Post reply on HN