Live data from Hacker News

Hate Java? You’re fighting the wrong battle.

javacodegeeks.com

181–186 of 186 posts

Re: Hate Java? You’re fighting the wrong battle.

#181
post #179

Earlier quoted context omitted.

If you're comparing to Python (which is stable but hella slow) or Ruby (which tends to be both unstable and slow), GHC stacks up pretty well. By "production systems", I was mostly referring to the sort of things that are normally written in Java or C++ - Google-scale server farms, or financial transaction systems. You really want predictable execution behavior in those systems. You want to be able to look at a graph…

I see -- that all makes perfect sense. Thank you! However, you're still suggesting that Haskell is only good for prototyping, not for "real apps", which understandably for you are Google-scale apps. There is a very long distance between what Google does and what I need to do, today, and premature scaling is the death of many projects. But let's be ambitious and pretend that one day I will want to operate at that scal…

Assuming C++ is out of the running, the alternative to Java is basically Scala. And that's it. Maybe Go will be an alternative in the eventual future, but right now it lacks the library & tool support.

There's also nothing wrong with writing your v1 in one language and then rewriting in a different one if you need to scale. You will probably need to do this anyway, even if you start in C++ or Java, because the architecture needed to scale by an order of magnitude is usually very different from the architecture needed to iterate quickly.

Re: Hate Java? You’re fighting the wrong battle.

#182
post #170

Earlier quoted context omitted.

Oh, I think that nearly all of the problems with Haskell could be fixed up if it had the resources of C++ or Java. The problem is that in getting those resources, it would create new problems that would end up looking a lot like the whining about C++ or Java. Java, as a language and a platform, is not fundamentally that bad. It was certainly done by very smart people with lots of experience. It sucks because it has s…

> The flip side of this is that if you suddenly use one more field in a tuple, way down the line in some unrelated portion of the code, you might trigger a very expensive computation. This is unacceptable in many large apps written by multiple people; you shouldn't have to worry that a tiny field reference can bloat the program's memory consumption by orders of magnitude. No matter what language you use if you want t…

But other languages give you a syntactic cue that what you're doing might be potentially expensive - it's a function call. That's why most language styleguides have a naming convention for accessors, so you can distinguish between method calls that are basically free vs. method calls that might be expensive.

In Haskell, every single token might trigger a long computation, so it's very easy to introduce something that wildly changes the performance characteristics of the program.

Re: Hate Java? You’re fighting the wrong battle.

#183
post #170

Earlier quoted context omitted.

> The flip side of this is that if you suddenly use one more field in a tuple, way down the line in some unrelated portion of the code, you might trigger a very expensive computation. This is unacceptable in many large apps written by multiple people; you shouldn't have to worry that a tiny field reference can bloat the program's memory consumption by orders of magnitude. No matter what language you use if you want t…

But other languages give you a syntactic cue that what you're doing might be potentially expensive - it's a function call. That's why most language styleguides have a naming convention for accessors, so you can distinguish between method calls that are basically free vs. method calls that might be expensive. In Haskell, every single token might trigger a long computation, so it's very easy to introduce something that…

Hmm I have come across many a codebase in countless languages where there was no way to discern that type of information from the naming convention. Even accessors in say C# or Java are perfectly legit to do any side effect they want. In fact I think it is worse in those situations - because side effects are not modeled. Indeed, no language has found a way to model non-termination in the type system, hence the halting problem.

Honestly I just haven't experienced this very often in Haskell... When I do it is usually a 'doh moment and a simple fix.

Re: Hate Java? You’re fighting the wrong battle.

#184

Earlier quoted context omitted.

But other languages give you a syntactic cue that what you're doing might be potentially expensive - it's a function call. That's why most language styleguides have a naming convention for accessors, so you can distinguish between method calls that are basically free vs. method calls that might be expensive. In Haskell, every single token might trigger a long computation, so it's very easy to introduce something that…

Hmm I have come across many a codebase in countless languages where there was no way to discern that type of information from the naming convention. Even accessors in say C# or Java are perfectly legit to do any side effect they want. In fact I think it is worse in those situations - because side effects are not modeled. Indeed, no language has found a way to model non-termination in the type system, hence the haltin…

[deleted]

Re: Hate Java? You’re fighting the wrong battle.

#185

Earlier quoted context omitted.

Mono doesn't get close to .NET, even in versions and in implemented functionality, there's always missing something. Writing a serious web application in asp.net is not the same as writing a serious web application in mono.

"...always missing something" Such as?

You can see that here: http://mono-project.com/Compatibility

Re: Hate Java? You’re fighting the wrong battle.

#186
post #111

Earlier quoted context omitted.

The interesting thing about Blub programmers is that they do not know they are Blub programmers. Even more interesting: Even those who know about the above phenomenon and make meta-comments on it are Blub programmers and do not know that they don't know this.

I am a Haskell programmer, and aware of the more powerful abstractions available in Agda and similar languages. So I am aware of my Blubness :-) But I try to keep up to date with regards to PL technologies, so I think I'm closer to the top of the contemporary Blub ladder, but I guess any Blub programmer might think that!

Darn iPad! That was meant to be

My Blub is Smalltalk, and I'm proud to claim it as such.

Post reply on HN