tag:blogger.com,1999:blog-741750605858169835.post5152252013007562768..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Closures - Comparing closure type inferenceStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-741750605858169835.post-55744059182026648792008-02-01T12:30:59.000+00:002008-02-01T12:30:59.000+00:00Ahmed,
There are people outside of academia who w...Ahmed,<br /><br />There are people outside of academia who want closures. I also happen to write distributed trading/pricing systems (just on slightly bigger scale) and I'm also not using closures - because they are not there. Unfortunately, to create the systems properly, there is a lot of quite verbose code patterns we have to follow to have everything working in right way. Good closures could cut the noise in source code by half probably. <br /><br />Yes, it would be a kind of subdialect of java and nobody from market could understand the code without some basic explanation. Unfortunately, it is also a case today - fact that you can understand the operations done, doesn't mean you understand the reason why they are done. In both cases, somebody with knowledge have to explain it to you. Difference is that after explanation, you will have to either 'parse' it in your mind every single time to match the pattern or see the shortcut syntax with correct keyword.<br /><br />Not having custom control structures causes copy/paste on the code pattern level (not on implementation level of course). Plus a lot of undeeded verbosity, which still won't allow 'Average Joe' to understand inherently complicated system.Arturnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-63963131387987391342008-01-29T11:08:08.000+00:002008-01-29T11:08:08.000+00:00Stephen: About monads; they're not so much a l...Stephen: About monads; they're not so much a language feature as a general way of thinking. One could argue that checked exceptions are an example of a monad. I'd suggest learning about them before commenting on them, though I do need to take my own advice here!<br /><br />I should note that BGGA deliberately avoids being concerned with type inference so that it doesn't get rejected because of any controversy over type inference.Ricky Clarksonhttp://cime.net/~ricky/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-2095537007380516582008-01-29T09:48:50.000+00:002008-01-29T09:48:50.000+00:00Pity you didn't mention C3S:
http://www.artim...Pity you didn't mention C3S:<br /><br />http://www.artima.com/weblogs/viewpost.jsp?thread=182412<br /><br />It has more inference than the other proposals. Your example would be:<br /><br />final stringList = ...<br />final integerList = ...<br />final str = find stringList, integerList, method(str, val) {<br />__str != null && str.length() > 0 && val != null && val > 10<br />};Howard Lovatthttp://www.artima.com/weblogs/viewpost.jsp?thread=182412noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-69933456613245546662008-01-29T00:02:16.000+00:002008-01-29T00:02:16.000+00:00BGGA is the only one that looks remotely good.
...BGGA is the only one that looks remotely good. <br /><br />FCA's syntax is silly<br />CICE is no better than the AIC.<br /><br />ClintonClinton Beginnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-28663999882351064082008-01-28T17:43:21.000+00:002008-01-28T17:43:21.000+00:00I'm working on an application that is almost a...I'm working on an application that is almost as mission-critical as they come (people have died when we made bad design decisions). The nature of the code is thousands of concurrent high-latency network calls, and we've implemented what amount to closures using generics; we're very much looking forward to closures being included in Java.<br /><br />I had a piece of code I was working on where fully 80% of the codespace was generics definitions; It was defining a chain of closures from one type to another to another to define my business rules. We chose to give up the strong compile-time typing to make the code at all maintainable; with good LHS type inference, we would get both the compile-time strong typing, and maintain the readability of the code.<br /><br />From what we've been experiencing, type inference is a predicate for closures.Bob Hansennoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-2397488910100694432008-01-28T11:23:53.000+00:002008-01-28T11:23:53.000+00:00CICE is clearer to me. For a java developper, it&#...CICE is clearer to me. For a java developper, it's very close to the inner class approach.<br />Personnaly I think type inference is a scripting language feature. And I'm happy that java is strongly typed.shamaznoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-9402513473043456902008-01-27T22:17:16.000+00:002008-01-27T22:17:16.000+00:00Hi Stephen,
i see your point but i tend to agree ...Hi Stephen, <br />i see your point but i tend to agree with Reiner, CICE version provides self documentation by revealing that operation is a PairMatcher contract.ahmetnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-35034757224636502482008-01-26T10:53:12.000+00:002008-01-26T10:53:12.000+00:00-Reinier: Yes, CICE might build in support for typ...-Reinier: Yes, CICE might build in support for type inference of generics over time, but I can only discuss what the current proposal states. Also, according to Neal, this inference problem also affects exception transparancy in CICE.<br /><br />-Ahmed: Closures are not an academic language feature - the vast majority of languages have them. They are not new (they've been around for decades), and they are well proven.<br /><br />Every day I work with Java I find a situation that would be better solved using closures. Typically, these are looping around lists and maps to find things, although there are many other use cases. A key reason why they are appropriate now is the Fork-Join framework from Doug Lea, which addresses the coming concurrent revolution in processors.<br /><br />For the record, I am very much not the academic. Yet, I know that some form of closures (FCM) would be very valuable for Java developers, and as the frameworks adapted, even you would be using them every day. Finally, neither loose typing nor monads would be especially appropriate for Java.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-58019651958752381822008-01-26T07:39:11.000+00:002008-01-26T07:39:11.000+00:00Why are we suddenly discussing adding academic lan...Why are we suddenly discussing adding academic language features to Java?<br /><br />When was the last time you wanted to use closures to solve a real-world problem?<br /><br />I write distributed trading systems that deal with millions of dollars daily and I've never felt the need for closures or inference. On the other hand the academics I talk to are infatuated with closures, loose typing, and monads, and have never written anything mission-critical in their life.Ahmed Hassannoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-12950377023347119762008-01-26T06:57:01.000+00:002008-01-26T06:57:01.000+00:00Given the widespread discussion about eliminating ...Given the widespread discussion about eliminating a lot of repetition of generics arguments, I think its somewhat disingenuous towards CICE to presume that a CICE proposal wouldn't go hand in hand with a proposal that shortens or eliminates generics types. In particular, because CICE is new syntax anyway, and there's always the long-winded alternative, you can say that for CICE syntax, if you don't add generics parameters of any sort to the class name, they are inferred, instead of the current default of treating it as a raw type.<br /><br />With that taken care of, the only extra content that the CICE proposal saddles you with is the PairMatcher name, which really is useful.<br /><br />NB: I filed a bug report for joda time at the sourceforge page but I'm not sure you check it.Reinier Zwitserloothttp://tipit.to/noreply@blogger.com