blackdrag · HackerTrans

11 ปีที่แล้วdiscuss

We have not been looking for a new governance structure, that's right. That comes in the package with moving to Apache.. as would have been if we had moved to Eclipse. Moving off Codehaus had happened at that point already in several aspects. There was only JIRA, mailing lists, web page as well as a git repo mirror on Codehaus. github because of pull requests, distributions moved away because Codehaus exchanged rsync with webdav making releases take a full day, CI moved because the sponsored server allows us to test against the newest Java directly from the repository and so on.

blackdrag

11 ปีที่แล้วdiscuss

Groovy moved from Codehaus to Apache because Codehaus was shut down. This has nothing to do with Pivotal at all. And maybe I get the word retrenched wrong, but it was not a simple reduction of people working at Groovy, it was a full layoff, and out of about 7 people involved with grails and groovy only the eclipse guy stays, because he also works on other things. But afaik Pivotal did not pay anything to Codehaus at any time.

As for Android... you can really make Android application in Groovy now. And the NY Times guys really did/do (don't know the current state) use it for the actual app.

blackdrag

11 ปีที่แล้วdiscuss

vorg, some corrections for you. Only 2 of 6 did go to OCI. Another 2 did go to Gradle. And then about Alex Groovy++. At least you are not spreading the false rumors anymore that the codebase was copied. I have not seen any original ideas in Groovy++. So what exactly has been duplicated? Plus, Groovy's static compiler uses flow typing, Groovy++ not. It has a big impact. How can you call this duplication at all? That is as much duplication as Java is a duplicate of C.

And I actually think you belittle Alex with your focus on Groovy++. Alex best work on Groovy was the introduction of callsite caching. That was his best and biggest work. In terms of features of the language there are surely numerous other things. But they are sources of trouble. And that is because he did never finalize his work. Instead he always wanted to have new things and added half-done code to Groovy. That goes for the stub based compilation, for mixins, for many of his internal changes. I could make a really long list. Most of these things have been a huge step forward and a huge source of trouble.

blackdrag

11 ปีที่แล้วdiscuss

there is one thing you can be very happy about... there is no Project Lead in Apache Projects, right?

blackdrag

12 ปีที่แล้วdiscuss

vorg (aka Gavin), can you proof your 2011 statement about the duplication? Neither was there a copy&paste, nor is there a big overlap in concepts that goes beyond what these would have in common with javac for example.

And another thing... Grails has nothing to do with Groovy on Android. And thanks to some fixes I did with Cedric you don't need to statically compile the groovy code either.

blackdrag

12 ปีที่แล้วdiscuss

I agree that the mailing list should have been used the same day, but are you seriously unhappy that something is announced on the mailing list with a delay of 4 days, where all of these days had been travel, conference or holiday for any of the core members?

blackdrag

12 ปีที่แล้วdiscuss

Guess I am one of the ones from 2 yrs ago, even though I am not aware this has already been 2 yrs. I thought last time was already last year... well, I can be easily mistaken. But I really wonder what those Pivotal accounts are supposed to be. Could be a reason to talk with some people if I had details

blackdrag

12 ปีที่แล้วdiscuss

Well, I as Groovy Core don't follow hacker news normally. There are already enough channels for me to follow and the density of Groovy related themes has been quite low here. It as a thing of trying to spend the little time I have with something useful and being effective about it. So if I answer here, then only because someone pointed me to it and then it is more to try to fight misinformation and FUD

blackdrag

12 ปีที่แล้วdiscuss

So what's the appropriate communication way for this? I am curious to know how that should have been done

blackdrag

12 ปีที่แล้วdiscuss

Even if Groovy 3 had its first beta tomorrow, it would take several months for it to become the new 3.0. That has been the case for every Groovy version with a beta and especially for a version with so many changes as 3.0. Also the bigger the changes in 3.0 the longer there will be a Groovy 2.x. You can't expect to have 2.x maintained for, for example a year and have only bugfix versions coming out.

blackdrag

14 ปีที่แล้วdiscuss

Should I have corrected your misread about the announcements? Well I would have done so if I had read it. I try to concentrate on working and what goes through the lists. I don't read blogs very often. The normal channel for me is to ask on the mailing list if there are things unclear. I then try to answer them as best as I can.

Looking at nabble a bit (I did of course not look at all your messages) I don't see what you mean with being ignored or not welcomed or ridiculed in 2006-2008. as for the back-channels, that was the situation from 2003 onwards already. back then a lot happened in IRC for example. The long discussions on the list have often only been the tip of the iceberg. As for GRegexes... it is the first time I hear about it. Remember I don't usually read many blogs and you never mentioned it on the groovy lists. So I am sorry that you have this problem. I won't say Alex is the only one at fault for this. We offered him a slow integration path of his "ideas" including a rewrite of the code, because his code was quite makeshift. He was not interested without getting money. And getting new founds from VMware is a fight, especially for Groovy. If you think VMware wants to control anything Groovy, then I think I have to tell you that this is wrong. Most of VMware doesn't even know Groovy exists. This has pros (no being bothered too much by marketing) and cons (not getting much in terms of funds). The part VMware is mostly interested in, is Grails as part of their products. And they don't care too much about what Grails does exactly either, as long as it works for them. So I really don't see VMware wanting to have everything under their control. I mean you complain also about a time long before main developers have been with VMware. From my perspective the freedom we have now is more then when there was G2One (there we always had financial problems). And before G2One is was even difficult to meet. I mean when I attended the first Paris meeting I was still student and paying everything myself.

Regarding a spec... We discuss this since... I don't know, since James had the stupid idea of doing a JSR and then not working on it. Jeremy worked a lot on it, but in the end he had to stop because of potential copyright issues with Sun. We asked them if we could take their spec and adapt it for Groovy. That of course they didn't want. Then we started with a "delta" spec. But actually this cannot work for two reasons. One is that Groovy has some quite fundamental changes of the concepts, so a simple "delta" will not do it in large parts. The other is that they too change the spec over time, making a "delta" a bit difficult. Well, ok, the later is not such a big deal, if you have some persons working on this... but we never had anyone but Jeremy. As for the spec from Guillaume... What you wrote doesn't sound quite right to me. The idea is to have a document similar to the JLS for Groovy, including code. This code is to form the TCK, and "directly" executed from that spec. Quite some tests from our test suite would then go into that spec and the spec will become part of our build, to ensure we do not accidentally change the spec with our implementation. If you want to make such a project you are welcome. But then I suggest not only looking at the very small beginnings at https://github.com/glaforge/dokspek I also suggest we discuss the exact thing on the list first - and that without letting us be blinded by emotion please.

blackdrag

14 ปีที่แล้วdiscuss

As a main Groovy developer, the Jochen Theodorou, that was spoken of above, I think I have to correct the above quite a bit.

Yes, the distribution contains 2 jars now, one for the groovy parts being precompiled with the invokedynamic port as well as the invokedynamic implementation itself and another one. But! The other one is not a static version. It is the normal dynamic Groovy, that was it before. Of course you can use the indy jar and use non indy code as well as you can use @CompileStatic with it. Should there be any problems in mixing indy and static compilation, please report them, they would be bugs. In both jars indy is disabled by default and needs to be enabled on the command line or as compiler option if you want to use it. The problem with having precompiled groovy code in indy simply is, that it cannot run on a pre jdk7. The alternative would be to have no indy precompiled stuff in the distribution and we may take this path later on. So the difference between the jars is, that the second jar has additionally classes for invokedynamic support and precompiles some stuff using indy, while the non-indy jar has no indy classes and is compiled like before. Static compilation has absolutely nothing to do with it. So sorry, but you say above is large nonsense and please stop spreading non-facts and false flags. Groovy 2.0.4 was released because of some critical bugs in stub compiler, that have been a bigger problem to other projects, that want to release soon a new version. As for Groovy++. If you want to hear the full story, I will tell it you, but not in public, because I am respecting Alex, but what I would have to say about this, wouldn't sound like it and is not explained in a few lines of code. Let us just say that we had some very negative vibes between us. Him being my boss in the G2One days made things especially bad.

Then about lazy evaluation... the way I know them is for example generators. There is an article on the Groovy wiki on how to make generators using groovy.lang.Closure. I don't think that lambdas in Jdk8 will allow for example partially uncompiled code or non checked code paths until needed. So the will effectively not be better than Groovy in terms of laziness.

comments