Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything about Java 8

techempower.com

Post reply on HN
Print view View original

111–120 of 182 posts

Re: Everything about Java 8

#111

Post by ScottBurson »

tragomaskhalos wrote: post #77
stelonix wrote: post #29

Earlier quoted context omitted.

"But somehow a lot of people think it's OK to repurpose an operator to mean something completely different just because it's convenient. C++ being the classic example." Do you have any data to prove such assertions? A C++ STL operator chosen more than a decade ago is not enough statistical data for one to have such a narrow-minded vision and say these bold statements. Maybe you need to check all the nice C++ librarie…

There's basic language bigotry going on here: an aged internet meme declares that C++ operator overloading is bad because you can indeed, in theory, do idiotic counter-intuitive things with it. Yet the identical capability in Ruby, Scala and Haskell (inter alia) is deemed A Good Thing by the consensus.

I think it's an interesting phenomenon in the sociology of programming languages.

A powerful new feature is introduced in a niche language, and novices abuse it. The feature gets a bad reputation. Yet eventually, as new languages adopt it, the community learns how to use it and how not to use it, and people become accustomed to it, and come to agree that it's not such a bad thing.

I'd say that's happened, to some degree, with garbage collection and lambda expressions. We seem to be in the middle of the process with operator overloading, and still in the early stages with Lisp-style macros (I can hope, anyway :-).

Re: Everything about Java 8

#112

Post by mikeash »

tragomaskhalos wrote: post #104
mikeash wrote: post #81

Earlier quoted context omitted.

For me, and perhaps others, this is because C++ enshrines idiotic counter-intuitive operator overloading in its standard library.

Examples ?

The use of > for streams is the one that always comes to mind. So minor, and yet so awful.

Re: Everything about Java 8

#113

Post by mikeash »

tragomaskhalos wrote: post #103
ethzero wrote: post #91

Earlier quoted context omitted.

It's not an identical capability. Scala doesn't technically have operator overloading, it has symbolic method names and operator syntax for methods. This means you can use any valid name as an operator. With C++, you can only overload the built-in symbolic operators. This means instead of choosing the best symbolic name to use as an operator you're forced to re-purpose some built-in operator like "<<". In Scala you c…

Yes I know that, but the point is that the "operator overloading is terrible" complaint typically cites either plainly daft straw men like "what if someone overrides + to mean subtraction", or else hones in on was stupid ..) Conversely, there was an XML library for Scala posted on Reddit about a year ago that used things like as method names; clearly the freedom to concoct your own symbolic names is far more open to…

Two big problems with overloading << for streams are operator precedence (the precedence of << makes little sense for a stream operator) and the fact that the chained syntax can make the whole thing ambiguous (which is kind of a subset of the precedence problem), e.g.: cout << x << 3, does that shift x by 3, or output x and 3 separately?

Re: Everything about Java 8

#114

Post by nollidge »

thecombjelly wrote: post #74

The inclusion of lambdas is great, but not supporting full closures severely hampers their usefulness. Instead of using lambdas to use patterns like CPS (continuation passing style) or alternative object interfaces, lambdas just save you from typing extra characters. It is always fun to watch other languages continue to implement features that bring them closer to lisp. I wonder how much longer it will be until every…

> It is impressive though that they have been able to still innovate without breaking backwards compatibility.

Indeed. The .NET IL compiler actually supports closures by generating a class with the lambda's method body as method on that class. That method takes in as parameters whatever outside variables need to be captured.

It also supports iterator continuations (e.g. "yield return") by generating an entire class which inherits off of IEnumerable and wraps your single function with all the necessary trappings to track the continuation state.

You can see this stuff by looking at C# assemblies in a free program called ILSpy[0]. Normally it'll reverse-engineer these compiler patterns, but if you uncheck all the "decompile" checkboxes in the options, it'll just straight-up translate the IL to C# and you can see the dirty tricks.

[0] http://ilspy.net/

Re: Everything about Java 8

#115

Post by thecombjelly »

nollidge wrote: post #114
thecombjelly wrote: post #74

The inclusion of lambdas is great, but not supporting full closures severely hampers their usefulness. Instead of using lambdas to use patterns like CPS (continuation passing style) or alternative object interfaces, lambdas just save you from typing extra characters. It is always fun to watch other languages continue to implement features that bring them closer to lisp. I wonder how much longer it will be until every…

> It is impressive though that they have been able to still innovate without breaking backwards compatibility. Indeed. The .NET IL compiler actually supports closures by generating a class with the lambda's method body as method on that class. That method takes in as parameters whatever outside variables need to be captured. It also supports iterator continuations (e.g. "yield return") by generating an entire class w…

C# is quite impressive, especially in comparison to Java. If it had been released earlier, wasn't owned solely by Microsoft, and supported all major platforms equally, it could have been huge, even larger than Java. If C# had reversed roles with Java a significant portion of the world would have been more productive.

Re: Everything about Java 8

#116

Post by lucastheisen »

MichaelGG wrote: post #66
twic wrote: post #58

Earlier quoted context omitted.

As a Java programmer, i agree that the catch blocks around parsing are annoying, but i'm not sure a method that returns an error code is any better. Wasn't that tried back in the '80s? The way Scala (and probably other functional languages, with which i am not familiar) handle this is with a little bit of polymorphism. Using Java syntax, parsing a string into integer would return a Validation , an abstract type which…

TryParse returns a boolean. So you use it like this: int res; if int.TryParse(s, out res) { // OK } { else // not ok } You certainly do not need an exception to deal with the simple case of "did this string parse into an int". Edit: A great alternative signature is to use Maybe/Option, so you get Some int or None. match int.TryParse s with | None -> ... | Some i -> ...

is that really more work than:

  int res;
  try { res = Integer.parseInt( s ); } // if part
  catch ( NumberFormatException nfe ) { } // else part
The words are different (try/catch instead of if/else), but still 2 blocks of code with similar syntax...

Re: Everything about Java 8

#118

Post by actf »

mbell wrote: post #94
gjulianm wrote: post #13

As a C# developer now experimenting with Java, I still miss some things even from Java 8. Probably some have technical reasons behind, but... - Getters and setters, C# style. That is, instead of private int foo; public int getFoo() { return foo; } public void setFoo(int value) { foo = value; } write this: public int Foo { get; set; } which is both easier to write and makes code more readable and understandable. - Man…

> Getters and setters, C# style. That is, instead of I just stopped using getters and setters all together unless I have a real use for them. The most common reasons are: because they are required by some third party library or they are the external interface for whatever the module of code is doing. For all internal classes, if the field needs external access, just make it public. Most of the arguments I hear for us…

I really disagree that C# getters and setters are less readable than a public field. Compare:

   public string Field { get; set;}
to

   public string field;
I felt I had to reply to this comment to discourage this practice for a couple of reasons:

1) By convention anyone reading your code will think this is very strange, and it will force them to spend additional time reading your code to understand why you are breaking such a strong convention.

2) Using properties really will make your life easier when you need to track down a state change in your program. Detecting a state change on a public setter is a lot easier than detecting state change on a public field.

3) In C#, at least, using public fields where you should be using public properties will make creating an interface on existing code significantly more difficult - as interfaces can only define public properties, and not fields.

In short please don't do this. It's really bad practice just to save a couple extra characters, and if I inherit your code someday I'll probably want to strangle you.

Re: Everything about Java 8

#119

Post by trailfox »

thecombjelly wrote: post #115
nollidge wrote: post #114

Earlier quoted context omitted.

> It is impressive though that they have been able to still innovate without breaking backwards compatibility. Indeed. The .NET IL compiler actually supports closures by generating a class with the lambda's method body as method on that class. That method takes in as parameters whatever outside variables need to be captured. It also supports iterator continuations (e.g. "yield return") by generating an entire class w…

C# is quite impressive, especially in comparison to Java. If it had been released earlier, wasn't owned solely by Microsoft, and supported all major platforms equally, it could have been huge, even larger than Java. If C# had reversed roles with Java a significant portion of the world would have been more productive.

C# 1.0 was very close to being an exact copy of Java. To say that if C# had been released before Java it would have been more popular is nonsensical as it started life as copy-cat Java. Without Java there wouldn't be a C#. Later versions of C# added more features much faster than Java. Many Java developers have since moved on to Scala and other JVM languages which are more expressive than C#.

Re: Everything about Java 8

#120

Post by johnyzee »

smrtinsert wrote: post #89
krg wrote: post #12

Earlier quoted context omitted.

I'm not sure what you mean exactly, but as mentioned in the article they've built a new JavaScript engine (to replace Rhino) to be included in Java8: http://openjdk.java.net/jeps/174

Just that an entire revolution is happening in the browser itself, I'd really like to be able to code Java directly with something GWT. I read recently that GWT has support for the latest html5 stuff, but complaints about compile time and lack of performance after compilation turn me off...

You should give GWT a go. Compile time is a valid complaint, though it can be mitigated by only producing a single permutation (browser specific output) while in development, rather than the default five-six. Also note that during development you usually don't compile but run in "dev mode", a browser plugin that runs against your actual Java code.

Performance after compilation is certainly not a problem, on the contrary the GWT output is very tight, especially with full obfuscation (aggressive optimizations, inlining etc.).

(I've written a complete HTML5 game engine in GWT: http://www.webworks.dk/enginetest)

Post reply on HN