tag:blogger.com,1999:blog-741750605858169835.post9020307993872739382..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Closures options - FCM+JCA is my choiceStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-741750605858169835.post-48173903359397751722007-05-17T12:03:21.000+01:002007-05-17T12:03:21.000+01:00I vote for CICE and strongly reject BGGA or FCM. N...I vote for CICE and strongly reject BGGA or FCM. Not that they are bad proposals but they add a level of complexity that it is simply not worth it. I think a very widely used language like Java is the totally wrong place for such experiments. Why use a proven tool that serves very well to so many people as a test bed for freaky language constructs. I think CICE easily provides all that is commonly needed from closures. Especially Mr Gafter should know better how easy one can "overdesign" a language, as he is part of the C++ language board I read. It is very stupid to ruin Java (language) by throwing in intelligent and stupid features just to please a percent or so very vocal developers. Especially when you consider that most of them will nevertheless quickly move to the next cool scripting language that comes along. Where comes this missionary eagerness from, to force a vast majority to follow the vogues of a small minority? Especially as no boundaries are in sight: Today the most complex of all thinkable closure implementations, oh and lets add control abstraction, properties, operator overloading then tomorrow aspects, continuations and so on. Stop it!<br />Use Groovy, Scala, Nice, port C# to the Java (platform) or create a new "Java++" language.<br />That would be a much cleaner and also a very democratic solution: If the proponents of endless feature addition are correct, than "Java++" will replace Java just as Java replaced C++ in many fields of application development.<br />Perhaps Java, Java++, Groovy and some others can fruitfully coexist, giving every kind of developer what he needs to get his work done and still have fun.Armin Ehrenreichnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-79213223491569543252007-05-04T16:42:09.000+01:002007-05-04T16:42:09.000+01:00Mikael, you keep saying that adding control invoca...Mikael, you keep saying that adding control invocation syntax will make the language harder to learn. In fact I would argue it's the opposite. It's a step toward simplifying the language, particularly the API usage aspect of it. I think when talk this supposed added complexity you are confusing those two aspects: writing an API and using it. Writing API is always a trickier problem, and the control invocation syntax does not really make this any more complex. As far as simplifying usage is concerned I would only refer the JSR draft where it lists 5 scenarios where we can expect improvements. Again, with version 5, and generics we saw the Java language trending toward more complexity. I see the invocation syntax as a push in the opposite direction, toward conciseness, expressiveness, and simplification.Mike Azzinoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-30553171337783995812007-05-04T15:03:33.000+01:002007-05-04T15:03:33.000+01:00And by "control abstraction", I also mea...And by "control abstraction", I also meant BGGA's "control invocation syntax". (But it's not a complete misuse from FCM/JCA perspective, since that's the only control abstraction you get, if I understand the clarification correctly.)Tom Palmernoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-82754204384964195612007-05-04T15:00:28.000+01:002007-05-04T15:00:28.000+01:00Thanks for the clarifications of the current statu...Thanks for the clarifications of the current status, by the way. And I stick to thinking that control abstraction is pretty vital. It's not for clever language people. It's so everyday people can do everyday things more easily and correctly. (And if other FCM or BGGA stuff gets in, I really don't see a need for CICE, unless we like Perl-style TIMTOWTDI.)Tom Palmernoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-73319115873753589672007-05-04T07:08:59.000+01:002007-05-04T07:08:59.000+01:00I would vote for CICE + FCM. Control Abstraction w...I would vote for CICE + FCM. Control Abstraction would be good for me and you, since we are willing to learn, but hard to swallow for all those corporate developers. They learned Java in uni and aren't interested to go back to school to learn a hole new type of Java programming, which true closures represents.<br /><br />Cheers,<br />MikaelMikael Grevhttp://www.migcalendar.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-40576797878521866962007-05-03T20:36:10.000+01:002007-05-03T20:36:10.000+01:00... As someone once said: Go Big or Go Home!!.... As someone once said: Go Big or Go Home!!.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-48505200909506640492007-05-03T20:32:58.000+01:002007-05-03T20:32:58.000+01:00FCM+JCA sounds like a reasonable choice. Although ...FCM+JCA sounds like a reasonable choice. Although I haven't really had the chance to compare the JCA to BGGA control abstraction. But I do like FCM method literals though, which hopefully will be extended to support other kind of currying. I was originally on the fence with regard to adding closure to Java until I saw the beauty, elegance, and power of control abstraction as offered by the BGGA proposal, then I became a convert. So to me any proposal that falls short on the control abstraction support is a non starter, and IMO is just a short term fix, equivalent of putting lipstick on the inner class pig. It's just not worth the hassle. I would recommend everyone to check out the control abstraction use cases that you posted on your blog. I found them very useful in showcasing the great potential of control abstractions.Mike Azzinoreply@blogger.com