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

321–330 of 344 posts

Re: Java for Everything

#321

Post by jtheory »

coldtea wrote: post #316
nickbauman wrote: post #304

Earlier quoted context omitted.

You really don't get it do you. An s-expression doesn't have to be evaled to be read. I just keep getting downvoted here. It's like offering a machine gun to a caveman and getting clubbed to death with it.

> An s-expression doesn't have to be evaled to be read. Yeah, so you get a serialization format that's the same as your code. Big deal. And you have to live with your code having the same look as a serialization format. Even McCarthy wanted to give Lisp a proper syntax. > It's like offering a machine gun to a caveman and getting clubbed to death with it. More like it's coming to Paul Graham's house to tell him all ab…

Okay, this suggests I'm not confused; there's just no argument given.

> Yeah, so you get a serialization format that's the same as your code. Big deal.

There's no reason this would be automatically a "good thing" -- a serialization format that is also valid source code -- it's just a thing. It's good to have a clean path from data structure to serialized data and back again; but if the obvious way to re-create the data structure (exec the code) has a huge security flaw built into it, that's no longer a clean path.

Human-readable serialized formats are nice; but guidelines on "readable" for a data structure vs. "readable" for full-power source code are not the same -- and "compact" is also strongly good for serialization formats, but not nearly so important for source code.

Re: Java for Everything

#322

Post by peterashford »

saosebastiao wrote: post #101
lkesteloot wrote: post #40

It's not so much that Java is great at everything. It's more like it doesn't suck at anything. Every other language has, somewhere, a deal-breaker for some particular use. I've not found one for Java. And Java's biggest downside, frankly, is that it hasn't attracted fresh young talent in a while, so it doesn't have really hot frameworks and libraries.

IMO, being tethered to the JVM is both its greatest strength and its greatest weakness. The JVM really is a masterful piece of engineering, but it is optimized so heavily for the server that any use case that deviates requires huge hacks to get what you want. For example, running a JIT on Android was so sluggish that Android had to design an entirely new runtime(ART).

The JVM runs very well on the desktop as well as the server. I have to point out: Android runs Dalvik, not the JVM. But here's the point: Java isn't tethered to the JVM. Use the JVM for server, desktop, Use ART or Dalvik for Android. Use Jikes, Excelsior Jet, RoboVM or other VMs, compilers for other targets. The limitation you raise doesn't really exist.

Re: Java for Everything

#323

Post by fsloth »

unclebucknasty wrote: post #318
fsloth wrote: post #240

Earlier quoted context omitted.

This behaviour - downvoting without explanation irritates me too when there is very lucid and concisely structured argument you can oppose. As such, I do not find your argument for verbosity normalizing convincing :) I fail to see how normalizing some risk metric against a verbosity of language will provide any valid data in the general context. For numerical algorithms, where a multiplication is just as verbose in a…

Well, I can appreciate the reply versus a downvote, but "I do not find your argument [against] verbosity normalizing convincing." :) > I fail to see how normalizing some risk metric against a verbosity of language will provide any valid data in the general context. OK, then let's look at the corollary: that is, not normalizing against verbosity would mean, roughly, that you're claiming that a language that is twice a…

"Overall, the notion of LOC alone being a risk-metric absent any additional context seems an oversimplification."

Yeah, I agree completely. Didn't think too long before answering there, I'm afraid. I confused the fact that in my experience increase of LOC correlates with increased risk of bugs with there actually being a causality between the said observables.

For me personally languages with higher LOC are harder to read, but this is just about the languages I like and not a generalization that can be applied to any language in general (i.e. Ocaml is nicer than C in this sense but APL or J would get me just terribly confused).

Basically, of the languages I consider readable, and when dealing with container operations, it's easier for me to parse especially those that either have basic containers as fundamental data types in the language (e.g. Python, F#) or have a uniform syntax over typical algorithms and containers (Clojure) rather than verbose languages like C or Java.

In these instances, it's not about the overall LOC count of the languages but the fact that they make common operations more legible and easier to reason with than C. I.e. they have less non-value adding burden typically. Why they are nicer, is not because of their LOC, though, but their LOC is a side-effect of their features that make them nice, I think.

Thanks for pointing this out :)

Re: Java for Everything

#324

Post by squar1sm »

MarkMc wrote: post #163
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…

Ant has a bad reputation? I clearly didn't get the memo - I find Ant to be a great little tool.

Ant's one of those "seldom skills". You set it up in the beginning and then tweak a little bit. Yes it works, it's fine. I just find it funny that it hasn't changed or evolved in a long time. I just keep taking my old examples and tweaking them. It's weird.

Re: Java for Everything

#325

Post by squar1sm »

allengeorge wrote: post #132
jafaku wrote: post #53

Does anyone know a good starting point for learning not just Java, but how to install everything I need? I consider myself the Neo of OOP and a master devops, but every time I tried to use Java I hit a wall of unreadable manuals/guides , software impossible to install/maintain, and mixed opinions among Java devs. Like it can't be used without a dedicated sysadmin.

That...sounds surprising. Basically you need: 1. An IDE (I highly recommend IntelliJ IDEA) 2. A build and dependency management tool (I prefer Gradle, but Maven is a reasonable choice - though way more verbose) Beyond that point, a lot depends on what you want to do. Some of my preferences (YMMV): * logging: slf4j over logback * json serialization/deserialization: jackson * db access (if you don't need or want ORM):…

Great list. I wish this list and ones like it had a name other than "modern java" to distinguish tools/projects/people/interest/books. Because it's hard to name something that's a synonym for "new". Eventually "more modern java" is needed. And then "most modern".

Re: Java for Everything

#326

Post by unclebucknasty »

fsloth wrote: post #323
unclebucknasty wrote: post #318

Earlier quoted context omitted.

Well, I can appreciate the reply versus a downvote, but "I do not find your argument [against] verbosity normalizing convincing." :) > I fail to see how normalizing some risk metric against a verbosity of language will provide any valid data in the general context. OK, then let's look at the corollary: that is, not normalizing against verbosity would mean, roughly, that you're claiming that a language that is twice a…

"Overall, the notion of LOC alone being a risk-metric absent any additional context seems an oversimplification." Yeah, I agree completely. Didn't think too long before answering there, I'm afraid. I confused the fact that in my experience increase of LOC correlates with increased risk of bugs with there actually being a causality between the said observables. For me personally languages with higher LOC are harder to…

>Thanks for pointing this out

Well, I think you actually described it more eloquently, once we got there. :)

Re: Java for Everything

#327

Post by lmm »

unclebucknasty wrote: post #315
lmm wrote: post #282

Earlier quoted context omitted.

> In any case, unless you're purposely writing completely nasty throwaway code, there is always some reusability, which typically makes starting from scratch in a new language a much weightier prospect than making some scalability enhancements to the existing base. It's not really from scratch. If you've figured out the correct structure and interfaces to solve your problem you can reuse all that when porting to a di…

> If you've figured out the correct structure and interfaces to solve your problem you can reuse all that when porting to a different language Well, I think you're underestimating the sheer brute force work needed to port an app with a large-ish LOC base. But, beyond that, if you've gone through the care of structuring it correctly such that the structure and interfaces are preservable once scalability needs arise, t…

> Well, I think you're underestimating the sheer brute force work needed to port an app with a large-ish LOC base.

I have done this professionally. You don't port everything, you just port services as they become bottlenecks. By the time you need to scale like this, you already need to have multiple engineering teams and you need well-defined interfaces between components, so having parts of your system in different languages doesn't impose an additional cost.

> So, if it can be so readily adapted to a new language and you're preserving so much code, then why bother porting it? Kind of makes may original argument. Just apply the scalability tweaks on the existing code base and you're done.

Sure, which is probably why Digg was happy to carry on using PHP. For the vast majority of systems you never get to the scale where using Java is worthwhile (at least in performance terms).

When do you want to port? When your server costs get high enough that a 15x performance factor is worth the constant cost in dev time that using a lower-level language would cost[1]. It might take more effort than writing in Java from day 1 - but it might not, if you go through several iterations of prototyping/refactoring in PHP and then only port once you've found the correct design. And more importantly, you get to pay the Java price much further down the line, when you're bigger and more profitable. As PG says, an early-stage startup should do things that don't scale.

[1] I'm not convinced you can't have your cake and eat it, with e.g. Scala or Haskell. But assuming for the sake of the argument that the only languages were Java and PHP and PHP really was more productive than Java but less performant.

Re: Java for Everything

#328

Post by jbergens »

msluyter wrote: post #105
blazespin wrote: post #85

Earlier quoted context omitted.

I suspect readability isn't a big priority for you. Here's how I'd write this, lambdas or not: public static List sortDescending(List ints) { ints.sort(new Comparator () { @Override public int compare(Integer o1, Integer o2) { if (o1.equals(o2)) { return 0; } else if (o1 My personal perspective is that your use is a typical abuse which turns simple code into something unreadable and overly complex. This makes code ha…

shrug . This seems like a pretty standard use of the ternary operator to me. I mean, just google examples of Comparator, and you'll find tons of examples like this: @Override public int compareTo(Object arg0) { Country country=(Country) arg0; return (this.countryId country.countryId ) ? 1:0 ; } ( http://www.javacodegeeks.com/2013/03/difference-between-comp... ) But that's orthogonal to my point, which is that lambdas…

And lambdas (or similar) has existed in C#, Python, Scala, Javascript and other languages for years. I still thinks this means that those languages has had large benefits compared to Java (7 and older). Now that Java 8 has lambdas even Java developers can learn to write better and more readable code. I also thinks that Java 8 is good enough for most projects now but Java 7 wasn't. Just my thinking.

Re: Java for Everything

#329

Post by jbergens »

waps wrote: post #158
freshflowers wrote: post #34

The same argument can be made for any mature language with a solid ecosystem of tools and libraries. Except the part about scalability, that's just BS. It has little to do with language and is all about architecture. Sure, at some point language can help you squeeze every ounce of performance out of the hardware (although my money would not be on Java for that), but that's only in cases where either performance is cr…

You forget just how much difference there is between languages. Comparing Python and Java for example, it's easy to find things that take 1-2 cpu cycles in Java (or even 0), that take thousands of cpu cycles in Python (e.g. function calls). http://benchmarksgame.alioth.debian.org/u32/python.php I mean, I would agree that 1s versus 1.3 seconds doesn't really matter. But look at those numbers we're talking 40-50 TIMES…

I agree that the project size (LOC and usage) matters a lot and that small projects could use almost any language. I don't agree that everything i linear. A project with 10 times the LOC is not just 10 times harder to build, it might be anywhere from 20-100 times harder. For example, 10 000 LOC is possible for a developer to read and remember quite well, 100 000 LOC is much harder and takes longer to read. 1 million LOC is probably really, really hard to read and understand (especially when we are talking about old code with a lot of cruft and possibly multiple changes in the design over time). So for a small code base that happens to have millions of users you should probably go for a fast language and take the time to optimize a lot. For a large code base with very few users you should probably use an expressive language and don't care about performance. And then you have all in-betweens which are left as an excercise to the reader ;-)

Re: Java for Everything

#330

Post by jbergens »

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…

I think we need something that could be called "The good parts of the Java/Ruby/C#/Javascript/... ecosystem".

Showing what tools and libraries are recommended at the moment and how some of them work together. In Javascript the ecosystem is growing almost exponentially which makes it impossible to keep up with everything. In Java and C# there is many old classes still in the libraries and around that most experienced developers avoid. And some trimmings of the ecosystem would probably be useful every 3-5 years or so.

Post reply on HN