Path: csiph.com!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail
From: Sebastian <news@seyweiler.dyndns.org>
Newsgroups: comp.lang.java.programmer
Subject: Re: Alternatives languages on the JVM: which one or is there no alternative?
Date: Wed, 04 Dec 2013 10:39:24 +0100
Organization: albasani.net
Lines: 48
Message-ID: <l7mt9b$909$1@news.albasani.net>
References: <b61c37c4-1b86-4b63-8ed1-fa5834eb638e@googlegroups.com> <5293388a$0$15988$e4fe514c@news2.news.xs4all.nl> <bfhsnfF1021U1@mid.individual.net> <529453d2$0$15908$e4fe514c@news2.news.xs4all.nl> <73997663-103c-4e48-ac9b-c50e8babfaa6@googlegroups.com> <5294b061$0$15961$e4fe514c@news2.news.xs4all.nl> <52955f0f$0$296$14726298@news.sunsite.dk> <5295a669$0$15879$e4fe514c@news.xs4all.nl> <19zo5i01fjd4t.101filzjnniw.dlg@40tude.net> <52972d87$0$15919$e4fe514c@news.xs4all.nl> <i_udnRgmTbHtXgrPnZ2dnUVZ8uWdnZ2d@giganews.com> <5297cbd9$0$15882$e4fe514c@news2.news.xs4all.nl> <16c2e66f-de41-4a63-8525-b6703837ae15@googlegroups.com> <52987501$0$15919$e4fe514c@news.xs4all.nl> <bbcf7db0-6415-4c5d-a9c0-4cf7ec6dee99@googlegroups.com> <01086072-1547-49d0-8ef6-ab6a22deb401@googlegroups.com> <529c9e1c$0$15920$e4fe514c@news.xs4all.nl> <529ca6a9$0$15992$e4fe514c@news.xs4all.nl> <bg47kaFrf3uU1@mid.individual.net> <l7jed7$222$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.albasani.net aooBT6Vg19Yu3qqQrD7X2bsv/FtAWnHHWLJ5YnqXjDX/QqmhjTuyms5zkSnKnvzbM+HziyyMz3Z3lYlm7/t+Ew==
NNTP-Posting-Date: Wed, 4 Dec 2013 09:39:55 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="wG2/cRTrut9WCzvHKVFR6oAiuF34r6/Hcukb3OidDyCB2jJYLYNHGp/7N3VXUksykgvUdnC1vsV4XGfALOrrK8Kbf12hZ6jRRnC7qjPXLWhkZriES6XIDNl4XaBxEDyo"; mail-complaints-to="abuse@albasani.net"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
In-Reply-To: <l7jed7$222$1@dont-email.me>
Cancel-Lock: sha1:2bhdpQdhuRUbjc7g7gRmpRBI1KQ=
Xref: csiph.com comp.lang.java.programmer:26723

Am 03.12.2013 03:07, schrieb markspace:
> On 12/2/2013 12:07 PM, Robert Klemme wrote:
>
>> Still, I don't see any hard reasons that speak against doing real
>> closures.  Maybe it's just the pragmatic way, i.e. not enough resources
>
> Have you read any of the discussion on the lambda-dev list?  Brain Goetz
> was dead-set against "real" closures.  He insisted on several occasions
> that "real" closures were broken and would not have been designed the
> way they were if computer science had known what they know today.
>
> The main issue iirc was that he wanted the lambdas to be immutable.  If
> you go back and modify objects or fields by closing over them, then you
> no longer have an immutable operation.  Whether the risk was thread
> safty and optimization, or programmer misuse, or something else, I don't
> recall off hand, but he was pretty adamant it was a dumb idea.
>

Brian Goetz also takes exception to talk of "real closures". Here's
an excerpt from an interview at

http://www.infoq.com/articles/Brian_Goetz_Project_Lambda_from_the_Inside_Interview

<quote>
InfoQ: Lambdas, Closures, there is some debate about what the difference 
is. What's your perspective?

Brian: I think getting worked up over whether lambdas as expressed in 
Java SE 8 are "real" closures or not is a pretty unconstructive 
activity. To me, the use of the term "real" here should be a syntax 
error; there are many different languages with closure-like constructs, 
with varying degrees of similarity and difference. Declaring that 
language X gets to define what a real closure is and any language that 
doesn't do it exactly that way isn't real is not helpful.

That said, there were hard decisions to make about whether to support 
features like mutable local capture, nonlocal control flow, exception 
transparency, and other features, and having left some of these out 
means certain use cases are harder to express naturally; these are 
tradeoffs between expressiveness and complexity, and we tried to spend 
our complexity budget where it had the most impact for developers. It's 
fair to talk about the pros and cons of each of these decisions, but 
framing this in terms of "real vs fake closures" is not a constructive 
way to have this dialog.
</quote>

-- Sebastian