Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java for Everything

teamten.com

Post reply on HN
Print view View original

291–300 of 344 posts

Re: Java for Everything

#291

Post by lispm »

lmm wrote: post #281
edwinnathaniel wrote: post #235

Earlier quoted context omitted.

> like I said, the only proven risk factor for bugs is number of lines of code. There's never been a proof that writing code in Ruby WILL give you LESS bugs than in Java just because you'll end up with LESS LOC. I think this is a generic statement that needs to be clarified. I agree and I will not argue that LESS lines of code "might" give you LESS bugs given that you're writing it using the SAME language (version 1…

> Sometimes I wonder why developers aren't forced to just use LISP since everybody in the whole world knows that LISP is super expressive that it MUST resulted in far less code right? Right? You've fallen for Lisp propaganda :P. If you look at the shootout, Python and Ruby are comfortably ahead of Lisp in the expressiveness stakes. > Fred Brooks Second System http://en.wikipedia.org/wiki/Second-system_effect is exact…

> If you look at the shootout, Python and Ruby are comfortably ahead of Lisp in the expressiveness stakes.

The code in the 'shootout' is verbose, to make it fast. Much faster than Ruby or Python.

Generally small code in Ruby and Python can be more compact. For larger code this is then no longer the case, once the macro-advantage kicks in...

Re: Java for Everything

#292

Post by infinii »

twic wrote: post #152
lmm wrote: post #89

Verbosity matters for reading and maintenance far more than it does for writing. IDEs can make the writing faster, but they can't make the code as easy to comprehend as it would be in a more expressive language. And remember that lines of code is the only proven risk factor for bugs. Most sites are not Twitter. They're not Stack Overflow. They're not even Nanowrimo. I've watched a company spend two years, dozens of d…

> I've watched a company spend two years, dozens of developers, and over a million in ESB license fees failing to write a site that was expected to have, at peak, 100 users/day. I'm sorry to hear that. But you understand that this had nothing to do with Java, right? Java didn't make those people do that. That was just good old fashioned human stupidity. It's entirely possible to write simple things in Java, without E…

Is there an update to this book or something similar that speaks to Java +7?

Re: Java for Everything

#293

Post by lmm »

pjmlp wrote: post #286
lmm wrote: post #275

Earlier quoted context omitted.

You are. Sure you call libraries that aren't written in Python, but that seems just as irrelevant as the fact that the JVM is written in C.

Which JVM?! There isn't such thing as "The JVM", there is the JVM standard, reference implementations and certified JVMs. Oracle has JVMs implemented in a mix of C, C++ and Java, up to pure Java (Maxime), just like many other JVM vendors and research institutes also do. Even Oracle is playing with the idea of using the Maxime JVM, now Graal, to eventually replace Hotspot. The Java 7 and Java 8 reference implementatio…

> Which JVM?!

The Oracle one, aka the one production Java code is usually deployed on. I am aware of several of those research projects but they're, well, research projects.

Even if the JVM were fully implemented in Java, the OS most likely wouldn't be. Even if it were, the CPU microcode almost certainly wouldn't be. At some point your Java will be running on something not-Java, even if that thing is "logic gates". But it doesn't matter - just as the implementation language of the libraries you use in Python doesn't matter.

Re: Java for Everything

#294

Post by davelnewton »

ridiculous_fish wrote: post #100

You have to appreciate bombastic statements like this for forcing you to confront your assumptions. "Everything in Java? Even a kernel? That's absurd." you think, and then wonder what makes it absurd, and realize that it could perhaps be done with some modifications, and remember Singularity, etc. But on the other hand, this is well trod ground. Everything WAS going to be Java. Remember picoJava, the bytecode-native…

You forgot JavaOS.

Re: Java for Everything

#295

Post by davelnewton »

No no, not Java for everything. I know Java, use Java, and don't hate it. Some of the best tooling available (similarly C#, but .NET isn't my thing.)

Here's my issue: no matter what problem you try to solve the solution looks like Java. I want my solutions to look like my problem.

Static imports go part of the way there, and if you're good at naming and architecture, the learning curve for any particular system remains relatively low. It's a hack/sugar, but it helps.

But that's about as far as you can go using only stock Java, e.g., no syntax extenders, no byte code treachery, etc. AOP can help, but everyone has to be aware of it, and comfortable with a system designed with AOP from the beginning.

Java for shell scripts? No thanks.

Re: Java for Everything

#296

Post by jerven »

coldtea wrote: post #207
nickbauman wrote: post #201

Earlier quoted context omitted.

So you're consuming data of an existing (legacy) SOAP service? Or complying with exisiting clients of a (legacy) SOAP service? That's not the same as writing a new SOAP service. If the language you're using is already expressed in a form that does not need serialization, then you don't have to serialize it. This is the very essence of languages that are homoiconic. Perhaps you should familiarize yourself with that be…

> If the language you're using is already expressed in a form that does not need serialization, then you don't have to serialize it. Yeah. If only that language and "not needing serialization" code format didn't have 200 other problems, like NONE of the major services accepting it, lack of tooling, a sorry state of an ecosystem, difficulty of finding programmers and/or jobs, etc...

And the simple fact that taking code provided by a remote service and just using it as is just handing the keys of your server over.

LISP homoicity is nice but its a bad, bad idea to accept LISP code over the network from any client. Documented dataformats that are not executable are enough of a security risk that sending an executable around is not a great idea.

(Should have been attached to grandparent, as I agree with parent)

Re: Java for Everything

#297

Post by jerven »

kamaal wrote: post #210
msluyter wrote: post #83

There's the language and there's the ecosystem. A lot of negative feelings that still linger are, IMHO, directed more at some of the painful historical aspects of the ecosystem: J2EE XML configuration hell, EJBs, bloated application servers, XML for everything, JAX-WS, SOAP, ant, classloader problems, maven dependency hell, 10 different logging libraries, etc... A lot of this stuff truly sucked. But I feel things hav…

>>Java8's lambdas + streams provide significant improvements. It will take more than a decade before we see any decent adoption of Java 8 in the industry. You are still going to see piles and piles of getters/setters, Enums, your design patterns taken to far extreme. Writing such pointless ceremonial code is the bloodline of Java community. Merely introducing a new version hardly changes anything.

The community that takes design patterns to far just happens to use Java (1.4 ;( ) if they used a different language they would do the same to that :(

Anecdote: I once saw a Perl shop that could have been the worst of Enterprise Java. They where the same because they where ENTERPRISE, they suffered in Perl in the same way the common office programmer suffers in Java.

Re: Java for Everything

#298

Post by peatmoss »

abalone wrote: post #238

iOS got this far on Objective-C. Seems like nobody really complains about that one the way they complain about Java. I think he goes a bit too far with "unit tests are a waste of time" (maybe he just means for type checking). But other than that this perfect captures my very pragmatic view towards Java. There's a lot to be said for consolidating on one server language, and if you're going to pick one language, that's…

The Obj-C stuff always had a very low cost to bring in C stuff. I've not done a lot with Java's FFI in terms of writing code, but every time I've tried to manage a build with Java that uses external C libraries, I want to cry. That alone pretty much erases the differences in hassle between Java and Obj-C in my opinion.

Re: Java for Everything

#299

Post by tboyd47 »

fsloth wrote: post #285
userbinator wrote: post #267

Earlier quoted context omitted.

It's entirely possible to write simple things in Java, without ESBs and a person-century of effort. That I don't disagree with (see Java4K and various other demoscene-like competitions), but when the mainstream culture of Java is oriented towards architecture-astronautism and "enterprisey" bureaucratic excesses of complexity, that's what the majority of Java developers you find are going to do. Ask them why a simpler…

"was told to "refactor" a fairly trivial 20-line method in one class into 8 separate classes each containing 1-line methods" How typical is this level of non-value adding misguided pedantism? I understand that big software consultancies would want to milk their clients for all the work they can for implementing function points. But what profitability models drive developers to this level of weirdness? Is it just a cu…

It's plain and simple pedantry, and it's not confined to Java. This mindset has a healthy representation in the Ruby community, which actually makes programming in Java much less distasteful to me -- if I'm going to be writing AbstractSingletonFactoryAdapters, then at least let my AbstractSingletonFactoryAdapters be fast.

Re: Java for Everything

#300

Post by overgard »

twic wrote: post #152
lmm wrote: post #89

Verbosity matters for reading and maintenance far more than it does for writing. IDEs can make the writing faster, but they can't make the code as easy to comprehend as it would be in a more expressive language. And remember that lines of code is the only proven risk factor for bugs. Most sites are not Twitter. They're not Stack Overflow. They're not even Nanowrimo. I've watched a company spend two years, dozens of d…

> I've watched a company spend two years, dozens of developers, and over a million in ESB license fees failing to write a site that was expected to have, at peak, 100 users/day. I'm sorry to hear that. But you understand that this had nothing to do with Java, right? Java didn't make those people do that. That was just good old fashioned human stupidity. It's entirely possible to write simple things in Java, without E…

> The normal approach to writing scalable apps these days is the twelve factor approach

I've never even heard of this. I agree with most of this advice, but, I wouldn't exactly call it a defacto standard.

Post reply on HN