Live data from Hacker News

Eclipse launches new language to cut down Java boilerplate - Extend

eclipse.org

81–90 of 229 posts

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

#81
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.

Functions in mathematics sets a good precedent for lack of a return keyword.

Where did you see that it says you can do it in the middle of a function? I understood it implicitly returns the last expression.

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

#82
post #46
post #39

Earlier quoted context omitted.

The biggest issues are less about syntax and more about having to restart containers etc again and again. But everyone except Play! and a few others seems to be jumping the new syntax bandwagon. Being a php/python/Java developer I'm afraid I'd trade all improvements after generics for a no restart required jvm

Depending on why you're restarting your VM, you may want to check out the DCEVM: http://java.net/projects/dcevm It lets you do arbitrary hotswapping of code, rather than only swapping method bodies. Not appropriate for production at this point, but you can install it on top of any Java 6 version prior to update 26 (not sure about Java 7); it's pretty useful for doing rapid iterations during development of large-scale…

Does anyone have the documentation or tutorial for DCEVM? I've looked at it from time to time but never able to figure out how to use it. There's no doc beside the jar file.

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

#83
I don't know, but, often get irriated by the usage of "closures" when it means "anonymous function/expression".

  > The term closure is often mistakenly used to mean anonymous function. This is probably because most languages implementing anonymous functions allow them to form closures and programmers are usually introduced to both concepts at the same time. An anonymous function can be seen as a function literal, while a closure is a function value. These are, however, distinct concepts. A closure retains a reference to the environment at the time it was created (for example, to the current value of a local variable in the enclosing scope) while a generic anonymous function need not do this.

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

#85
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…

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

A C-like parser will keep parsing an expression as long as it's legal. Take:

    foo("bar") * a
It will parse the call to 'foo', then see the '*' which is an infix operator and parse the whole thing as a multiplication expression. In most C-like languages, '(' is both a prefix operator (for grouping) and an infix operator (for function calls). So:

    foo("bar") (a + b)
Is ambiguous if you don't require semicolons to separate expressions. The parser will parse the call to foo, then see the '(' and parse that as a call to the value returned by 'foo'. To stop that, you use the semicolon to stop parsing one expression, so the next '(' is treated as a prefix operator.

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

#86

Good use of Twitter's css framework, bootstrap. Makes it much easier to launch a website with a decent UI without too much thought.

I noticed how they literally took the bootstrap front page and changed a few images and the text. Fast indeed. http://twitter.github.com/bootstrap/

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

#87
post #26

I wish they'd taken it just a little further and made surrounding brackets optional (using indentation instead). I.e. def greetABunchOfPeople(List people) people.forEach println(sayHello)

Further!

  greetABunchOfPeople List people
    pers:people
      println pers.sayHello

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

#88
post #31
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…

Talking about cargo cult, they added "def" to function definitions making it more verbose actually.

Seriously, I was thinking, WTF? Increased verbosity and then it isn't even a full word like "define", it's verbose and then abbreviated. Are they just trying to make Javathon at any price?

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

#89

I don't know, but, often get irriated by the usage of "closures" when it means "anonymous function/expression". > The term closure is often mistakenly used to mean anonymous function. This is probably because most languages implementing anonymous functions allow them to form closures and programmers are usually introduced to both concepts at the same time. An anonymous function can be seen as a function literal, whil…

Agreed. As I've written here previously:

http://news.ycombinator.com/item?id=2303548

A longer explanation:

http://news.ycombinator.com/item?id=2851446

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

#90
post #25

Earlier quoted context omitted.

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.

You'd use an underscore to form a partially applied function:

    foo.Sort(x.compare _)
And Scala's getters and setters are essentially equivalent to C#'s properties:

    class A {
        private var _x = 0
        def x = _x
        def x_=(value: Int) { _x = value }
    }

    val a = new A
    a.x = 5
    println(a.x)
Post reply on HN