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

281–290 of 344 posts

Re: Java for Everything

#281

Post by lmm »

edwinnathaniel wrote: post #235
lmm wrote: post #138

Earlier quoted context omitted.

> Care to share more details of these companies including how the Ruby ones become profitable after a month with 4 guys on payroll? No offense but I've got to check the facts these days.. :). It was small industry, those were basically the only two companies in it, I don't feel I can. (I've already changed some small details e.g. it wasn't actually Ruby). In any case it's just one person's anecdote - but I bet it's h…

> 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 exactly what you're experiencing, forget the language war for a second please. Really.

Really not. This was one of the leanest places I've ever worked; everything we did there was absolutely necessary for the scale we were operating at. I've seen second-system effect in action; last.fm wasn't it. Writing Java will not save you from having to scale horizontally; maybe it's 2x, 5x, 10x faster than a dynamic language, but if you're growing then these kinds of constant factors only buy you a small amount of development time.

> Recently we refactor a certain part of our code and added Microservice written in JAX-RS because we have to integrate with another product suite internally. That's what I called re-use and evolution of code-base: 10 years of Java where some of the code from the past were/are reused and still in production today. (.... but boy those old code aren't pretty, hehehehe).

If you're using microservices multiple languages really shouldn't be a problem. It's not like we rewrote everything; services that were fine in PHP stayed in PHP. We moved things to Java as and when we needed to. If everything's a service (Thrift in our case) then it really doesn't matter what language is on the other end.

And it's not exactly "from scratch". Physically typing out the code is never the bottleneck; most of the hard part of programming is design, getting the correct decomposition of the problem. Porting well-written code from one language to another language that supports the same paradigms is really not that hard, and certainly doesn't mean throwing away all the lessons of the first codebase.

Re: Java for Everything

#282

Post by lmm »

unclebucknasty wrote: post #200
lmm wrote: post #138

Earlier quoted context omitted.

> Care to share more details of these companies including how the Ruby ones become profitable after a month with 4 guys on payroll? No offense but I've got to check the facts these days.. :). It was small industry, those were basically the only two companies in it, I don't feel I can. (I've already changed some small details e.g. it wasn't actually Ruby). In any case it's just one person's anecdote - but I bet it's h…

> You're rearchitecting anyway, creating stable interfaces and putting load balancers in there because those are also things you need to do as you're scaling up. Changing languages is no harder I have to disagree here. With just a little forethought, a good bit of the code can be reusable. For instance, your data access layer. And, the more forethought you put into it, the larger the potential reusability. This doesn…

> 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 different language, and that's the hard part of development.

Re: Java for Everything

#283

Post by lmm »

edwinnathaniel wrote: post #232
lmm wrote: post #144

Earlier quoted context omitted.

> But if you take a look at how Sinatra (or Rails) serialize the returned object, you notice the duplicated code. Especially if you want to return both JSON or XML based on the request header. To add to this, both frameworks do this serialization as part of the code logic that you have to write, instead of slapping annotation once... I can't speak for Sinatra, but in Spray I'd just write a directive for this - maybe…

I've been using Jersey since 2010 and I have never need to write my own annotation. Maybe I'm lucky enough that Jersey fills my need perfectly and maybe you're right that once I needed to write my own annotation, I may run into a bit of trouble (though some people do write annotation only to be consumed by reflection, hence bypassing the service file) but I guess... that's like.. what... 1-5% extreme use-cases? Like.…

> You sound like programming in another level higher than mine. I applaud that. I'll revisit Spray/Scala _when_ I found a definitive use-case for this. For now, Java seems to fit the bill for pretty much 99% my use-cases and fit my taste as well (less low-level code stuff because it is built-in the framework that is well-architected/well-designed so that I can focus on business logic code).

Sometimes you don't need it, but there are blub-paradox cases as well; I tried to sum up a few of the things I retrospectively recognize I was missing in Java in http://m50d.github.io/2014/05/16/signs-your-java-program.htm...

A lot of it is just being able to track things in the type system that you wanted to track in Java anyway, but it seemed too hard. I mean, I've worked in Java codebases where it would have been very nice to see which methods accessed the database as part of their type. I've even seen one that used a kind of Hungarian notation to express this - in fact if I can point to a single place that set me on the road to Scala, it's http://www.joelonsoftware.com/articles/Wrong.html . Because I read that and then thought: hang on a minute, why not just make whether a String is encoded part of its type-type, the type that's enforced by the compiler?

Re: Java for Everything

#284

Post by fsloth »

pgsandstrom wrote: post #268
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…

What you argue is not that LOC in itself causes bugs, but that certain programming syntaxes are both complex (thus induces bugs) and takes up more LOC.

Oh, that I did. Very true.

Re: Java for Everything

#285

Post by fsloth »

userbinator wrote: post #267
twic wrote: post #152

Earlier quoted context omitted.

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

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 cultural pathology?

Re: Java for Everything

#286

Post by pjmlp »

lmm wrote: post #275
pjmlp wrote: post #256

Earlier quoted context omitted.

Because the whole point of the OP is being able to use the same language for the whole stack.

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 implementation saw a lot of C++ code being replaced by Java code, thanks to new JIT intrinsics.

The idea that C is the only way to implement VMs needs to die.

Re: Java for Everything

#287

Post by hvidgaard »

pimlottc wrote: post #92
jim_greco wrote: post #59

The biggest thing for me is that the tooling around Java makes maintaining large projects extremely easy. Being able to refactor hundreds of files in a few keystrokes without worry lets me sleep well at night. It's certainly a lot faster to get up and running with a dynamic language, but the initial build out is a small percentage of the overall time you are going to spend with a codebase. I've also built just about…

I think this is the key point in the debate - weighing initial development time against ongoing development and maintenance. It's something that's hard to grasp until you've been around for a while working on real-world large-scale projects. And it's a hard thing to get the sense of when you're in school, writing throwaway code that doesn't last past the end of the semester. When you understand this, then you can mak…

First to market has never ever been about using a dynamically typed language. Getting the ideas from talk to concepts, testing, bugfixing and marketing takes vastly more time than actually developing the code. So while Python might enable me to show my prototype on Monday, while that Java version wouldn't be seen until Friday, there still is quite a lot of time before you can say it's properly released.

Where these "fast" to develop languages shines are throwaway prototypes. For some people their ideas flow out much faster with dynamically typed language. But it is all too well known that even though the manager said you could throw it away, they change their mind because "it's basically finished, right?".

That said, you are spot on. Initial development is likely not where you want to focus at all, for any kind of project that needs to be maintained for more than a few months.

Re: Java for Everything

#288

Post by lucozade »

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…

This is excessive but I've seen numerous similar cases. Premature code future-proofing has always struck me as similar to premature code optimisation. Generally something that newer/weaker devs tend to do until they learn better.

Re: Java for Everything

#289

Post by vorg »

allengeorge wrote: post #262
vorg wrote: post #190

Earlier quoted context omitted.

The site at groovy.codehaus.org doesn't mention anything about the new site (actually www.groovy-lang.org). Until it does the new site is unofficial and just one of the 5 despots at Codehaus trying to grab control of the product away from the other 4 despots there. That despot has tried other tricks like soliciting for subscribers to his weekly "news mailout" which is mainly links to tweets mentioning Groovy.

Mmm. I got this from Guillaume Laforge's blog: http://glaforge.appspot.com/article/a-new-groovy-website-in-... He's one of the core groovy developers - unless he's one of those despots you're talking about?

If an old site for anything (here, groovy.codehaus.org) doesn't mention it's moving to a new site (here, www.groovy-lang.org) then I question what's going on. As for your link, it's a link to a personal blog and not an article on the Codehaus Groovy site so it's just as unofficial as the supposed new site for Groovy.

Re: Java for Everything

#290

Post by davexunit »

terryf wrote: post #279
nickbauman wrote: post #135

Earlier quoted context omitted.

False. If you use a language that's homoiconic (any Lisp), you don't need to serialize anything. The source code of the language is already in its serialzed form. You can't beat the speed of not having to do something in the first place. As an aside, no sane person would write a SOAP webservice today.

SOAP certainly sucks, but regarding your comment on using lisp as the transfer protocol is a bad idea. Data transfer protocols must be verifiable - you should basically be able to write a piece of code that parses the data input and verifies that it will not do something bad if deserialized. Given that as far as I know, Lisp is turing-complete, this task is impossible. Therefore, Lisp, while being a nice programming…

Reading an sexp isn't the same as evaling it. Just read it and manipulate the resulting tree. Lisps have templating, marshalling, and unmarshalling built-in.
Post reply on HN