An Opinionated Guide to Modern Java Development, Part 1 • Hacker News Board

Re: An Opinionated Guide to Modern Java Development, Part 1

#381

Post by lmm » Sat, May 03, 2014, 1:25 PM UTC

zak_mc_kracken wrote: post #274

emsy wrote: post #193

Earlier quoted context omitted.

For starters, you can see Groovy as "Java without semicolons". I went from Maven to Gradle and never looked back. It's superior in most ways. The tooling could be better though.

> you can see Groovy as "Java without semicolons I see it as "Java without types", myself. I'm aware that Groovy now supports optional typing but if I'm going this path, I prefer to switch to Kotlin, which I describe as "Java with everything that's bad removed".

If that's what you want wouldn't Ceylon be a better choice? If you're still using the Java standard library you still have the billion dollar mistake (null) everywhere.

Re: An Opinionated Guide to Modern Java Development, Part 1

#382

Post by virtualwhys » Sat, May 03, 2014, 2:03 PM UTC

the_af wrote: post #379

virtualwhys wrote: post #375

Earlier quoted context omitted.

There's no need to be disappointed in Scala's Option, if used sensibly (i.e. not intentionally trying to break it) Option will work as advertised. val is indeed king, var is used sparingly, look under the hood of any prominent Scala library and you'll see val-ue of immutability put into practice. Locally scoped vars can be useful, but beyond that dangers waits (not unlike Haskell's unsafePerformIO). In terms of disap…

Fair enough. I don't believe Option is only broken when "intentionally trying to break it". Of course, my example is trivial and the null is explicit. But what if it was a call to a Java method that shouldn't return null, but does because of programmer carelessness? I agree there are pain points with Haskell as well, no language is perfect. But slow compilation... surely you're kidding when you don't see this as a pr…

Reason appears ;-)

When calling a Java method assume a null return and wrap it up in an Option just as you'd do with Haskell when interfacing with the "outside" world.

As for Scala compilation speed, Haskell's not gonna win that battle, ghc is to scalac as scalac is to javac, which is to say, the last is first and the first is last in terms of compilation speed. Also, IIRC only Yesod provides incremental builds, no? With SBT incremental builds most code changes incur a As for the IDE story, the secret to a performant Scala IDE is to turn off automatic builds in Eclipse and let SBT run the show. With the SBT eclipse plugin there's a setting that allows SBT compilation target and Eclipse target to be shared so you never have to clean/build in Eclipse -- this is a huge win, the difference between standard dog slow Eclipse performance, and snappy, oh this is real nice if only the haters knew, joy ;-)

Re: An Opinionated Guide to Modern Java Development, Part 1

#383

Post by brown9-2 » Sat, May 03, 2014, 2:09 PM UTC

mateuszf wrote: post #209

stevoski wrote: post #159

Earlier quoted context omitted.

Not quite. eg: public final Date date; date.setTime(1); That's not immutable.

Yep, the thing is that Date is immutable. I think that this public final immutable rule is ok, but one has to ensure the fields themself are really not modifiable.

A class with mutable fields that a caller can mutate is not immutable.

Re: An Opinionated Guide to Modern Java Development, Part 1

#384

Post by zenbowman » Sat, May 03, 2014, 3:18 PM UTC

pkolaczk wrote: post #365

zenbowman wrote: post #362

Earlier quoted context omitted.

In some categories, yes. In many others, especially those requiring vector or matrix arithmetic (medical imaging, physical simulations, modeling, graphics, scientific computing, video games), there's simply no competition.

Not sure of that. Some scientists from CERN would certainly disagree... Pure array-based arithmetic in Java is pretty damn fast, especially if you care to avoid dynamic allocations. It can be also very memory/cache friendly.

I was under the impression CERN was a C++ shop, have they switched over to Java?

Re: An Opinionated Guide to Modern Java Development, Part 1

#385

Post by lomnakkus » Sat, May 03, 2014, 4:08 PM UTC

eeperson wrote: post #233

lomnakkus wrote: post #225

Earlier quoted context omitted.

Thank you, I haven't actually tried that. I really live the "I just want my IDE to work" philosophy (out of laziness), so I try to avoid configuration if I can. :) About monadic style: I realize that it's a hard sell, but it's basically about leveraging for comprehensions (aka. do-notation) to specify your build. Shake is an example of this, although probably not particularly suited to building Scala code.

Shake?

Sorry, should've linked[1]. There's also a further link from there to a paper for your reading pleasure :).

[1] http://hackage.haskell.org/package/shake

Re: An Opinionated Guide to Modern Java Development, Part 1

#386

Post by grkvlt » Sat, May 03, 2014, 4:09 PM UTC

twistedpair wrote: post #11

bsaul wrote: post #6

I'm back to java after having an unsatisfying experience 2 years ago with Spring MVC, (this time i use the "play framework"), and it seems to confirm my intuition that the language itself is really just fine. The problem lies more in bloated frameworks and corporate culture where everything needs to be standardized, regulated, and the purpose of a mandatory non-free training session. Add to that the fact that every s…

How's Play! compare to Spring? I'm working on a bloated Spring whale (1.5M LoC, 485 Spring XML config files) and wondering if something like Play! can do it better, or if complexity is simply a beast that will inevitably turn any project into a turgid mass. I ask since friends at Google will laugh at a bar if you even say "Spring," but I'm curious what else can do it all (Guice/Gin?). Perhaps nothing can and the tric…

Note that Play is only really comparable to Spring MVC, it's not a general-purpose dependency-injection framework. In the DI space Guice is more of a competitor to Spring.

Re: An Opinionated Guide to Modern Java Development, Part 1

#387

Post by pkolaczk » Sat, May 03, 2014, 6:28 PM UTC

zenbowman wrote: post #384

pkolaczk wrote: post #365

Earlier quoted context omitted.

Not sure of that. Some scientists from CERN would certainly disagree... Pure array-based arithmetic in Java is pretty damn fast, especially if you care to avoid dynamic allocations. It can be also very memory/cache friendly.

I was under the impression CERN was a C++ shop, have they switched over to Java?

They do have quite a few projects in Java and they published some of their Java scientific libraries as open source. See Colt project. Also the software processing data from LHC is at least partially Java based.

Re: An Opinionated Guide to Modern Java Development, Part 1

#388

Post by the_af » Sat, May 03, 2014, 7:36 PM UTC

virtualwhys wrote: post #382

the_af wrote: post #379

Earlier quoted context omitted.

Fair enough. I don't believe Option is only broken when "intentionally trying to break it". Of course, my example is trivial and the null is explicit. But what if it was a call to a Java method that shouldn't return null, but does because of programmer carelessness? I agree there are pain points with Haskell as well, no language is perfect. But slow compilation... surely you're kidding when you don't see this as a pr…

Reason appears ;-) When calling a Java method assume a null return and wrap it up in an Option just as you'd do with Haskell when interfacing with the "outside" world. As for Scala compilation speed, Haskell's not gonna win that battle, ghc is to scalac as scalac is to javac, which is to say, the last is first and the first is last in terms of compilation speed. Also, IIRC only Yesod provides incremental builds, no?…

I'll try that, thanks for the recommendation!

Re: An Opinionated Guide to Modern Java Development, Part 1

#389

Post by frowaway001 » Sun, May 04, 2014, 12:07 AM UTC

the_af wrote: post #378

roryokane wrote: post #374

Earlier quoted context omitted.

Scala needed to support null somehow in order to interoperate with arbitrary Java code, such as passing null as a parameter to a third-party Java library. So at least some variables should be allowed to have null. Maybe they couldn’t think of a way to prevent Option-typed variables from being null without preventing arbitrary Java interop. Making only Option types reject nulls might have been thought too hacky. Those…

Oh, I understand why null was needed (backwards compatibility, like you said), and I'm no language designer, so I don't know what I would have done instead. Maybe mark pieces of code that must interact with Java code with "unsafe" blocks, outside of which no nulls can escape? unsafe { ... } Don't know if this would work. I'm just disappointed because this slightly breaks the Option type, that's all.

> I'm just disappointed because this slightly breaks the Option type, that's all.

I have never ever seen this happening.

The complaint feels a lot like "well, someone could use reflection and change the cached values of Integer, why don't you check that every time something returns an Integer?" to me.

null is the sad fact of running on the JVM, but pretending that it doesn't exist works 99.9999% of the time in Scala.

Re: An Opinionated Guide to Modern Java Development, Part 1

#390

Post by the_af » Sun, May 04, 2014, 1:14 AM UTC

frowaway001 wrote: post #389

the_af wrote: post #378

Earlier quoted context omitted.

Oh, I understand why null was needed (backwards compatibility, like you said), and I'm no language designer, so I don't know what I would have done instead. Maybe mark pieces of code that must interact with Java code with "unsafe" blocks, outside of which no nulls can escape? unsafe { ... } Don't know if this would work. I'm just disappointed because this slightly breaks the Option type, that's all.

> I'm just disappointed because this slightly breaks the Option type, that's all. I have never ever seen this happening. The complaint feels a lot like "well, someone could use reflection and change the cached values of Integer, why don't you check that every time something returns an Integer?" to me. null is the sad fact of running on the JVM, but pretending that it doesn't exist works 99.9999% of the time in Scala.

I know I'm beginning to sound like a broken record, but "I have never seen this happening" is a poor argument when discussing type systems. Please realize that "I've never seen a type bug like this happen" is exactly what proponents of dynamic typing will say when dismissing the burden of static typing: "I've never seen a bug caused by incorrect types. It sounds nice in theory and in your contrived examples, but in practice type errors never happen to me, therefore I don't want a type system that gets in the way."

The fact is that type system should NOT allow an Option val to be null. That's what type systems are there for. If a Scala programmer coming from a Java background wants to use null in Scala programs, the compiler will happily allow it. This is awful practice in Scala, of course, but it's allowed without warning. I've seen this happen with amateur Scala devs (and I'm ready to admit I'm an amateur with Scala too, I don't want to sound condescending).

Your remark that "null is the sad fact of running on the JVM" was what I was saying all along. Am I allowed to express disappointment that Scala's type system is compromised because of this fact?