Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #26606 > unrolled thread

Alternatives languages on the JVM: which one or is there no alternative?

Back to article view | Back to comp.lang.java.programmer

Contents

  Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-11-25 03:09 -0800
    Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-25 12:46 +0100
      Re: Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-11-25 05:20 -0800
      Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-11-25 22:10 +0100
        Re: Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-11-25 14:34 -0800
        Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-26 08:54 +0100
          Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-11-26 00:29 -0800
            Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-26 15:29 +0100
              Re: Alternatives languages on the JVM: which one or is there no alternative? Arne Vajhøj <arne@vajhoej.dk> - 2013-11-26 21:55 -0500
                Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-27 08:59 +0100
                  Re: Alternatives languages on the JVM: which one or is there no alternative? Joerg Meier <joergmmeier@arcor.de> - 2013-11-27 10:41 +0100
                    Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-28 12:48 +0100
                      Re: Alternatives languages on the JVM: which one or is there no alternative? leif.roar@invalid.com (Leif Roar Moldskred) - 2013-11-28 16:28 -0600
                        Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-29 00:03 +0100
                          Re: Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-11-29 00:41 -0800
                            Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-29 12:05 +0100
                              Re: Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-11-29 03:51 -0800
                                Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-29 16:44 +0100
                                  Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-11-29 16:48 +0100
                                Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-12-02 06:33 -0800
                                  Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-12-02 15:50 +0100
                                    Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-12-02 16:26 +0100
                                      Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-12-02 21:07 +0100
                                        Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-12-02 23:33 +0100
                                        Re: Alternatives languages on the JVM: which one or is there no alternative? markspace <markspace@nospam.nospam> - 2013-12-02 18:07 -0800
                                          Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-12-03 08:59 +0100
                                          Re: Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-12-03 00:14 -0800
                                            Re: Alternatives languages on the JVM: which one or is there no alternative? Silvio <silvio@internet.com> - 2013-12-03 09:42 +0100
                                              Re: Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-12-03 02:58 -0800
                                                Re: Alternatives languages on the JVM: which one or is there no alternative? Martin Gregorie <martin@address-in-sig.invalid> - 2013-12-03 20:55 +0000
                                                  Re: Alternatives languages on the JVM: which one or is there no alternative? Saxo <jeti789@web.de> - 2013-12-04 00:12 -0800
                                                  Re: Alternatives languages on the JVM: which one or is there no alternative? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-14 03:31 -0400
                                                    Re: Alternatives languages on the JVM: which one or is there no alternative? Martin Gregorie <martin@address-in-sig.invalid> - 2013-12-14 10:11 +0000
                                                    Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-12-14 17:39 +0100
                                                      Re: Alternatives languages on the JVM: which one or is there no alternative? "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-12-14 16:52 +0000
                                                      Re: Alternatives languages on the JVM: which one or is there no alternative? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-14 13:47 -0400
                                                        Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-12-14 23:55 +0100
                                          Re: Alternatives languages on the JVM: which one or is there no alternative? Sebastian <news@seyweiler.dyndns.org> - 2013-12-04 10:39 +0100
                                            Re: Alternatives languages on the JVM: which one or is there no alternative? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-14 03:56 -0400
    Re: Alternatives languages on the JVM: which one or is there no alternative? v_borchert@despammed.com (Volker Borchert) - 2013-11-26 21:28 +0000
      Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-11-26 23:29 +0100
        Re: Alternatives languages on the JVM: which one or is there no alternative? v_borchert@despammed.com (Volker Borchert) - 2013-11-27 05:13 +0000
          Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-11-27 22:57 +0100
            Re: Alternatives languages on the JVM: which one or is there no alternative? v_borchert@despammed.com (Volker Borchert) - 2013-11-29 23:22 +0000
              Re: Alternatives languages on the JVM: which one or is there no alternative? Robert Klemme <shortcutter@googlemail.com> - 2013-11-30 14:41 +0100
              Re: Alternatives languages on the JVM: which one or is there no alternative? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-11-30 16:49 -0600
          Re: Alternatives languages on the JVM: which one or is there no alternative? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-11-27 23:07 -0600
            Re: Alternatives languages on the JVM: which one or is there no alternative? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-11-28 23:41 +0000
              Re: Alternatives languages on the JVM: which one or is there no alternative? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-11-29 00:08 -0600
                Re: Alternatives languages on the JVM: which one or is there no alternative? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-11-29 16:49 +0000
                  Re: Alternatives languages on the JVM: which one or is there no alternative? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-11-30 16:46 -0600
                    Re: Alternatives languages on the JVM: which one or is there no alternative? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2014-02-14 15:36 +0000
            Re: Alternatives languages on the JVM: which one or is there no alternative? v_borchert@despammed.com (Volker Borchert) - 2013-11-29 23:37 +0000
    Re: Alternatives languages on the JVM: which one or is there no alternative? Roedy Green <see_website@mindprod.com.invalid> - 2013-11-28 12:50 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#26697

On 12/02/2013 03:33 PM, Robert Klemme wrote:
>
> The problem with "real" closures (i.e. the ones you can write to) is that they require a dramtic change in the underlying mechanics: you need to keep stack frames around for longer than a method call.  Having that in Java would be really nice but the potential for impact on the huge basis of existing code is severe.  I personally like the simplified anonymous classes approach because it is a pragmatic step forward: you get to use anonymous functions with far less visual overhead than before.
>
> Kind regards
>
> 	robert
>

Not necessarily. Local variables that are written to from closures in 
their scope can also be given an extra level of indirection by mutably 
wrapping them in an object. All access to the variable is then done 
through the wrappers which can be copied into closures just like values 
are copied in the read-only scenario.

[toc] | [prev] | [next] | [standalone]

#26698

On 12/02/2013 03:50 PM, Silvio wrote:
> On 12/02/2013 03:33 PM, Robert Klemme wrote:
>>
>> The problem with "real" closures (i.e. the ones you can write to) is
>> that they require a dramtic change in the underlying mechanics: you
>> need to keep stack frames around for longer than a method call.
>> Having that in Java would be really nice but the potential for impact
>> on the huge basis of existing code is severe.  I personally like the
>> simplified anonymous classes approach because it is a pragmatic step
>> forward: you get to use anonymous functions with far less visual
>> overhead than before.
>>
>> Kind regards
>>
>>     robert
>>
>
> Not necessarily. Local variables that are written to from closures in
> their scope can also be given an extra level of indirection by mutably
> wrapping them in an object. All access to the variable is then done
> through the wrappers which can be copied into closures just like values
> are copied in the read-only scenario.
>

BTW: that is how Scala does it so it is not a very experimental approach 
anymore. To many Java purists the thought that a primitive might become 
a full object may seem horrendous but if you think about it autoboxing 
does the same thing, even at the risk of repeatedly boxing the same 
primirive over and over...

[toc] | [prev] | [next] | [standalone]

#26700

On 02.12.2013 16:26, Silvio wrote:
> On 12/02/2013 03:50 PM, Silvio wrote:
>> On 12/02/2013 03:33 PM, Robert Klemme wrote:
>>>
>>> The problem with "real" closures (i.e. the ones you can write to) is
>>> that they require a dramtic change in the underlying mechanics: you
>>> need to keep stack frames around for longer than a method call.
>>> Having that in Java would be really nice but the potential for impact
>>> on the huge basis of existing code is severe.  I personally like the
>>> simplified anonymous classes approach because it is a pragmatic step
>>> forward: you get to use anonymous functions with far less visual
>>> overhead than before.

>> Not necessarily. Local variables that are written to from closures in
>> their scope can also be given an extra level of indirection by mutably
>> wrapping them in an object. All access to the variable is then done
>> through the wrappers which can be copied into closures just like values
>> are copied in the read-only scenario.

Yes, true.  That's an approach I had not thought of.  The only downside 
I can see immediately is that you may pay the overhead for the 
additional indirection even if the closure is not used (e.g. because it 
is not in the branch of code actually executed).  One can even optimize 
the approach by creating a single instance carrying the local state so 
there is not one object per referred local variable but one per closure 
creation.  But I guess that overhead is as acceptable as this:

> BTW: that is how Scala does it so it is not a very experimental approach
> anymore. To many Java purists the thought that a primitive might become
> a full object may seem horrendous but if you think about it autoboxing
> does the same thing, even at the risk of repeatedly boxing the same
> primirive over and over...

Another thing which might not be that nice is that instance variables 
will be accessed differently, i.e. through 'this'.  So there is one 
access path for local variables introducing a synthetic indirection and 
another one going through 'this'.

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 
to do the full thing (think of the delays of Java 8 we have seen 
already) and also that gives them the chance to learn how people use the 
new feature and maybe improve it before going full circle.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#26702

On 12/02/2013 09:07 PM, Robert Klemme wrote:
>
> Yes, true.  That's an approach I had not thought of.  The only downside
> I can see immediately is that you may pay the overhead for the
> additional indirection even if the closure is not used (e.g. because it
> is not in the branch of code actually executed).  One can even optimize
> the approach by creating a single instance carrying the local state so
> there is not one object per referred local variable but one per closure
> creation.  But I guess that overhead is as acceptable as this:
>

Yes, that is a possible optimization. But, the combined object approach 
can become very complex when multiple closures are in play, which is 
very common once real closures are available.

>
> Another thing which might not be that nice is that instance variables
> will be accessed differently, i.e. through 'this'.  So there is one
> access path for local variables introducing a synthetic indirection and
> another one going through 'this'.
>

That is correct and it is also a gotcha with Scala closures. Not that it 
is something you have to consider often but in very rare cases it boils 
up and may force one to copy something into a local temporary.

> 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
> to do the full thing (think of the delays of Java 8 we have seen
> already) and also that gives them the chance to learn how people use the
> new feature and maybe improve it before going full circle.
>
> Kind regards
>
>      robert
>

I also suspect the resources part was a factor. That and the fact that 
it was hard enough already to reach consensus on the proposal(s).

Cheers,

Silvio

[toc] | [prev] | [next] | [standalone]

#26705

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.

[toc] | [prev] | [next] | [standalone]

#26707

On 12/03/2013 03:07 AM, markspace wrote:
> 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.
>

Yes, and it was not a particularly strong argument that he made. 
Closures are no different from any "normal" piece of code and there is 
no argument whatsoever to restrict their abilities because of "thread 
safeness" considerations. There is all but consensus that "computer 
science" in retrospect would have done anything different, let alone 
make the choices they made for Java.

Immutability and thread-safeness are very important considerations and 
while Scala heavily emphasizes on using immutable container classes in 
its standard library other languages like Haskell reject mutability as a 
whole. I see value in both approaches. There are heaps of arguments that 
can be made in this area but they don't concern closures in particular.

[toc] | [prev] | [next] | [standalone]

#26708

Am Dienstag, 3. Dezember 2013 03:07:31 UTC+1 schrieb markspace:

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

You can easily brake this using the single element array trick:

int sumArray[] = new int[] { 0 };
ints.forEach(i -> {sumArray[0] += i;}); 
println(sumArray[0]); 

I wonder what he value is if it's that easily broken ...

[toc] | [prev] | [next] | [standalone]

#26709

On 12/03/2013 09:14 AM, Saxo wrote:
> Am Dienstag, 3. Dezember 2013 03:07:31 UTC+1 schrieb markspace:
>
>> 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.
>
> You can easily brake this using the single element array trick:
>
> int sumArray[] = new int[] { 0 };
> ints.forEach(i -> {sumArray[0] += i;});
> println(sumArray[0]);
>
> I wonder what he value is if it's that easily broken ...
>

In addition, Java closures can still mutate heap objects so the point 
made against mutation from closures was quite weak. I suspect BG made it 
as part of the discussion on lambdas at the time and that it should not 
be taken out of that context.

[toc] | [prev] | [next] | [standalone]

#26713

Am Dienstag, 3. Dezember 2013 09:42:09 UTC+1 schrieb Silvio:
> On 12/03/2013 09:14 AM, Saxo wrote:
> 
> > Am Dienstag, 3. Dezember 2013 03:07:31 UTC+1 schrieb markspace:
> 
> >
> 
> >> 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.
> 
> >
> 
> > You can easily brake this using the single element array trick:
> 
> >
> 
> > int sumArray[] = new int[] { 0 };
> 
> > ints.forEach(i -> {sumArray[0] += i;});
> 
> > println(sumArray[0]);
> 
> >
> 
> > I wonder what he value is if it's that easily broken ...
> 
> >
> 
> 
> 
> In addition, Java closures can still mutate heap objects so the point 
> 
> made against mutation from closures was quite weak. I suspect BG made it 
> 
> as part of the discussion on lambdas at the time and that it should not 
> 
> be taken out of that context.

Yah, but I'm anyway looking forward to using Java8. I think we will start developing with it in my company earliest in 2020 ... No kiding. I guess other places might be similar. You have to convince the architects that lambdas are beneficial while those guys only care about the CTO and would never talk to some developer. Seriously, architects being decoupled from development was the worst mistake in the last 10-15 years in Java development ...

Sorry for the rant. Couldn't control myself for a little moment ... ;-).

-- Saxo

[toc] | [prev] | [next] | [standalone]

#26715

On Tue, 03 Dec 2013 02:58:08 -0800, Saxo wrote:

> 
> Yah, but I'm anyway looking forward to using Java8. I think we will
> start developing with it in my company earliest in 2020 ... No kiding. I
> guess other places might be similar. You have to convince the architects
> that lambdas are beneficial while those guys only care about the CTO and
> would never talk to some developer. Seriously, architects being
> decoupled from development was the worst mistake in the last 10-15 years
> in Java development ...
>
Decoupling architects from the development process has a much longer 
history than Java: I first ran into sort of mess around 1977 in a COBOL 
shop. Those guys were so decoupled that they trashed their copies of 
design project documents as soon as they'd handed the project over to the 
developers. That way of working didn't work then and doesn't now.

Now add UML to the mix, managers who think that a high level UML 
description of each process is all a developer needs and eliminate all 
feedback to the design team from the devs: the result is most unlikely to 
be a working system. UML is OK if used properly, but its all too easy for 
non-technical managers and designers, who are outside the development 
loop, to convince themselves that once the high-level UML has been 
produced, their job is done. In reality its barely started.
    
> Sorry for the rant. Couldn't control myself for a little moment ... ;-).
>
Ditto.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#26722

Am Dienstag, 3. Dezember 2013 21:55:14 UTC+1 schrieb Martin Gregorie:
> On Tue, 03 Dec 2013 02:58:08 -0800, Saxo wrote:
> 
> 
> 
> > 
> 
> > Yah, but I'm anyway looking forward to using Java8. I think we will
> 
> > start developing with it in my company earliest in 2020 ... No kiding. I
> 
> > guess other places might be similar. You have to convince the architects
> 
> > that lambdas are beneficial while those guys only care about the CTO and
> 
> > would never talk to some developer. Seriously, architects being
> 
> > decoupled from development was the worst mistake in the last 10-15 years
> 
> > in Java development ...
> 
> >
> 
> Decoupling architects from the development process has a much longer 
> 
> history than Java: I first ran into sort of mess around 1977 in a COBOL 
> 
> shop. Those guys were so decoupled that they trashed their copies of 
> 
> design project documents as soon as they'd handed the project over to the 
> 
> developers. That way of working didn't work then and doesn't now.
> 
> 
> 
> Now add UML to the mix, managers who think that a high level UML 
> 
> description of each process is all a developer needs and eliminate all 
> 
> feedback to the design team from the devs: the result is most unlikely to 
> 
> be a working system. UML is OK if used properly, but its all too easy for 
> 
> non-technical managers and designers, who are outside the development 
> 
> loop, to convince themselves that once the high-level UML has been 
> 
> produced, their job is done. In reality its barely started.
> 
>     
> 
> > Sorry for the rant. Couldn't control myself for a little moment ... ;-).
> 
> >
> 
> Ditto.

Thanks for your contribution. I feel much better now having talked to people that think alike ;-).

[toc] | [prev] | [next] | [standalone]

#26885

On 12/03/2013 04:55 PM, Martin Gregorie wrote:
> On Tue, 03 Dec 2013 02:58:08 -0800, Saxo wrote:
>
>>
>> Yah, but I'm anyway looking forward to using Java8. I think we will
>> start developing with it in my company earliest in 2020 ... No kiding. I
>> guess other places might be similar. You have to convince the architects
>> that lambdas are beneficial while those guys only care about the CTO and
>> would never talk to some developer. Seriously, architects being
>> decoupled from development was the worst mistake in the last 10-15 years
>> in Java development ...
>>
> Decoupling architects from the development process has a much longer
> history than Java: I first ran into sort of mess around 1977 in a COBOL
> shop. Those guys were so decoupled that they trashed their copies of
> design project documents as soon as they'd handed the project over to the
> developers. That way of working didn't work then and doesn't now.
>
> Now add UML to the mix, managers who think that a high level UML
> description of each process is all a developer needs and eliminate all
> feedback to the design team from the devs: the result is most unlikely to
> be a working system. UML is OK if used properly, but its all too easy for
> non-technical managers and designers, who are outside the development
> loop, to convince themselves that once the high-level UML has been
> produced, their job is done. In reality its barely started.
>
>> Sorry for the rant. Couldn't control myself for a little moment ... ;-).
>>
> Ditto.
>
Truth be told, I never heard of software "architects" back in the '70's 
or '80's, it only started showing up as a term in the '90's. Even in the 
'90's I don't recall people describing themselves as architects so much 
as there were folks who started talking about software architecture.

All of a sudden with the original dot com boom we started seeing 
"architects". That's less than 15 years ago. It's been astonishing to me 
how you can actually become an architect with just 5 or 10 years under 
your belt, but apparently that's readily achievable. Given the fact that 
we've got dozens of conferences and dozens of websites where hundreds of 
youngsters with 2-5 years software experience can posture as architects, 
either I'm dated or my standards are too high.

Martin, I gave up on UML several years ago. That and all other graphical 
modeling languages. All of that graphical stuff seriously wastes time - 
competent developers understand text better, and God forbid if managers 
see UML. Plain English, pseudocode, and sketches on paper work a lot better.

There actually is a role for architects. It's just that 95 percent of 
the people who advertise themselves as such couldn't code their way out 
of a piss-soaked paper bag, let alone comprehend a system.

AHS
-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#26888

On Sat, 14 Dec 2013 03:31:20 -0400, Arved Sandstrom wrote:

> Martin, I gave up on UML several years ago. That and all other graphical
> modeling languages. All of that graphical stuff seriously wastes time -
> competent developers understand text better, and God forbid if managers
> see UML. Plain English, pseudocode, and sketches on paper work a lot
> better.
>
Agreed.
 
> There actually is a role for architects. It's just that 95 percent of
> the people who advertise themselves as such couldn't code their way out
> of a piss-soaked paper bag, let alone comprehend a system.
>
Yes. If a significantly sized system isn't designed, designed well and 
this specifically includes details of how it is to be controlled, 
configured and recovered after a crash, before any code is cut it will 
probably be a disaster. Configuration needs to cover how the system is to 
be scaled up since there is a good chance that it will be asked to deal 
with more data that is delivered quicker than the original requirements 
foresaw. For example, I designed a system that handled the warehousing 
and analysis of call detail records that, when first run live, was faced 
with more data volume than the requirement said was expected in 3 years 
time (due to the introduction of pay-as-you-go). And it soon ramped up 
from there...


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#26894

On 14.12.2013 08:31, Arved Sandstrom wrote:

> Truth be told, I never heard of software "architects" back in the '70's
> or '80's, it only started showing up as a term in the '90's. Even in the
> '90's I don't recall people describing themselves as architects so much
> as there were folks who started talking about software architecture.

ACK.

> All of a sudden with the original dot com boom we started seeing
> "architects". That's less than 15 years ago. It's been astonishing to me
> how you can actually become an architect with just 5 or 10 years under
> your belt, but apparently that's readily achievable. Given the fact that
> we've got dozens of conferences and dozens of websites where hundreds of
> youngsters with 2-5 years software experience can posture as architects,
> either I'm dated or my standards are too high.

Yes, indeed.  Another thing I find quite irritating is the verve with 
which people advertise the next new language / framework / project 
management technique etc. on these conferences.  There's a lot of good 
ideas around but nobody will master any of these if they jump on the 
next bandwagon at the frequency that they come round the corner.

> Martin, I gave up on UML several years ago. That and all other graphical
> modeling languages. All of that graphical stuff seriously wastes time -
> competent developers understand text better, and God forbid if managers
> see UML. Plain English, pseudocode, and sketches on paper work a lot
> better.

UML works great on paper.  I do agree with you when it comes to 
graphical modeling.  That is a waste of time IMHO.  But even for paper 
and whiteboard it's good to have a common  graphical syntax - even if 
you just use a small portion of UML for that.

> There actually is a role for architects. It's just that 95 percent of
> the people who advertise themselves as such couldn't code their way out
> of a piss-soaked paper bag, let alone comprehend a system.

I can't comment on the 95% but I have certainly seen this phenomenon.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#26895

Robert Klemme wrote:

> > It's just that 95 percent of
> > the people who advertise themselves as such couldn't code their way out
> > of a piss-soaked paper bag, [...]
>
> I can't comment on the 95% but I have certainly seen this phenomenon.

Impossible to put solid numbers on it without actual research, but -- oh, it 
would be FUN to do the research...

    -- chris 

[toc] | [prev] | [next] | [standalone]

#26896

On 12/14/2013 12:39 PM, Robert Klemme wrote:
> On 14.12.2013 08:31, Arved Sandstrom wrote:
>
>> Truth be told, I never heard of software "architects" back in the '70's
>> or '80's, it only started showing up as a term in the '90's. Even in the
>> '90's I don't recall people describing themselves as architects so much
>> as there were folks who started talking about software architecture.
>
> ACK.
>
>> All of a sudden with the original dot com boom we started seeing
>> "architects". That's less than 15 years ago. It's been astonishing to me
>> how you can actually become an architect with just 5 or 10 years under
>> your belt, but apparently that's readily achievable. Given the fact that
>> we've got dozens of conferences and dozens of websites where hundreds of
>> youngsters with 2-5 years software experience can posture as architects,
>> either I'm dated or my standards are too high.
>
> Yes, indeed.  Another thing I find quite irritating is the verve with
> which people advertise the next new language / framework / project
> management technique etc. on these conferences.  There's a lot of good
> ideas around but nobody will master any of these if they jump on the
> next bandwagon at the frequency that they come round the corner.

I have fairly typical online subscriptions and professional reading 
habits: DDJ, CodeProject, InfoQ, ACM TechNews, ODN, The ServerSide, 
LinkedIn groups, to name a few that are reasonably general. I've noted 
the same thing - how the hell does anyone keep track of all this stuff? 
Agile was supposed to supplant waterfall and spiral and all that, but 
now apparently agile often fails at scale, so lean is the way to go. 
Build system A for language X is obviously obsolete because it's already 
6 months old, so someone had to invent build system B. There may be ten 
thousand *.js libraries out there now, and God only knows what they all do.

I've evidently really missed the boat by not being up to speed on 
asynchronous event-driven functional reactive programming. I've also 
noticed that after the few years that I generally ignored NoSQL that now 
there's a backlash that is talking up relational again - good to know, 
RDBMS's worked just fine for me all along.

There's plenty of innovation and disruption alright. So much so that 
we're no further ahead in solving core problems than, say, 20 or 30 
years ago.

>> Martin, I gave up on UML several years ago. That and all other graphical
>> modeling languages. All of that graphical stuff seriously wastes time -
>> competent developers understand text better, and God forbid if managers
>> see UML. Plain English, pseudocode, and sketches on paper work a lot
>> better.
>
> UML works great on paper.  I do agree with you when it comes to
> graphical modeling.  That is a waste of time IMHO.  But even for paper
> and whiteboard it's good to have a common  graphical syntax - even if
> you just use a small portion of UML for that.

Ranting aside, I don't completely discount the use of UML or another 
graphical language. A lot of the modeling graphics I've seen (UML and 
otherwise) have made me question the wisdom of the adage "a picture is 
worth a thousand words", but there's certainly important uses for these 
drawings.

The core problem with UML or other modeling languages is not the 
constructs they make available, it's the fact that many people feel the 
need to express every detail of their design using UML etc. I'm not 
interested in seeing a class diagram that shows every private field for 
every class, nor sequence diagrams for mundane interactions. The 
graphics should express key information, not all information.

>> There actually is a role for architects. It's just that 95 percent of
>> the people who advertise themselves as such couldn't code their way out
>> of a piss-soaked paper bag, let alone comprehend a system.
>
> I can't comment on the 95% but I have certainly seen this phenomenon.
>
> Kind regards
>
>      robert
>
Ahh, I pulled 95% out of my hat. Based on empirical evidence ( personal 
knowledge of hundreds of IT types over the decades), I might not be so 
harsh, but I'd estimate that well over three-quarters of self-titled 
software architects simply do not have the seniority nor experience to 
possibly be one [1], and of those people that do ostensibly have the 
seniority and the experience (on paper), a large majority prove not to 
be adequate.

AHS

1. Not always a person's fault. One's employer frequently indulges in 
title inflation. I'm familiar with quite a few local software 
consultancies where practically everyone is a "senior consultant" - no 
matter that you're just a junior coder for hire who's got 2 years 
experience...
-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#26907

On 14.12.2013 18:47, Arved Sandstrom wrote:

> I have fairly typical online subscriptions and professional reading
> habits: DDJ, CodeProject, InfoQ, ACM TechNews, ODN, The ServerSide,
> LinkedIn groups, to name a few that are reasonably general. I've noted
> the same thing - how the hell does anyone keep track of all this stuff?

Hire someone doing the reading for you... ;-)

> Agile was supposed to supplant waterfall and spiral and all that, but
> now apparently agile often fails at scale, so lean is the way to go.
> Build system A for language X is obviously obsolete because it's already
> 6 months old, so someone had to invent build system B. There may be ten
> thousand *.js libraries out there now, and God only knows what they all do.

:-)

> I've evidently really missed the boat by not being up to speed on
> asynchronous event-driven functional reactive programming. I've also
> noticed that after the few years that I generally ignored NoSQL that now
> there's a backlash that is talking up relational again - good to know,
> RDBMS's worked just fine for me all along.

I, too, am convinced that many underestimate the value of mature RDBMS 
systems.  I'd love to know how many people go through hoops and loops to 
retrofit transactional behavior on a NoSQL DB because it looked cool 
when the project started out.  "Concurrency we'll do later."  Well...

> There's plenty of innovation and disruption alright. So much so that
> we're no further ahead in solving core problems than, say, 20 or 30
> years ago.

It's disturbing to see how often the same problem is solved over and 
over again.  Just look at the number of text editors...

> The core problem with UML or other modeling languages is not the
> constructs they make available, it's the fact that many people feel the
> need to express every detail of their design using UML etc. I'm not
> interested in seeing a class diagram that shows every private field for
> every class, nor sequence diagrams for mundane interactions. The
> graphics should express key information, not all information.

Exactly!  Well put.

> 1. Not always a person's fault. One's employer frequently indulges in
> title inflation. I'm familiar with quite a few local software
> consultancies where practically everyone is a "senior consultant" - no
> matter that you're just a junior coder for hire who's got 2 years
> experience...

You get to charge more for a senior...  In part it's also a cultural 
thing.  A few weeks back I saw a request for a senior which required two 
years of experience - and it was not in the western hemisphere.

Cheers

	robert

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#26886

On 12/04/2013 05:39 AM, Sebastian wrote:
> 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
>
I get Goetz' argument, a bit. But there is a fairly well established 
notion of closure - I don't think it's up to Goetz to suggest that there 
is ambiguity about the definition. I don't like the terminology 
"closure-like".

I respect Brian Goetz. I've read and relied upon much of his literature. 
Having said that, it's unhelpful and not healthy for any one single 
person to control so much of the conversation about a language or 
platform. There's only so many people that can directly influence Java 
development...as in a dozen or less...but millions use it, and 
presumably thousands are just as proficient with Java as Goetz or Bloch 
- except you never hear from them.

I think Goetz could have just summarized by explaining what a real 
closure is, and explaining whether or not Java 8 has one. Maybe two or 
three sentences.

AHS

-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#26627

No language that is to run on the JVM can overcome its fundamental
shortcoming of missing multiple implementation inheritance. While
this might not be a problem with everyday code, is _is_ a problem
if you are in low-level or framework stuff, for example if you have
class hierarchies where you want to offer mixed reference flavors -
your class C either ends up with two fields, one T and one to some
(X extends WeakReference<T>) which contains another extra field for
the back reference to the containing C so that the C can be notified
of the X having been garbage collected and an extra two-word object
header, or with lots of duplicated code.


-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web