Live data from Hacker News

Modern Java – A Guide to Java 8

github.com

161–170 of 203 posts

Re: Modern Java – A Guide to Java 8

#161

I personally jumped right into Clojure on the jvm without much Java experience. I've found it to be awesome. Is there a non-political reason that someone should choose Java over Clojure (or possibly Scala)? Where does Java shine?

IMO Java doesn't shine anywhere. It's statically typed, but lacks support to be flexible. Thus many Java programs rely on reflection at runtime or casting. This negates all of the benefits of static typing, turning the language into a dynamic one.

The main choice is then either Clojure or Scala. This comes down to dynamic versus static type checking. With a dynamic language, one is significantly less sure if a program is correct. In large programs that use dynamic languages, many tests must be created that are essentially doing the work that a type checker in a static language would do automatically.

In a static language, entire classes of bugs are eliminated. Scala provides the best support for strong, static typing on the JVM.

Re: Modern Java – A Guide to Java 8

#162
post #142

Earlier quoted context omitted.

Hear hear. A couple more features that'd be nice: - An `public Optional or(Optional other)` so if optA is empty, then `optA.or(optB)` would return `optB` - A `toStream` method on `Optional` (I believe this is coming in Java 9) or have a `Stream.flatMap` signature that flattens `Optional`s without needing to call `Optional.toStream` (Scala does this, arguable if this is an acceptable munge of Monadic types, but it's r…

Check out fugue: https://bitbucket.org/atlassian/fugue -- a proper monadic Option and more. :) (Full disclosure: I'm an Atlassian and I know/<3 the people who write it, but I also use it a fuckton in my own code.)

Yea this library with Java 8 makes functional style java actually kinda nice. The addition of an Either really opens up what you can do.

Re: Modern Java – A Guide to Java 8

#163
post #155

Earlier quoted context omitted.

Yeah, I don't know. Java developers need IDEs like Rob Ford needs crack cocaine, but it's more a comment on the deficiencies of the language than the purported benefits of an IDE.

IDEs were created for Interlisp-D, Smalltalk and Mesa/Cedar. Were popularized in the PC, Amiga and NeXT eco-systems, thanks to Turbo Pascal, Delphi, VB, AMOS, GFA, Objective-C, Eiffel, Oberon, ... Java wasn't even a thing in those days.

That's not the point. Due to its verbosity, it's impractical to use Java without an IDE. That's not necessarily the case for more compact languages.

Re: Modern Java – A Guide to Java 8

#164
post #79

Earlier quoted context omitted.

Java lambdas are no different than an anonymous Runnable or Callable. It's just nicer syntax.

> It's just nicer syntax. Which is mostly the point. Ultimately, everything is no different from .

Exactly. Everything is just syntax sugar over 0s and 1s :)

Re: Modern Java – A Guide to Java 8

#165
post #159

Earlier quoted context omitted.

I never understood the following : Eiffel had a better syntax, better support for core issues, Void type, design by contract, multiple-inheritance and an intermediate virtual machine for portability although the most common target was C code. To name a few. I was using Eiffel in a small side project just about when Java released their 1.1.4 (a version before the object serialization library, iirc). It was a sticking…

Syntax is not a big deal. Ideally it should be small. If you don't like java, please don't use it. move on. Why create ugliness in java?

Typesystem is not the same as syntax? I dont believe raising ugliness in syntax as an issue. Of course, I do mention the ugliness in Haskell and that is in special cases where the overhead of boxing is significant. So, yeah, we could move on, but I think that is a specious argument. I guess one could really move on, till we start seeing Scala embrace Uniform Access Principle or Java embrace lambdas (implicitly or explicitly) to support generics. So, what it seems to me is that you are ok with a bad language design and accept the weakness of the language because it was delivered and also accept that like any working document there could be amendments and that is part of working in a programming language. Moreover, the principles of language design that I list were available as prior art, so it is not clear as to why Java language designers decided to at least not refer to it during design. Anyway, my intention was not to start a flame war? Note: Regarding : "why create ugliness in Java?" Any reason for an ad homenim attack? or was it a general rant? Since we are on hacker news I would like to give you the benefit of doubt :).

Re: Modern Java – A Guide to Java 8

#166
post #117
post #92

My Java code has improve dramatically since I started (ab)using Optionals. String foo = Optional.ofNullable(paramater) .filter(...) .map(a -> ...) .map(b -> ...) .orElseGet(() -> ...) .orElse(defaultValue) Between this kind of thing, and similar playing with Streams, some of the ugliest code I work with is suddenly quite clear, coherent, understandable.

I'm not so up on Java, could someone explain why they chose "->" for lambdas instead of the "=>" that C# and ES6 use, as those languages seem to me like they would be the first place to look for inspiration.

I'm not an expert. C++ uses -> for pointer dereference, e.g. o->p refers to the property "p" of object "o". I would assume C# inherits from C++ and had to define another operator.

Java probably followed Scala's notation, which is probably derived from mathematics where ↦ is an application (a function) and ⇒ is a simple logical implication.

Re: Modern Java – A Guide to Java 8

#167
post #155

Earlier quoted context omitted.

IDEs were created for Interlisp-D, Smalltalk and Mesa/Cedar. Were popularized in the PC, Amiga and NeXT eco-systems, thanks to Turbo Pascal, Delphi, VB, AMOS, GFA, Objective-C, Eiffel, Oberon, ... Java wasn't even a thing in those days.

That's not the point. Due to its verbosity, it's impractical to use Java without an IDE. That's not necessarily the case for more compact languages.

Programs are written once, read multiple times.

Re: Modern Java – A Guide to Java 8

#168
post #65

Earlier quoted context omitted.

Java's way of expressing variance is really awkward (even quite popular libraries get their types wrong as a result), arrays are special-cased into unsoundness, Serializable is a total mess where it could be a perfect example of how to use a type system, there are no higher kinds, the exception system is like a second parallel type system (it even has union types, which would be incredibly useful if you could use the…

> Comparable returns an int for what should be a 3-value enum. To be fair, I can think of another functional language starting with "O" guilty of exactly the same thing...

I was about to refute your argument by proposing creating a union type. Here is a relevant reference: https://realworldocaml.org/v1/en/html/functors.html

(This idiom is a bit of a historical error. It would be better if compare returned a variant with three cases for less than, greater than, and equal. But it's a well-established idiom at this point, and unlikely to change.)

Eiffel is similar to ocaml : http://www.infor.uva.es/~felix/referencia_smart_eiffel/libra...

Does anyone know the advantages of the above signature over the Haskell alternative? Because this seems to be more obvious and easier to read. So there are more than one language guilty of using a ternary operator for compare.

Haskell does define the appropriate constructors, rightly so: https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-O...

data Ordering :: *

Constructors LT EQ GT

Re: Modern Java – A Guide to Java 8

#169
post #92

My Java code has improve dramatically since I started (ab)using Optionals. String foo = Optional.ofNullable(paramater) .filter(...) .map(a -> ...) .map(b -> ...) .orElseGet(() -> ...) .orElse(defaultValue) Between this kind of thing, and similar playing with Streams, some of the ugliest code I work with is suddenly quite clear, coherent, understandable.

Two .map-s one after another is code smell (and also a bit slow). Why not combine them into one?

Do standard collections have groupBy? You can go a long way with groupBy and zipWith operations, which are a pair like map-reduce but for in-memory handling.

Re: Modern Java – A Guide to Java 8

#170
post #141

Earlier quoted context omitted.

Does that really look better to you? More understandable? Methods with the word "and" in them are really awful smells to me too. Comparing your code and mine, I ask you this: which one do you thing is more maintainable after 5 years of edits? Each time a new developer needs to add a new case, a new rule, a new whatever, on my Optional (ab)usage, they just add a new line in the appropriate spot, a .filter or a .map or…

Java does not have a full FP story, so to bastardize newer code as though it does becomes unreadable IMO. The "and" was just for the example, since "..." wouldn't have made it clear. I do not find it more readable personally, but that is a personal opinion. Because other code eagerly returns (doesn't usually bother me in an imperative language) is a different problem with code path complexity that can be addressed el…

I don't disagree that FP doesn't feel complete in Java yet. But that doesn't mean I'm not totally willing to start playing with what I've got!

The biggest worry I have right now is the story on debugging code with Optional bastardized FP. I know I'm going to learn some lessons soon enough, lol.

Post reply on HN