Live data from Hacker News

Eclipse launches new language to cut down Java boilerplate - Extend

eclipse.org

71–80 of 229 posts

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#71
post #49

Earlier quoted context omitted.

There is nothing wrong with optional semi-colons. In most cases, the parser doesn't need them, and the programmer doesn't want to type them. But they're useful in some cases for disambiguation, especially in a language like Xtend that doesn't use an explicit return. E.g. foo("bar") ; (a + b) The semicolon is necessary for disambiguation in a case like this, but there is no reason to require the programmer to put in s…

"The semicolon is necessary for disambiguation in a case like this..." This is why semicolons should be mandatory or illegal. The whole "optional semicolon" thing is a mis-feature designed by language committees that can't make a decision. One's codebase becomes a mismash of lines with and lines without semicolons, sprinkled in as magic to make the compiler happy. There are plenty of interesting language features whi…

We should also use a fully-parenthesized prefix syntax so we don't get a mishmash of lines with and without parentheses used to override operator precedence!

I agree Javascript's "automatic semicolon insertion" is a terrible feature, but largely because the description is so hard to understand that programmers don't know when the semicolon is required.

In an expression-oriented language, like Xtend seems to be, the rule for when you need a semicolon is simple. The parser makes the longest legal expression it can, if that's not what you mean, then add a semicolon. It's no harder to understand than the lexer equivalent (the lexer makes the longest token you can, if you want to resolve the ambiguity insert a space), or the operator precedence rule (the parser will interpret infix operations using this precedence table, if that isn't what you mean use parentheses).

Matlab, for example, doesn't require commas to separate list elements, and doesn't require but allows semicolons at the end of lines, and nobody complains.

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#72
post #6

yet another Scala

Scala has a time to market and a perception problem. Look for Kotlin to be the Scala that Scala never will be.

I don't know what your beef with Scala is, but you're seriously deluded.

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#73
post #61

Operator overload would be nice. But I don't think declaring variables whose type can be inferred from the right side of the attribution, semicolons or parentheses for parameterless methods are the biggest problems with Java.

Isn't that restricted by the JVM?

It's syntax. You could simply define a rule that the compiler, when facing objects that do not natively (as in vanilla Java) support operator X would have the .operatorX method used instead.

The JVM would never know.

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#74
post #56

Granted Im not the target market, but Implicit returns do not seem like a good idea.

Yeah, is there precedent for that? It looks fucking nutty. Can you do it in the middle of the function!? So odd. There's a lot of cruft in java, but I'm not sure the return statement is even on the list of things I'd bother attacking.

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#75
post #66

Earlier quoted context omitted.

> for obvious reasons As someone from outside the Java universe, I'd like to learn more about those reasons and why they are obvious.

The vast majority of Java developers are very, very comfortable with static typing and the most advanced IDEs in software development. Clojure with its s-expressions and dynamic typing is going nowhere except for some small, high-brow teams...just the way it is. Scala lost its opportunity a while back with its perception problem and lack of IDE support.

Can you please explain the Scala's perception problem?

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#76
How can we honestly accept anything coming from the people who gave us eclipse? What a giant stinky pile of pooh that turned out to be.

I think that the current stewards of the java language are actually going down the most helpful/likely to succeed path to helping fix java by fixing java. What a novel f-ing concept. As much as it can be anyway, and despite the serious reservations of the giant doucheball they inherited with most of oracle. (despite Larry himself possibly being a pretty cool/legit engineer himself)

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#77
post #25
post #14

Parenthesis for method invocations are optional, if the method does not take any arguments. obj.compute instead of obj.compute() That seems silly. The optional semicolons also irritate me. ----------------- (Added) I imagine a committee of Java developers, in a penthouse boardroom at Oracle, meeting with management to discuss Java's descent into disuse. "Lets make Java more concise," suggests a senior developer. "Yes…

That's what Scala already does: if a method does not take any args then the parentheses aren't necessary. To quote Odersky: "This convention supports the uniform access principle which says that client code should not be affected by a decision to implement an attribute as a field or method." It makes sense if you want to implement something that may be a field but needs to be computed.

How do you differentiate between referencing a method, and calling the method? I.e., foo.Sort(x.compare)?

I think the idea of computed fields implemented via methods is better represented via C#-style properties, although I'd prefer to be able to access their methods directly, when suitable.

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#78
post #49
post #14

Parenthesis for method invocations are optional, if the method does not take any arguments. obj.compute instead of obj.compute() That seems silly. The optional semicolons also irritate me. ----------------- (Added) I imagine a committee of Java developers, in a penthouse boardroom at Oracle, meeting with management to discuss Java's descent into disuse. "Lets make Java more concise," suggests a senior developer. "Yes…

There is nothing wrong with optional semi-colons. In most cases, the parser doesn't need them, and the programmer doesn't want to type them. But they're useful in some cases for disambiguation, especially in a language like Xtend that doesn't use an explicit return. E.g. foo("bar") ; (a + b) The semicolon is necessary for disambiguation in a case like this, but there is no reason to require the programmer to put in s…

Sorry for not understanding, but can you explain what the ambiguity is here?

Re: Eclipse launches new language to cut down Java boilerplate - Extend

#79
post #16
post #6

yet another Scala

It's not just Scala, it's Groovy, BeanShell, Factor (JFactor now), Fantom, Frege, Kotlin, Ceylon, Stab, Gosu, Mirah, and that's not counting all the ported versions of Ruby, Python, Lisp (Clojure) and so on. What you haven't written a JVM language yet? It used to be you weren't a proper programmer until you'd gotten fed up and written your own CMS or web framework. Now I guess everyone has to have their own programmi…

Sidenote: JFactor is an outdated implementation and I haven't heard anything about it being revived. Factor has compiled to native code for years now.
Post reply on HN