Re: When to Drop "()" in a Function Call

On Fri, Sep 30, 2011 at 4:49 PM, Tony Morris <tmorris@tmorris.net> wrote:

Note that some hold strong objection to using this "convention."

What are those objections (if you know) and is an alternative approach recommended?

It's only a hint and isn't backed by the type system.

On Oct 1, 2011 12:17 AM, "Nils Kilden-Pedersen" <nilskp@gmail.com> wrote:
> On Fri, Sep 30, 2011 at 4:49 PM, Tony Morris <tmorris@tmorris.net> wrote:
>
>> Note that some hold strong objection to using this "convention."
>>
> What are those objections (if you know) and is an alternative approach
> recommended?

Not so.
As Daniel already stated, if you define a structural type then you *must* correctly match the parentheses (or lack thereof).  The two styles *do* have different representations in the type system.
The ability to mix-and-match is a bit of a hack, but also a necessary evil to support Java interop.

On 1 October 2011 11:47, Chris Twiner <chris.twiner@gmail.com> wrote:

It's only a hint and isn't backed by the type system.

On Oct 1, 2011 12:17 AM, "Nils Kilden-Pedersen" <nilskp@gmail.com> wrote:
> On Fri, Sep 30, 2011 at 4:49 PM, Tony Morris <tmorris@tmorris.net> wrote:
>
>> Note that some hold strong objection to using this "convention."
>>
> What are those objections (if you know) and is an alternative approach
> recommended?

--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

I hope this incorrect answer is sufficient to answer the original question.

On 01/10/11 20:53, Kevin Wright wrote:
> Not so.
>
> As Daniel already stated, if you define a structural type then you *must*
> correctly match the parentheses (or lack thereof). The two styles *do* have
> different representations in the type system.
>
> The ability to mix-and-match is a bit of a hack, but also a necessary evil
> to support Java interop.
>
> On 1 October 2011 11:47, Chris Twiner wrote:
>
>> It's only a hint and isn't backed by the type system.
>> On Oct 1, 2011 12:17 AM, "Nils Kilden-Pedersen" wrote:
>>> On Fri, Sep 30, 2011 at 4:49 PM, Tony Morris
>> wrote:
>>>> Note that some hold strong objection to using this "convention."
>>>>
>>> What are those objections (if you know) and is an alternative approach
>>> recommended?
>
>

No.

On 01/10/11 20:58, Kevin Wright wrote:
> We need a new rule in the mailing lists. No calling something out as wrong
> unless you can also explain why you believe that to be the case.
>
> If the only guidance we ever gave was "you're wrong", then nobody would ever
> learn anything around here.
>
>
>
> On 1 October 2011 11:54, Tony Morris wrote:
>
>> I hope this incorrect answer is sufficient to answer the original question.
>>
>> On 01/10/11 20:53, Kevin Wright wrote:
>>> Not so.
>>>
>>> As Daniel already stated, if you define a structural type then you *must*
>>> correctly match the parentheses (or lack thereof). The two styles *do*
>> have
>>> different representations in the type system.
>>>
>>> The ability to mix-and-match is a bit of a hack, but also a necessary
>> evil
>>> to support Java interop.
>>>
>>> On 1 October 2011 11:47, Chris Twiner wrote:
>>>
>>>> It's only a hint and isn't backed by the type system.
>>>> On Oct 1, 2011 12:17 AM, "Nils Kilden-Pedersen"
>> wrote:
>>>>> On Fri, Sep 30, 2011 at 4:49 PM, Tony Morris
>>>> wrote:
>>>>>> Note that some hold strong objection to using this "convention."
>>>>>>
>>>>> What are those objections (if you know) and is an alternative approach
>>>>> recommended?
>>>
>>

We need a new rule in the mailing lists.  No calling something out as wrong unless you can also explain why you believe that to be the case.
If the only guidance we ever gave was "you're wrong", then nobody would ever learn anything around here.


On 1 October 2011 11:54, Tony Morris <tonymorris@gmail.com> wrote:

I hope this incorrect answer is sufficient to answer the original question.

On 01/10/11 20:53, Kevin Wright wrote:
> Not so.
>
> As Daniel already stated, if you define a structural type then you *must*
> correctly match the parentheses (or lack thereof).  The two styles *do* have
> different representations in the type system.
>
> The ability to mix-and-match is a bit of a hack, but also a necessary evil
> to support Java interop.
>
> On 1 October 2011 11:47, Chris Twiner <chris.twiner@gmail.com> wrote:
>
>> It's only a hint and isn't backed by the type system.
>> On Oct 1, 2011 12:17 AM, "Nils Kilden-Pedersen" <nilskp@gmail.com> wrote:
>>> On Fri, Sep 30, 2011 at 4:49 PM, Tony Morris <tmorris@tmorris.net>
>> wrote:
>>>> Note that some hold strong objection to using this "convention."
>>>>
>>> What are those objections (if you know) and is an alternative approach
>>> recommended?
>
>

I think you are focussing on the wrong thing here. One is a syntactic notation and the other is an effect system.

Enforcing in the type system means if one function has a side effect then all that call it do as well. Here the compiler stops us making mistakes.

The other is, as said before, there to support or enforce property like access. This likely isn't what Tony was referring to.

I answered as to why declaring a convention to work around the lack of an effect system is disagreed with.

If you don't agree with that or believe that an effect system is not useful at all/ more useful that's another thing entirely and something I personally won't debate.

On Oct 1, 2011 12:53 PM, "Kevin Wright" <kev.lee.wright@gmail.com> wrote:
> Not so.
>
> As Daniel already stated, if you define a structural type then you *must*
> correctly match the parentheses (or lack thereof). The two styles *do* have
> different representations in the type system.
>
> The ability to mix-and-match is a bit of a hack, but also a necessary evil
> to support Java interop.
>
> On 1 October 2011 11:47, Chris Twiner <chris.twiner@gmail.com> wrote:
>
>> It's only a hint and isn't backed by the type system.
>> On Oct 1, 2011 12:17 AM, "Nils Kilden-Pedersen" <nilskp@gmail.com> wrote:
>> > On Fri, Sep 30, 2011 at 4:49 PM, Tony Morris <tmorris@tmorris.net>
>> wrote:
>> >
>> >> Note that some hold strong objection to using this "convention."
>> >>
>> > What are those objections (if you know) and is an alternative approach
>> > recommended?
>>
>
>
>
> --
> Kevin Wright
> mail: kevin.wright@scalatechnology.com
> gtalk / msn : kev.lee.wright@gmail.com
> quora: http://www.quora.com/Kevin-Wright
> google+: http://gplus.to/thecoda
> <kev.lee.wright@gmail.com>
> twitter: @thecoda
> vibe / skype: kev.lee.wright
> steam: kev_lee_wright
>
> "My point today is that, if we wish to count lines of code, we should not
> regard them as "lines produced" but as "lines spent": the current
> conventional wisdom is so foolish as to book that count on the wrong side of
> the ledger" ~ Dijkstra

Oh sure, the use of () to donate side effects is just a convention, the compiler certainly doesn't enforce this convention.
What the compiler *will* do, however, is encode methods in the type system differently, depending on the existence of parentheses.  It just doesn't attach any other significance to the differing types.
If we're doing it properly, with no side-effects in sight, then both forms become redundant.  "method()" is nothing but side-effect, and has no place in a purely functional design. While "def property = ..." can (and should) be written instead as "val property = ..." or "lazy val property = ...", depending on the computational cost.


On 1 October 2011 13:25, Chris Twiner <chris.twiner@gmail.com> wrote:

I think you are focussing on the wrong thing here. One is a syntactic notation and the other is an effect system.

Enforcing in the type system means if one function has a side effect then all that call it do as well. Here the compiler stops us making mistakes.

The other is, as said before, there to support or enforce property like access. This likely isn't what Tony was referring to.

I answered as to why declaring a convention to work around the lack of an effect system is disagreed with.

If you don't agree with that or believe that an effect system is not useful at all/ more useful that's another thing entirely and something I personally won't debate.

On Oct 1, 2011 12:53 PM, "Kevin Wright" <kev.lee.wright@gmail.com> wrote:
> Not so.
>
> As Daniel already stated, if you define a structural type then you *must*
> correctly match the parentheses (or lack thereof). The two styles *do* have
> different representations in the type system.
>
> The ability to mix-and-match is a bit of a hack, but also a necessary evil
> to support Java interop.
>
> On 1 October 2011 11:47, Chris Twiner <chris.twiner@gmail.com> wrote:
>
>> It's only a hint and isn't backed by the type system.
>> On Oct 1, 2011 12:17 AM, "Nils Kilden-Pedersen" <nilskp@gmail.com> wrote:
>> > On Fri, Sep 30, 2011 at 4:49 PM, Tony Morris <tmorris@tmorris.net>
>> wrote:
>> >
>> >> Note that some hold strong objection to using this "convention."
>> >>
>> > What are those objections (if you know) and is an alternative approach
>> > recommended?
>>
>
>
>
> --
> Kevin Wright
> mail: kevin.wright@scalatechnology.com
> gtalk / msn : kev.lee.wright@gmail.com
> quora: http://www.quora.com/Kevin-Wright
> google+: http://gplus.to/thecoda
> <kev.lee.wright@gmail.com>
> twitter: @thecoda
> vibe / skype: kev.lee.wright
> steam: kev_lee_wright
>
> "My point today is that, if we wish to count lines of code, we should not
> regard them as "lines produced" but as "lines spent": the current
> conventional wisdom is so foolish as to book that count on the wrong side of
> the ledger" ~ Dijkstra

--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

On 01/10/11 22:37, Kevin Wright wrote:
> While "def property = ..." can (and should)
> be written instead as "val property = ..." or "lazy val property = ...",
> depending on the computational cost.
Please stop saying things like this (i.e. not true).

On 01/10/11 22:51, Kevin Wright wrote:
> There's an - admittedly negligible - extra cost to retrieving a lazy val as
> compared to retrieving a (regular) val, and I'm not entirely sure to what
> extent the JVM can optimise this out of existence.
>
> If the property is trivial, such as "val diameter = radius * 2", then I'd
> say it's more efficient to simply evaluate the thing up front, instead of
> making it lazy. Scala isn't Haskell, and the JVM isn't optimised to handle
> everything being lazily evaluated. We need to be aware of this if
> performance is a consideration.
>
>
> On 1 October 2011 13:42, Tony Morris wrote:
>
>> On 01/10/11 22:37, Kevin Wright wrote:
>>> While "def property = ..." can (and should)
>>> be written instead as "val property = ..." or "lazy val property = ...",
>>> depending on the computational cost.
>> Please stop saying things like this (i.e. not true).
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
If you think laziness has anything to do with performance, you're doing
it wrong. Please stop spreading things that are not true. It is not
helpful to people who might wish to learn. One day someone is going to
say this to me in real life and expect me to take them seriously. I am
going to blame you on that day.

Do not say "Scala is not Haskell" to me either. By doing so, you simply
pretend to provide an explanation, when it isn't -- you're just telling
me something that I already know better than you do, and you know I know
it better than you do -- what are you hoping to achieve with a
pseudo-explanation like this? It is deliberately non-progressive. This
is why I don't bother providing explanations to you. I'm not going to
pretend.

Just think about it a bit more before introducing bureaucratic dogma
that is chronically departed from any resemblance to reality. Scala is
not Java after all.

There's an - admittedly negligible - extra cost to retrieving a lazy val as compared to retrieving a (regular) val, and I'm not entirely sure to what extent the JVM can optimise this out of existence.
If the property is trivial, such as "val diameter = radius * 2", then I'd say it's more efficient to simply evaluate the thing up front, instead of making it lazy.  Scala isn't Haskell, and the JVM isn't optimised to handle everything being lazily evaluated.  We need to be aware of this if performance is a consideration.

On 1 October 2011 13:42, Tony Morris <tonymorris@gmail.com> wrote:

On 01/10/11 22:37, Kevin Wright wrote:
> While "def property = ..." can (and should)
> be written instead as "val property = ..." or "lazy val property = ...",
> depending on the computational cost.
Please stop saying things like this (i.e. not true).

--
Tony Morris
http://tmorris.net/

On Sat, Oct 1, 2011 at 09:42, Tony Morris wrote:
> On 01/10/11 22:37, Kevin Wright wrote:
>> While "def property = ..." can (and should)
>> be written instead as "val property = ..." or "lazy val property = ...",
>> depending on the computational cost.
> Please stop saying things like this (i.e. not true).

In what sense are they not true, Tony?

If I have a Matrix class with a determinant method, it will certainly
improve performance of operations that use it if it's provided as a
val instead of a def. Likewise, if it is provided as a lazy val, it
will improve overall performance of using the class both in cases
where no method that uses determinant is used and in cases where many
methods that use determinant is used, but it will _decrease_
performance if determinant is used only once.

On another e-mail you said that "If you think laziness has anything to
do with performance, you're doing it wrong. " I take it you mean that
laziness is not *about* performance, which might be true some of the
time, but the decision to make "determinant" lazy above would be about
performance. Furthermore, laziness and performance _are_ tied, as is
trivially seen by the preference to foldr on lists in Haskell and
foldLeft on lists in Scala.

However, you have not stated any of these things. You haven't stated
ANYTHING that could be used in advancing one's knowledge. Your
behavior in this thread is like a proof by reductio ad absurdum -- it
shows something to be true, but doesn't help you get anywhere else, as
opposed by a proof by construction, which is much more valuable in
producing further results.

James Iry once made a joke about Prolog. Your e-mails on this thread
look remarkably like that hypothetical program.

On 02/10/11 00:10, Daniel Sobral wrote:
> On Sat, Oct 1, 2011 at 09:42, Tony Morris wrote:
>> On 01/10/11 22:37, Kevin Wright wrote:
>>> While "def property = ..." can (and should)
>>> be written instead as "val property = ..." or "lazy val property = ...",
>>> depending on the computational cost.
>> Please stop saying things like this (i.e. not true).
> In what sense are they not true, Tony?

The should part is the not-true part.

> If I have a Matrix class with a determinant method, it will certainly
> improve performance of operations that use it if it's provided as a
> val instead of a def. Likewise, if it is provided as a lazy val, it
> will improve overall performance of using the class both in cases
> where no method that uses determinant is used and in cases where many
> methods that use determinant is used, but it will _decrease_
> performance if determinant is used only once.
>
> On another e-mail you said that "If you think laziness has anything to
> do with performance, you're doing it wrong. " I take it you mean that
> laziness is not *about* performance, which might be true some of the
> time, but the decision to make "determinant" lazy above would be about
> performance. Furthermore, laziness and performance _are_ tied, as is
> trivially seen by the preference to foldr on lists in Haskell and
> foldLeft on lists in Scala.
This is why I have such strong objection. You are free to believe all
this, you can believe in the existence of unicorns, that rainbows are
created by fairies and you can believe that there is a preference for
foldLeft/foldRight in one language or another. However, the moment I
have to deal with this kind of nonsense of this extraordinarily
catastrophic departure from reality, especially if I am trying to get
shit done, I am going to become very very resentful. Soon, someone is
going to say this to me in real life and wonder why I look at them like
they didn't quite think it all the way through, or at all if I am to be
brutally honest. I hate getting into that situation. I've got shit to
do. Make up silly stuff on your own watch!

> However, you have not stated any of these things. You haven't stated
> ANYTHING that could be used in advancing one's knowledge.
Yes I have. I just get tired of repeating myself over and over. Shall I
do it one more time? No. Why not just think it through, *even just a
little bit*?

On 1 October 2011 13:58, Tony Morris <tonymorris@gmail.com> wrote:

On 01/10/11 22:51, Kevin Wright wrote:
> There's an - admittedly negligible - extra cost to retrieving a lazy val as
> compared to retrieving a (regular) val, and I'm not entirely sure to what
> extent the JVM can optimise this out of existence.
>
> If the property is trivial, such as "val diameter = radius * 2", then I'd
> say it's more efficient to simply evaluate the thing up front, instead of
> making it lazy.  Scala isn't Haskell, and the JVM isn't optimised to handle
> everything being lazily evaluated.  We need to be aware of this if
> performance is a consideration.
>
>
> On 1 October 2011 13:42, Tony Morris <tonymorris@gmail.com> wrote:
>
>> On 01/10/11 22:37, Kevin Wright wrote:
>>> While "def property = ..." can (and should)
>>> be written instead as "val property = ..." or "lazy val property = ...",
>>> depending on the computational cost.
>> Please stop saying things like this (i.e. not true).
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
If you think laziness has anything to do with performance, you're doing
it wrong. Please stop spreading things that are not true. It is not
helpful to people who might wish to learn. One day someone is going to
say this to me in real life and expect me to take them seriously. I am
going to blame you on that day.

I believe that the test to determine whether or not a lazy val has been evaluated takes > 0 CPU cycles. It's negligible, and may be optimised to nothing through the JVM and branch prediction.
In general, laziness is independent of performance, and is often beneficial.  But it's worth bearing in mind that a non-lazy val doesn't require the test, and so could offer a small advantage for tight loops in particularly performance-critical code.  

Do not say "Scala is not Haskell" to me either. By doing so, you simply
pretend to provide an explanation, when it isn't -- you're just telling
me something that I already know better than you do, and you know I know
it better than you do -- what are you hoping to achieve with a
pseudo-explanation like this? It is deliberately non-progressive. This
is why I don't bother providing explanations to you. I'm not going to
pretend.

So here's how my thought process went:
Tony:You just said something that isn't true
Me:Hmm, what could that be?
I stated that defs can be substituted with vals in purely functional code.  That's clearly true, it's the very definition of referential transparency, and so true as to be axiomatic. Surely not the basis of your objection then.
When you have referential transparency, you should replace defs with vals/lazy vals.  It seems eminently sensible to keep redoing the same work, and I've seen your own source code make extensive use of vals, so you can't be objecting to this either.
What's left?  The suggestion to use *either* vals or lazy vals, by a process of elimination this is the only possible remaining point of contention.  The question then is which of the two you object to.
Given your noted preference for re-implementing designs from Haskell in Scala, the fact that you answer Scala questions with Haskell source code, your repeated appeals for the use of more laziness in Scala, and online examples of your own source code that also demonstrate your beliefs in this regard; I can only infer that you don't think it's true that a method should be replaced with a strictly-evaluated field, you take issue with my suggestion to use a non-lazy val.
Although there's no reason in theory why lazy evaluation would be less performant than strict evaluation, the JVM is optimised for Java programs.  Imperative, strictly evaluated Java programs.  So there will be a performance benefit, in many scenarios, *on that particular platform*

Of course, it could be something else entirely that you were describing as untrue.  But you didn't specify... 

Just think about it a bit more before introducing bureaucratic dogma
that is chronically departed from any resemblance to reality. Scala is
not Java after all.


--
Tony Morris
http://tmorris.net/

On 02/10/11 00:26, Kevin Wright wrote:
> On 1 October 2011 13:58, Tony Morris wrote:
>
>> On 01/10/11 22:51, Kevin Wright wrote:
>>> There's an - admittedly negligible - extra cost to retrieving a lazy val
>> as
>>> compared to retrieving a (regular) val, and I'm not entirely sure to what
>>> extent the JVM can optimise this out of existence.
>>>
>>> If the property is trivial, such as "val diameter = radius * 2", then I'd
>>> say it's more efficient to simply evaluate the thing up front, instead of
>>> making it lazy. Scala isn't Haskell, and the JVM isn't optimised to
>> handle
>>> everything being lazily evaluated. We need to be aware of this if
>>> performance is a consideration.
>>>
>>>
>>> On 1 October 2011 13:42, Tony Morris wrote:
>>>
>>>> On 01/10/11 22:37, Kevin Wright wrote:
>>>>> While "def property = ..." can (and should)
>>>>> be written instead as "val property = ..." or "lazy val property =
>> ...",
>>>>> depending on the computational cost.
>>>> Please stop saying things like this (i.e. not true).
>>>>
>>>> --
>>>> Tony Morris
>>>> http://tmorris.net/
>>>>
>>>>
>>>>
>> If you think laziness has anything to do with performance, you're doing
>> it wrong. Please stop spreading things that are not true. It is not
>> helpful to people who might wish to learn. One day someone is going to
>> say this to me in real life and expect me to take them seriously. I am
>> going to blame you on that day.
>>
>>
> I believe that the test to determine whether or not a lazy val has been
> evaluated takes > 0 CPU cycles. It's negligible, and may be optimised to
> nothing through the JVM and branch prediction.
>
> In general, laziness is independent of performance, and is often beneficial.
> But it's worth bearing in mind that a non-lazy val doesn't require the
> test, and so could offer a small advantage for tight loops in particularly
> performance-critical code.
>
>
>> Do not say "Scala is not Haskell" to me either. By doing so, you simply
>> pretend to provide an explanation, when it isn't -- you're just telling
>> me something that I already know better than you do, and you know I know
>> it better than you do -- what are you hoping to achieve with a
>> pseudo-explanation like this? It is deliberately non-progressive. This
>> is why I don't bother providing explanations to you. I'm not going to
>> pretend.
>>
>>
> So here's how my thought process went:
>
> Tony:
> You just said something that isn't true
>
> Me:
> Hmm, what could that be?
>
> I stated that defs can be substituted with vals in purely functional code.
> That's clearly true, it's the very definition of referential transparency,
> and so true as to be axiomatic. Surely not the basis of your objection then.
Fuck. What can I say now?

That is *absolutely not true* and has been documented all over the
planet since around the time your grandparents were born. This is the
entire reason you use lazy evaluation -- to achieve termination while
maintaining composition.

In short, take any program that terminates under an "inside-out"
(strict) evaluation. You are guaranteed that the same program terminates
under an "outside-in" (lazy) evaluation. The opposite is NOT TRUE. This
is what lazy evaluation means.

So if you go "substituting defs with vals" and thinking that "yeah this
is cool man", then either you're doing it wrong and something is going
to explode in your face or you've just won a bloody Fields Prize by
overturning computer science -- which is more likely? Exactly.

> When you have referential transparency, you should replace defs with
> vals/lazy vals.
You're free to believe this. I have absolutely no problem with that at
all. However, here are the facts:

* It is complete bullshit
* It is very very very very very very very well-documented as complete
bullshit
* I use Scala a lot in production
* I work with colleagues who use Scala
* I predict that if the bullshit keeps up, one day, one of those
colleagues is going to spray this bullshit at me
* If my prediction is true, I am going to have to deal with it
* I am then probably going to be told that I have to explain why it is
bullshit even though it is very very very very very very very
well-documented
* I am going to show this very very very very very very very
well-documented literature to someone and then they will reply, "yeah
but where is the documentation?" and expect me to keep taking them seriously
* I will be told that I have the burden of explanation when I have
interesting things to do and this is going to cause resentment

You are advising a curious person on this mailing list, so I believe you
have a responsibility of trust to that person. These are my personal
values. However, this responsibility also carries implications for other
people, such as myself, so even if you do not subscribe to these values,
I harbour resentment simply because that curious person is probably
going to spray the same nonsense at me one day and get upset when I
dismiss them. Then I have to deal with an upset person! When does it stop!?

Please stop for a minute and think about it -- that's all I am asking.
It just gets so silly sometimes!

On Sat, Oct 1, 2011 at 11:18, Tony Morris wrote:

>> However, you have not stated any of these things. You haven't stated
>> ANYTHING that could be used in advancing one's knowledge.

> Yes I have. I just get tired of repeating myself over and over. Shall I
> do it one more time? No. Why not just think it through, *even just a
> little bit*?

Ok, then remove yourself from the discussion. You are not adding
anything to it, and certainly removing a lot in terms of civility and
friendliness. If you are going to stay, let it be for something other
than useless annoying people.

On Sat, Oct 1, 2011 at 09:26, Brian Schlining <bschlining@gmail.com> wrote:

On Sat, Oct 1, 2011 at 07:10, Daniel Sobral <dcsobral@gmail.com> wrote:

If I have a Matrix class with a determinant method, it will certainly
improve performance of operations that use it if it's provided as a
val instead of a def. 

This is only true if the Matrix is immutable; If the matrix is mutable you'll need to recalculate the lu decomposition each time you want the determinant.


--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining@gmail.com

--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining@gmail.com

On Sat, Oct 1, 2011 at 11:59, Daniel Sobral <dcsobral@gmail.com> wrote:

On Sat, Oct 1, 2011 at 13:26, Brian Schlining <bschlining@gmail.com> wrote:
>
>
> On Sat, Oct 1, 2011 at 07:10, Daniel Sobral <dcsobral@gmail.com> wrote:
>>
>> If I have a Matrix class with a determinant method, it will certainly
>> improve performance of operations that use it if it's provided as a
>> val instead of a def.
>
> This is only true if the Matrix is immutable; If the matrix is mutable
> you'll need to recalculate the lu decomposition each time you want the
> determinant.

It is true under the parameters I specified. In particular, <much text here>

Sorry, I seemed to have missed the assumption of immutability.
And remember, sedulously eschew obfuscatory hyperverbosity and prolixity!
Cheers--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining@gmail.com



--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining@gmail.com

On Oct 1, 2011 10:40 AM, "Tony Morris" <tonymorris@gmail.com> wrote:
>
> On 02/10/11 00:26, Kevin Wright wrote:
> > On 1 October 2011 13:58, Tony Morris <tonymorris@gmail.com> wrote:
> >
> >> On 01/10/11 22:51, Kevin Wright wrote:
> >>> There's an - admittedly negligible - extra cost to retrieving a lazy val
> >> as
> >>> compared to retrieving a (regular) val, and I'm not entirely sure to what
> >>> extent the JVM can optimise this out of existence.
> >>>
> >>> If the property is trivial, such as "val diameter = radius * 2", then I'd
> >>> say it's more efficient to simply evaluate the thing up front, instead of
> >>> making it lazy.  Scala isn't Haskell, and the JVM isn't optimised to
> >> handle
> >>> everything being lazily evaluated.  We need to be aware of this if
> >>> performance is a consideration.
> >>>
> >>>
> >>> On 1 October 2011 13:42, Tony Morris <tonymorris@gmail.com> wrote:
> >>>
> >>>> On 01/10/11 22:37, Kevin Wright wrote:
> >>>>> While "def property = ..." can (and should)
> >>>>> be written instead as "val property = ..." or "lazy val property =
> >> ...",
> >>>>> depending on the computational cost.
> >>>> Please stop saying things like this (i.e. not true).
> >>>>
> >>>> --
> >>>> Tony Morris
> >>>> http://tmorris.net/
> >>>>
> >>>>
> >>>>
> >> If you think laziness has anything to do with performance, you're doing
> >> it wrong. Please stop spreading things that are not true. It is not
> >> helpful to people who might wish to learn. One day someone is going to
> >> say this to me in real life and expect me to take them seriously. I am
> >> going to blame you on that day.
> >>
> >>
> > I believe that the test to determine whether or not a lazy val has been
> > evaluated takes > 0 CPU cycles. It's negligible, and may be optimised to
> > nothing through the JVM and branch prediction.
> >
> > In general, laziness is independent of performance, and is often beneficial.
> >  But it's worth bearing in mind that a non-lazy val doesn't require the
> > test, and so could offer a small advantage for tight loops in particularly
> > performance-critical code.
> >
> >
> >> Do not say "Scala is not Haskell" to me either. By doing so, you simply
> >> pretend to provide an explanation, when it isn't -- you're just telling
> >> me something that I already know better than you do, and you know I know
> >> it better than you do -- what are you hoping to achieve with a
> >> pseudo-explanation like this? It is deliberately non-progressive. This
> >> is why I don't bother providing explanations to you. I'm not going to
> >> pretend.
> >>
> >>
> > So here's how my thought process went:
> >
> > Tony:
> > You just said something that isn't true
> >
> > Me:
> > Hmm, what could that be?
> >
> > I stated that defs can be substituted with vals in purely functional code.
> >  That's clearly true, it's the very definition of referential transparency,
> > and so true as to be axiomatic. Surely not the basis of your objection then.
> Fuck. What can I say now?
>
> That is *absolutely not true* and has been documented all over the
> planet since around the time your grandparents were born. This is the
> entire reason you use lazy evaluation -- to achieve termination while
> maintaining composition.

And here's the crux of the debate. 

Tony, while the scala community is the most 'fear's community I know, there is a huge gap in my own schooling on this issue.  Until this gap is broadly taught at schools you should probably assume these papers were written in caves using rocks and blood and some crud pictorial language for all the folks in industry who have read this.  As such, the burden of enlightenment is on the ignorant, but you can still provide links in a friendly way for us.   Perhaps a pregenerated response you can paste everytime this shows up.

However the rift between computer science and software engineering is still high.   Scala is an excellent example of bridging this gap, but the reality is that many of us (engineers) just don't have these studies as common knowledge.

I feel I've been spending the past 4 years making up for what they don't teach in undergrad.   If you wish to help, emails that can be taken as dismissive are a bad idea, even if they had an altogether different intention.

>
> In short, take any program that terminates under an "inside-out"
> (strict) evaluation. You are guaranteed that the same program terminates
> under an "outside-in" (lazy) evaluation. The opposite is NOT TRUE. This
> is what lazy evaluation means.
>
> So if you go "substituting defs with vals" and thinking that "yeah this
> is cool man", then either you're doing it wrong and something is going
> to explode in your face or you've just won a bloody Fields Prize by
> overturning computer science -- which is more likely? Exactly.
>
>
> > When you have referential transparency, you should replace defs with
> > vals/lazy vals.
> You're free to believe this. I have absolutely no problem with that at
> all. However, here are the facts:
>
> * It is complete bullshit
> * It is very very very very very very very well-documented as complete
> bullshit
> * I use Scala a lot in production
> * I work with colleagues who use Scala
> * I predict that if the bullshit keeps up, one day, one of those
> colleagues is going to spray this bullshit at me
> * If my prediction is true, I am going to have to deal with it
> * I am then probably going to be told that I have to explain why it is
> bullshit even though it is very very very very very very very
> well-documented
> * I am going to show this very very very very very very very
> well-documented literature to someone and then they will reply, "yeah
> but where is the documentation?" and expect me to keep taking them seriously
> * I will be told that I have the burden of explanation when I have
> interesting things to do and this is going to cause resentment
>
> You are advising a curious person on this mailing list, so I believe you
> have a responsibility of trust to that person. These are my personal
> values. However, this responsibility also carries implications for other
> people, such as myself, so even if you do not subscribe to these values,
> I harbour resentment simply because that curious person is probably
> going to spray the same nonsense at me one day and get upset when I
> dismiss them. Then I have to deal with an upset person! When does it stop!?
>
> Please stop for a minute and think about it -- that's all I am asking.
> It just gets so silly sometimes!
>
> --
> Tony Morris
> http://tmorris.net/
>
>

On 02/10/11 08:53, Josh Suereth wrote:
> On Oct 1, 2011 10:40 AM, "Tony Morris" wrote:
>> On 02/10/11 00:26, Kevin Wright wrote:
>>> On 1 October 2011 13:58, Tony Morris wrote:
>>>
>>>> On 01/10/11 22:51, Kevin Wright wrote:
>>>>> There's an - admittedly negligible - extra cost to retrieving a lazy
> val
>>>> as
>>>>> compared to retrieving a (regular) val, and I'm not entirely sure to
> what
>>>>> extent the JVM can optimise this out of existence.
>>>>>
>>>>> If the property is trivial, such as "val diameter = radius * 2", then
> I'd
>>>>> say it's more efficient to simply evaluate the thing up front, instead
> of
>>>>> making it lazy. Scala isn't Haskell, and the JVM isn't optimised to
>>>> handle
>>>>> everything being lazily evaluated. We need to be aware of this if
>>>>> performance is a consideration.
>>>>>
>>>>>
>>>>> On 1 October 2011 13:42, Tony Morris wrote:
>>>>>
>>>>>> On 01/10/11 22:37, Kevin Wright wrote:
>>>>>>> While "def property = ..." can (and should)
>>>>>>> be written instead as "val property = ..." or "lazy val property =
>>>> ...",
>>>>>>> depending on the computational cost.
>>>>>> Please stop saying things like this (i.e. not true).
>>>>>>
>>>>>> --
>>>>>> Tony Morris
>>>>>> http://tmorris.net/
>>>>>>
>>>>>>
>>>>>>
>>>> If you think laziness has anything to do with performance, you're doing
>>>> it wrong. Please stop spreading things that are not true. It is not
>>>> helpful to people who might wish to learn. One day someone is going to
>>>> say this to me in real life and expect me to take them seriously. I am
>>>> going to blame you on that day.
>>>>
>>>>
>>> I believe that the test to determine whether or not a lazy val has been
>>> evaluated takes > 0 CPU cycles. It's negligible, and may be optimised to
>>> nothing through the JVM and branch prediction.
>>>
>>> In general, laziness is independent of performance, and is often
> beneficial.
>>> But it's worth bearing in mind that a non-lazy val doesn't require the
>>> test, and so could offer a small advantage for tight loops in
> particularly
>>> performance-critical code.
>>>
>>>
>>>> Do not say "Scala is not Haskell" to me either. By doing so, you simply
>>>> pretend to provide an explanation, when it isn't -- you're just telling
>>>> me something that I already know better than you do, and you know I
> know
>>>> it better than you do -- what are you hoping to achieve with a
>>>> pseudo-explanation like this? It is deliberately non-progressive. This
>>>> is why I don't bother providing explanations to you. I'm not going to
>>>> pretend.
>>>>
>>>>
>>> So here's how my thought process went:
>>>
>>> Tony:
>>> You just said something that isn't true
>>>
>>> Me:
>>> Hmm, what could that be?
>>>
>>> I stated that defs can be substituted with vals in purely functional
> code.
>>> That's clearly true, it's the very definition of referential
> transparency,
>>> and so true as to be axiomatic. Surely not the basis of your objection
> then.
>> Fuck. What can I say now?
>>
>> That is *absolutely not true* and has been documented all over the
>> planet since around the time your grandparents were born. This is the
>> entire reason you use lazy evaluation -- to achieve termination while
>> maintaining composition.
> And here's the crux of the debate.
>
> Tony, while the scala community is the most 'fear's community I know, there
> is a huge gap in my own schooling on this issue. Until this gap is broadly
> taught at schools you should probably assume these papers were written in
> caves using rocks and blood and some crud pictorial language for all the
> folks in industry who have read this. As such, the burden of enlightenment
> is on the ignorant, but you can still provide links in a friendly way for
> us. Perhaps a pregenerated response you can paste everytime this shows up.
>
> However the rift between computer science and software engineering is still
> high. Scala is an excellent example of bridging this gap, but the reality
> is that many of us (engineers) just don't have these studies as common
> knowledge.
>
> I feel I've been spending the past 4 years making up for what they don't
> teach in undergrad. If you wish to help, emails that can be taken as
> dismissive are a bad idea, even if they had an altogether different
> intention.
I appreciate this. I truly do. However, there is a balance to be had.

I have been lecturing since 2001, I have fought for the instatement of
university curriculum that are actually useful instead of indoctrination
of brand names as it is today. I have been on an advisory team for the
construction of undergraduate curriculum of computer science degrees and
largely ignored, except when I didn't attach a brand name (such as "dot
net or java") -- I have tried it. I teach to the best of my ability and
learn as much as I can so that I can help teaching. This is *the best* I
can do.

However, there are others who like learning too. When they ask a
question, they are expecting an answer that they can trust to some
extent. When I see an answer that is simply the repetition of some
dogma, with absolutely no thought at all (to be distinguished from an
answer I simply disagree with or is contentious because nobody really
knows), then I am now caught in a twist.

Should I point out that it is wrong for the sake of the person asking?
This may backfire and be followed up with even more nonsense. Should I
keep quiet? But then that is why this nonsense exists to begin with!
Should I write an essay explaining why it is wrong? But then I'll be
very busy! Should I provide links and references and reading material?
But then I am asked, "where is the documentation?" or perhaps, "but that
documentation is not in my preferred syntax -- where are the parentheses"?

Think harder please. *We have a responsibility*.

But then I am asked, "where is the documentation?" or perhaps, "but that
documentation is not in my preferred syntax -- where are the parentheses"?

Just tell them that Lisp cornered the market on parentheses in the functional programming world back in the late fifties, forcing all future functional languages to largely do without.  And then suggest if the really need a parentheses fix, they can look at Scheme.  :-)

In the future, could we please please avoid the "You're wrong, and I'm not going to bother to explain why" statements? They are completely unhelpful, border on being rude sometimes from the wrong side of the border, and what with ancillary comments, decrease the SNR considerably. Definitely not what I come to the mailing list to read.
Ken

On 10/02/11 01:14, Erik Engbrecht wrote:
>
>>
>>
>> But then I am asked, "where is the documentation?" or perhaps, "but that
>> documentation is not in my preferred syntax -- where are the parentheses"?
>>
>
> Just tell them that Lisp cornered the market on parentheses in the
> functional programming world back in the late fifties, forcing all future
> functional languages to largely do without. And then suggest if the really
> need a parentheses fix, they can look at Scheme. :-)

In the spirit of providing relevant references:

http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong....

;-)

On Sat, Oct 01, 2011 at 05:14:09PM -0700, Erik Engbrecht wrote:
> And then suggest if the really need a parentheses fix, they can look at Scheme. :-)

This would be the relevant link, right?
http://okmij.org/ftp/Scheme/monad-in-Scheme.html

- Florian.

Cant just replace defs with vals or lazy vals... Each is different... A val takes up storage and is evaluated only once while a def is evaluated every time. Even if the only side effect is the CPU getting warmer, there is a difference... There are interface design considerations as well.
Laziness in general is not associated with performance as long as it will eventually execute. The "lazy val" in scala is associated with performance only if it may not execute and coming up with the value even once is worth the overhead in accessing it every time (an assumption of mine, not fact). For instance initializing a parser instance in a background thread would be worth it ;)
In fact, laziness may be anti-performance in the eyes of the end user... Since a lot of up-front computation may be lazily deferred to the last moment... :) 

Thanks,Razvan
On 2011-10-01, at 10:26 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

On 1 October 2011 13:58, Tony Morris < (tonymorris [at] gmail [dot] com> wrote:

On 01/10/11 22:51, Kevin Wright wrote:
> There's an - admittedly negligible - extra cost to retrieving a lazy val as
> compared to retrieving a (regular) val, and I'm not entirely sure to what
> extent the JVM can optimise this out of existence.
>
> If the property is trivial, such as "val diameter = radius * 2", then I'd
> say it's more efficient to simply evaluate the thing up front, instead of
> making it lazy.  Scala isn't Haskell, and the JVM isn't optimised to handle
> everything being lazily evaluated.  We need to be aware of this if
> performance is a consideration.
>
>
> On 1 October 2011 13:42, Tony Morris < (tonymorris [at] gmail [dot] com> wrote:
>
>> On 01/10/11 22:37, Kevin Wright wrote:
>>> While "def property = ..." can (and should)
>>> be written instead as "val property = ..." or "lazy val property = ...",
>>> depending on the computational cost.
>> Please stop saying things like this (i.e. not true).
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
If you think laziness has anything to do with performance, you're doing
it wrong. Please stop spreading things that are not true. It is not
helpful to people who might wish to learn. One day someone is going to
say this to me in real life and expect me to take them seriously. I am
going to blame you on that day.

I believe that the test to determine whether or not a lazy val has been evaluated takes > 0 CPU cycles. It's negligible, and may be optimised to nothing through the JVM and branch prediction.
In general, laziness is independent of performance, and is often beneficial.  But it's worth bearing in mind that a non-lazy val doesn't require the test, and so could offer a small advantage for tight loops in particularly performance-critical code.  

Do not say "Scala is not Haskell" to me either. By doing so, you simply
pretend to provide an explanation, when it isn't -- you're just telling
me something that I already know better than you do, and you know I know
it better than you do -- what are you hoping to achieve with a
pseudo-explanation like this? It is deliberately non-progressive. This
is why I don't bother providing explanations to you. I'm not going to
pretend.

So here's how my thought process went:
Tony:You just said something that isn't true
Me:Hmm, what could that be?
I stated that defs can be substituted with vals in purely functional code.  That's clearly true, it's the very definition of referential transparency, and so true as to be axiomatic. Surely not the basis of your objection then.
When you have referential transparency, you should replace defs with vals/lazy vals.  It seems eminently sensible to keep redoing the same work, and I've seen your own source code make extensive use of vals, so you can't be objecting to this either.
What's left?  The suggestion to use *either* vals or lazy vals, by a process of elimination this is the only possible remaining point of contention.  The question then is which of the two you object to.
Given your noted preference for re-implementing designs from Haskell in Scala, the fact that you answer Scala questions with Haskell source code, your repeated appeals for the use of more laziness in Scala, and online examples of your own source code that also demonstrate your beliefs in this regard; I can only infer that you don't think it's true that a method should be replaced with a strictly-evaluated field, you take issue with my suggestion to use a non-lazy val.
Although there's no reason in theory why lazy evaluation would be less performant than strict evaluation, the JVM is optimised for Java programs.  Imperative, strictly evaluated Java programs.  So there will be a performance benefit, in many scenarios, *on that particular platform*

Of course, it could be something else entirely that you were describing as untrue.  But you didn't specify... 

Just think about it a bit more before introducing bureaucratic dogma
that is chronically departed from any resemblance to reality. Scala is
not Java after all.


--
Tony Morris
http://tmorris.net/

> This is the
> entire reason you use lazy evaluation -- to achieve termination while
> maintaining composition.

And here's the crux of the debate. 

Lightbulb! 
Been sneaking around this for a while but the black and white of the sentence above turned on another lightbulb... And a part of the world Just became even brighter :) 
Thanks,Razvan
On 2011-10-01, at 6:53 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

On Oct 1, 2011 10:40 AM, "Tony Morris" < (tonymorris [at] gmail [dot] com> wrote:
>
> On 02/10/11 00:26, Kevin Wright wrote:
> > On 1 October 2011 13:58, Tony Morris < (tonymorris [at] gmail [dot] com> wrote:
> >
> >> On 01/10/11 22:51, Kevin Wright wrote:
> >>> There's an - admittedly negligible - extra cost to retrieving a lazy val
> >> as
> >>> compared to retrieving a (regular) val, and I'm not entirely sure to what
> >>> extent the JVM can optimise this out of existence.
> >>>
> >>> If the property is trivial, such as "val diameter = radius * 2", then I'd
> >>> say it's more efficient to simply evaluate the thing up front, instead of
> >>> making it lazy.  Scala isn't Haskell, and the JVM isn't optimised to
> >> handle
> >>> everything being lazily evaluated.  We need to be aware of this if
> >>> performance is a consideration.
> >>>
> >>>
> >>> On 1 October 2011 13:42, Tony Morris < (tonymorris [at] gmail [dot] com> wrote:
> >>>
> >>>> On 01/10/11 22:37, Kevin Wright wrote:
> >>>>> While "def property = ..." can (and should)
> >>>>> be written instead as "val property = ..." or "lazy val property =
> >> ...",
> >>>>> depending on the computational cost.
> >>>> Please stop saying things like this (i.e. not true).
> >>>>
> >>>> --
> >>>> Tony Morris
> >>>> http://tmorris.net/
> >>>>
> >>>>
> >>>>
> >> If you think laziness has anything to do with performance, you're doing
> >> it wrong. Please stop spreading things that are not true. It is not
> >> helpful to people who might wish to learn. One day someone is going to
> >> say this to me in real life and expect me to take them seriously. I am
> >> going to blame you on that day.
> >>
> >>
> > I believe that the test to determine whether or not a lazy val has been
> > evaluated takes > 0 CPU cycles. It's negligible, and may be optimised to
> > nothing through the JVM and branch prediction.
> >
> > In general, laziness is independent of performance, and is often beneficial.
> >  But it's worth bearing in mind that a non-lazy val doesn't require the
> > test, and so could offer a small advantage for tight loops in particularly
> > performance-critical code.
> >
> >
> >> Do not say "Scala is not Haskell" to me either. By doing so, you simply
> >> pretend to provide an explanation, when it isn't -- you're just telling
> >> me something that I already know better than you do, and you know I know
> >> it better than you do -- what are you hoping to achieve with a
> >> pseudo-explanation like this? It is deliberately non-progressive. This
> >> is why I don't bother providing explanations to you. I'm not going to
> >> pretend.
> >>
> >>
> > So here's how my thought process went:
> >
> > Tony:
> > You just said something that isn't true
> >
> > Me:
> > Hmm, what could that be?
> >
> > I stated that defs can be substituted with vals in purely functional code.
> >  That's clearly true, it's the very definition of referential transparency,
> > and so true as to be axiomatic. Surely not the basis of your objection then.
> Fuck. What can I say now?
>
> That is *absolutely not true* and has been documented all over the
> planet since around the time your grandparents were born. This is the
> entire reason you use lazy evaluation -- to achieve termination while
> maintaining composition.

And here's the crux of the debate. 

Tony, while the scala community is the most 'fear's community I know, there is a huge gap in my own schooling on this issue.  Until this gap is broadly taught at schools you should probably assume these papers were written in caves using rocks and blood and some crud pictorial language for all the folks in industry who have read this.  As such, the burden of enlightenment is on the ignorant, but you can still provide links in a friendly way for us.   Perhaps a pregenerated response you can paste everytime this shows up.

However the rift between computer science and software engineering is still high.   Scala is an excellent example of bridging this gap, but the reality is that many of us (engineers) just don't have these studies as common knowledge.

I feel I've been spending the past 4 years making up for what they don't teach in undergrad.   If you wish to help, emails that can be taken as dismissive are a bad idea, even if they had an altogether different intention.

>
> In short, take any program that terminates under an "inside-out"
> (strict) evaluation. You are guaranteed that the same program terminates
> under an "outside-in" (lazy) evaluation. The opposite is NOT TRUE. This
> is what lazy evaluation means.
>
> So if you go "substituting defs with vals" and thinking that "yeah this
> is cool man", then either you're doing it wrong and something is going
> to explode in your face or you've just won a bloody Fields Prize by
> overturning computer science -- which is more likely? Exactly.
>
>
> > When you have referential transparency, you should replace defs with
> > vals/lazy vals.
> You're free to believe this. I have absolutely no problem with that at
> all. However, here are the facts:
>
> * It is complete bullshit
> * It is very very very very very very very well-documented as complete
> bullshit
> * I use Scala a lot in production
> * I work with colleagues who use Scala
> * I predict that if the bullshit keeps up, one day, one of those
> colleagues is going to spray this bullshit at me
> * If my prediction is true, I am going to have to deal with it
> * I am then probably going to be told that I have to explain why it is
> bullshit even though it is very very very very very very very
> well-documented
> * I am going to show this very very very very very very very
> well-documented literature to someone and then they will reply, "yeah
> but where is the documentation?" and expect me to keep taking them seriously
> * I will be told that I have the burden of explanation when I have
> interesting things to do and this is going to cause resentment
>
> You are advising a curious person on this mailing list, so I believe you
> have a responsibility of trust to that person. These are my personal
> values. However, this responsibility also carries implications for other
> people, such as myself, so even if you do not subscribe to these values,
> I harbour resentment simply because that curious person is probably
> going to spray the same nonsense at me one day and get upset when I
> dismiss them. Then I have to deal with an upset person! When does it stop!?
>
> Please stop for a minute and think about it -- that's all I am asking.
> It just gets so silly sometimes!
>
> --
> Tony Morris
> http://tmorris.net/
>
>

On 03/10/11 02:14, Razvan Cojocaru wrote:
> Cant just replace defs with vals or lazy vals... Each is different... A val takes up storage and is evaluated only once while a def is evaluated every time. Even if the only side effect is the CPU getting warmer, there is a difference... There are interface design considerations as well.
>
> Laziness in general is not associated with performance as long as it will eventually execute. The "lazy val" in scala is associated with performance only if it may not execute and coming up with the value even once is worth the overhead in accessing it every time (an assumption of mine, not fact). For instance initializing a parser instance in a background thread would be worth it ;)
>
> In fact, laziness may be anti-performance in the eyes of the end user... Since a lot of up-front computation may be lazily deferred to the last moment... :)
>
> Thanks,
> Razvan

Oops http://paste.pocoo.org/show/486077/

Let's not advise newbies to do silly things anymore :)

On Saturday, October 1, 2011 6:51:43 PM UTC-5, Tony Morris wrote:

Should I point out that it is wrong for the sake of the person asking?
This may backfire and be followed up with even more nonsense. Should I
keep quiet? But then that is why this nonsense exists to begin with!
Should I write an essay explaining why it is wrong? But then I'll be
very busy!

As a tech writer who needs to communicate with engineers--most helpful, some with too little time, a few hostile, and some with no understanding of the "broader picture" that I deal with, I'd say the important thing is simply to remain polite. This does not imply taking a lot of time. For example, one way of making your point about lazy evaluation would be to say, "That statement is incorrect; strict evaluation may fail to terminate on cases where lazy evaluation does terminate, the converse is not true." This keeps the discussion at the level of ideas (you don't specify a person), uses less inflammatory language ("wrong" carries more emotional baggage than "incorrect"), and gets your point across in a single suggestion.
This strategy has worked well for me in the past. I've also seen many examples of people trying to advance their ideas by force (in the emotional sense) of argument. This never seems to work. (Actually, logical argument works surprisingly poorly too--people simply don't like giving up their ideas, and _proving_ those ideas wrong seems to entrench them more forcefully. I've found either presenting a de facto accomplishment that is clearly better than what was before, or a "nibbling" approach where you change something in such small increments that no one objects to any particular change, can work best in practice.)
Ken

On 2 October 2011 20:12, Ken McDonald <ykkenmcd@gmail.com> wrote:

On Saturday, October 1, 2011 6:51:43 PM UTC-5, Tony Morris wrote:

Should I point out that it is wrong for the sake of the person asking?
This may backfire and be followed up with even more nonsense. Should I
keep quiet? But then that is why this nonsense exists to begin with!
Should I write an essay explaining why it is wrong? But then I'll be
very busy!

As a tech writer who needs to communicate with engineers--most helpful, some with too little time, a few hostile, and some with no understanding of the "broader picture" that I deal with, I'd say the important thing is simply to remain polite. This does not imply taking a lot of time. For example, one way of making your point about lazy evaluation would be to say, "That statement is incorrect; strict evaluation may fail to terminate on cases where lazy evaluation does terminate, the converse is not true." This keeps the discussion at the level of ideas (you don't specify a person), uses less inflammatory language ("wrong" carries more emotional baggage than "incorrect"), and gets your point across in a single suggestion.

+1
"Please stop saying things like this (i.e. not true)""stop telling lies""I hope this incorrect answer..." "no""the should part is the not true part"etc.
All totally failed to convey the point that "strict evaluation may fail to terminate".  This being the core point that Tony was trying to get across despite the fact that *neither he nor anyone else* even mentioned that non-termination was relevant in this discussion.  I'm in complete agreement with the point, but simply had no idea that it had suddenly come into scope.  I'm not a mind reader!
Which brings me back to my earlier request: If *anyone* is going to call out some claim as being factually incorrect, then it's far more useful to say "that's wrong, because..." than it is to simply say "that's wrong"
Explaining why something is wrong, even if it's a single simple sentence, provides material that everyone on the list may learn from.  Anything else is just an insult, and wastes time where people try to figure exactly *what* is wrong.


 

This strategy has worked well for me in the past. I've also seen many examples of people trying to advance their ideas by force (in the emotional sense) of argument. This never seems to work. (Actually, logical argument works surprisingly poorly too--people simply don't like giving up their ideas, and _proving_ those ideas wrong seems to entrench them more forcefully. I've found either presenting a de facto accomplishment that is clearly better than what was before, or a "nibbling" approach where you change something in such small increments that no one objects to any particular change, can work best in practice.)
Ken

On 03/10/11 06:06, Kevin Wright wrote:
> On 2 October 2011 20:12, Ken McDonald wrote:
>
>> On Saturday, October 1, 2011 6:51:43 PM UTC-5, Tony Morris wrote:
>>> Should I point out that it is wrong for the sake of the person asking?
>>> This may backfire and be followed up with even more nonsense. Should I
>>> keep quiet? But then that is why this nonsense exists to begin with!
>>> Should I write an essay explaining why it is wrong? But then I'll be
>>> very busy!
>>>
>> As a tech writer who needs to communicate with engineers--most helpful,
>> some with too little time, a few hostile, and some with no understanding of
>> the "broader picture" that I deal with, I'd say the important thing is
>> simply to remain polite. This does not imply taking a lot of time. For
>> example, one way of making your point about lazy evaluation would be to say,
>> "That statement is incorrect; strict evaluation may fail to terminate on
>> cases where lazy evaluation does terminate, the converse is not true." This
>> keeps the discussion at the level of ideas (you don't specify a person),
>> uses less inflammatory language ("wrong" carries more emotional baggage than
>> "incorrect"), and gets your point across in a single suggestion.
>>
> +1
>
> "Please stop saying things like this (i.e. not true)"
> "stop telling lies"
> "I hope this incorrect answer..."
> "no"
> "the should part is the not true part"
> etc.
>
> All totally failed to convey the point that "strict evaluation may fail to
> terminate". This being the core point that Tony was trying to get across
> despite the fact that *neither he nor anyone else* even mentioned that
> non-termination was relevant in this discussion. I'm in complete agreement
> with the point, but simply had no idea that it had suddenly come into scope.
> I'm not a mind reader!
>
None were intended to convey the point about lazy evaluation. No, it
wasn't the core point I was trying to get across. If it were, I'd have
said exactly that.

I really resent attempts to explain to me how to communicate by those
for which there has been repeated failures to comprehend already, and
now trying to tell me how to make a point in a context that I was never
trying to make. Just give up on this please.

No, I was trying to register my objection that you were wrong on an
extremely important point (why/when to drop ()). I do this *solely* for
the benefit of the poor bastard who asked the original question who has
been bullshitted the whole way. Each time I register objection, this has
been followed up with more and more bullshit.

In this most recent case, you've explicitly advised to break programs.
Want to know why? Because I "reimplement haskell with scala", that's
why. This had "suddenly" come into scope because you brought it into
scope, remember? "you should replace defs with vals/lazy vals" -- that's
what you said. I can let it slide that you have no understanding of what
it is I do, (reimplement haskell design with scala -- WTF?), because the
consequences are not so dire (funny even?), but now let's advise some
poor, curious bugger to spin their programs in a loop?

I spoke up about the () nonsense because:
a) it is widely-believed
b) it is complete rubbish
c) I am expected to take it seriously
d) some poor learner asked himself/herself the question and didn't find
the answer, hence the mailing list question and has now been told a
misleading answer, with peer support of that answer

I really, truly do ask that someone who wants to discuss this issue put
some preliminary thought into it. I mean, some introspective, "is this
really a good idea?" kind of thought. Perhaps even learn about other
effect-tracking mechanisms out there -- you know, the ones that smarter
guys than ourselves sorted out. I think that would be a good idea before
getting started don't you?

On the point of lazy evaluation, Kevin, you were absolutely intent on
explaining to me how it all works. Great, you're enthusiastic. Now would
be a good time for you to know what it means. Why not go and find out on
your own volition? It only took me 10 or so lines of code to demonstrate
why your suggestion is terrible even in a trivial example -- where to
now? Why pester me because I told you were wrong -- go and read some
shit instead. Why not ask the mountain of literature out there that will
tell you why you were wrong? You probably don't know where to start --
you've been put through some shitty university course that indoctrinated
you with some garbage and now you popped out the other side unable to
see the forest through the trees. I am extremely sympathetic to this
problem and I will assist it in a way that I believe is effective --
just ask, don't whinge. One day you'll come back and tell me, "no
actually, you are wrong!" I look forward to that day -- please make it
happen.

Also, I will not pander to princesses. Note how I didn't list it. That's
because it isn't an option.

I don't have to explain why something is nonsense. I get to choose when
I explain why. Not you.

I really truly hope this helps.

Aside from the point Tony eventually made about the "can (and should)
" being dangerous, I'm actually fairly sure from some of Kevin's
previous posts that he's not intending this to be as sweeping a
statement as it came across.

For others benefit, vals are good for communicating something is
fixed, lazy vals do the same but may not get evaulated, defs always
get re-evaluated.

vals add to the memory usage of your objects, lazy vals that + the
synchronization object/primitive (afaik one per instance irrespective
of the number of lazy vals).

I'd just add that lazy vals may seem like a great calculation time
saver but you are better off (as with most performance related things)
profiling as to whether it really helps. IME if you have vals in
instances as cached results repeatedly used in tight loops (let alone
lazy vals) you are possibly going to get a noticeable performance hit
if the gc is going to get hammered. This led to Scales Xml dropping
vals and lazy vals in a number of places as the time spent in gc and
the resulting size of the trees was up to 10% higher (and for some
places more).

Its not a correctness or flexibility thing I'm on about here, just the
performance of a given application, don't assume adding a val will
speed an app up, profile it and make sure.

On Sat, Oct 1, 2011 at 2:37 PM, Kevin Wright wrote:
> Oh sure, the use of () to donate side effects is just a convention, the
> compiler certainly doesn't enforce this convention.

> in a purely functional design. While "def property = ..." can (and should)
> be written instead as "val property = ..." or "lazy val property = ...",
> depending on the computational cost.
>
>
> On 1 October 2011 13:25, Chris Twiner wrote:
>>
>> I think you are focussing on the wrong thing here. One is a syntactic
>> notation and the other is an effect system.
>>

Don't forget the one I missed and Tony pointed out, that values are always evaluated up-front while defs are not and thus can be composed. Without defs for instance you could not have Streams or... Well, monads for that matter.?!

Using vals everywhere is like writing the code while it runs... That was the vision that hit me when that lightbulb came on... I'm still recovering ;) ... beer helps :)

Cheers,
Razvan

On 2011-10-02, at 5:50 PM, Chris Twiner wrote:

> Aside from the point Tony eventually made about the "can (and should)
> " being dangerous, I'm actually fairly sure from some of Kevin's
> previous posts that he's not intending this to be as sweeping a
> statement as it came across.
>
> For others benefit, vals are good for communicating something is
> fixed, lazy vals do the same but may not get evaulated, defs always
> get re-evaluated.
>
> vals add to the memory usage of your objects, lazy vals that + the
> synchronization object/primitive (afaik one per instance irrespective
> of the number of lazy vals).
>
> I'd just add that lazy vals may seem like a great calculation time
> saver but you are better off (as with most performance related things)
> profiling as to whether it really helps. IME if you have vals in
> instances as cached results repeatedly used in tight loops (let alone
> lazy vals) you are possibly going to get a noticeable performance hit
> if the gc is going to get hammered. This led to Scales Xml dropping
> vals and lazy vals in a number of places as the time spent in gc and
> the resulting size of the trees was up to 10% higher (and for some
> places more).
>
> Its not a correctness or flexibility thing I'm on about here, just the
> performance of a given application, don't assume adding a val will
> speed an app up, profile it and make sure.
>
> On Sat, Oct 1, 2011 at 2:37 PM, Kevin Wright wrote:
>> Oh sure, the use of () to donate side effects is just a convention, the
>> compiler certainly doesn't enforce this convention.
>
>
>
>> in a purely functional design. While "def property = ..." can (and should)
>> be written instead as "val property = ..." or "lazy val property = ...",
>> depending on the computational cost.
>>
>>
>> On 1 October 2011 13:25, Chris Twiner wrote:
>>>
>>> I think you are focussing on the wrong thing here. One is a syntactic
>>> notation and the other is an effect system.
>>>

On 10/03/2011 09:34 AM, Razvan Cojocaru wrote:
> Don't forget the one I missed and Tony pointed out, that values are always evaluated up-front while defs are not and thus can be composed. Without defs for instance you could not have Streams or... Well, monads for that matter.?!
>
> Using vals everywhere is like writing the code while it runs... That was the vision that hit me when that lightbulb came on... I'm still recovering ;) ... beer helps :)
>
> Cheers,
> Razvan
You've also got to balance this desire for neat compositional with the
absence of effect-tracking in Scala -- since if you write your code all
nice and lazy up front, but introduce a side-effect, you're in for a
world of pain.

Hi Tony,

Can you please elaborate?

Out of pure guesswork, I assume you're against methods with empty parenthesis. Guessing more, it is because pure no-arg methods are simply constant methods (returning the same value) with the added benefit vs. vals of being lazy. How am I doing so far?

Having said that, if someone (very very stupid, I know) chooses to use methods with side effects (is a princess, too lazy to learn), are there any other objections to the use of () as a hint to those side effects? Obviously, only a visual hint, but better than a kick in the pants..

Ittay

On 10/03/2011 05:41 PM, Ittay Dror wrote:
> Hi Tony,
>
> Can you please elaborate?
>
> Out of pure guesswork, I assume you're against methods with empty
> parenthesis. Guessing more, it is because pure no-arg methods are
> simply constant methods (returning the same value) with the added
> benefit vs. vals of being lazy. How am I doing so far?
>
> Having said that, if someone (very very stupid, I know) chooses to use
> methods with side effects (is a princess, too lazy to learn), are
> there any other objections to the use of () as a hint to those side
> effects? Obviously, only a visual hint, but better than a kick in the
> pants..
>
> Ittay

My objections to using () to denote any meaning whatsoever are very
similar to my objections to crystal healing as a method of medicinal
treatment. Ineffective placebo at best, dangerous in practice. Let's be
clear on that: the very best you will ever achieve is absolutely nothing
at all and that is an extremely rare case.

Some people have a very hard time with this concept. I will put it
another way: by using this technique, you are in the very best possible
circumstance, having as much efficacy on your stated intended goal as a
chiropractor does on a patient with foraminal stenosis -- which is
absolutely nothing at all, absolutely. In practice, when you actually do
deploy this technique, the common case is the result of significant
adverse consequence. It is not possible, under any circumstance
whatsoever, to achieve a positive outcome, similar to crystal healing.
Handwave all you like, but placebos are not only departed from reality,
but also *dangerous* by proximal cause.

HTH

I'd be significantly less confused if I hadn't said:

"def property = ..." can (and should) be written instead as "val property = ..." or "lazy val property = ..."

At no point was I demanding that anybody force strict evaluation where it would change the behaviour of a program.  To suggest that I was demanding this is nothing less than disingenuous.

Let me expand on my prior statement to avoid further confusion and misunderstanding:

In purely functional code, a property encoded as a method can be safely translated to a lazy val, thanks to referential transparency.  Unless you can demonstrate with absolute certainty that the method is called once and one only, then this is a highly desirable change; as you avoid repeatedly calling a (potentially high-cost) method.  Instead, the results are memoised (cached) and simply reused for subsequent invocations.
There is a *small* memory cost in saving this result, but it's almost certainly going to be less than load placed on the heap/stack/gc by continually re-evaluating the same result.
Another option is to replace the method with a (strictly-evaluated) val, especially if it's know for certain that the property *will* be accessed. If the property is determined by other members that are also strictly evaluated, and if the calculation is sure not e.g. throw a divide by zero exception, then this is also safe.  It has the added advantage of eliminating the cost of testing to see if the property has been memoised yet (a vary small cost, but it may be relevant in tight loops).  After all, why muck about with the extra cost of deferring and later caching a result that you *know* is going to be evaluated anyway?

Lazy vals and by-name params are both Good Things(tm).  It's not without reason that many other programming languages choose to make all evaluation lazy by default.  Lazy evaluation avoid issues of the sort that Tony highlighted, they're also essential in amortising the cost of operations against purely functional data structures, allowing full immutability without incurring a performance hit.
However... Lazy evaluation isn't without problems.  Haskell will use strictness analysis to determine when strict behaviour can be used to improve performance, but it isn't perfect - and one of the main performance optimisations available to a Haskell programmer is selectively forcing strict evaluation (it's the first item listed under "general techniques" here: http://www.haskell.org/haskellwiki/Performance).  Lazy evaluation is also known to put a lot of pressure on the stack.  When your programs must run on actual hardware, and not just in theory, then too much laziness can make your program blow up with every bit as much finality as not enough laziness.

But, whatever you do:  If the concrete definition of a property is immutable, and you can take advantage of referential transparency, then make it either a val or a lazy val.  Don't make it a method and continually re-evaluate the thing, because that's just wasteful!


On 3 October 2011 09:01, Tony Morris <tonymorris@gmail.com> wrote:

On 10/03/2011 05:41 PM, Ittay Dror wrote:
> Hi Tony,
>
> Can you please elaborate?
>
> Out of pure guesswork, I assume you're against methods with empty
> parenthesis. Guessing more, it is because pure no-arg methods are
> simply constant methods (returning the same value) with the added
> benefit vs. vals of being lazy. How am I doing so far?
>
> Having said that, if someone (very very stupid, I know) chooses to use
> methods with side effects (is a princess, too lazy to learn), are
> there any other objections to the use of () as a hint to those side
> effects? Obviously, only a visual hint, but better than a kick in the
> pants..
>
> Ittay

My objections to using () to denote any meaning whatsoever are very
similar to my objections to crystal healing as a method of medicinal
treatment. Ineffective placebo at best, dangerous in practice. Let's be
clear on that: the very best you will ever achieve is absolutely nothing
at all and that is an extremely rare case.

Some people have a very hard time with this concept. I will put it
another way: by using this technique, you are in the very best possible
circumstance, having as much efficacy on your stated intended goal as a
chiropractor does on a patient with foraminal stenosis -- which is
absolutely nothing at all, absolutely. In practice, when you actually do
deploy this technique, the common case is the result of significant
adverse consequence. It is not possible, under any circumstance
whatsoever, to achieve a positive outcome, similar to crystal healing.
Handwave all you like, but placebos are not only departed from reality,
but also *dangerous* by proximal cause.

HTH


--
Tony Morris
http://tmorris.net/

--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

For the love of all that is true, please give up. Please.

On 03/10/11 21:27, Kevin Wright wrote:
> I'd be significantly less confused if I hadn't said:
>
> "def property = ..." can (and should) be written instead as "val property =
> ..."* or "lazy val property = ..."*
>
>
> At no point was I demanding that anybody force strict evaluation where it
> would change the behaviour of a program. To suggest that I was demanding
> this is nothing less than disingenuous.
>
>
> Let me expand on my prior statement to avoid further confusion and
> misunderstanding:
>
>
> In purely functional code, a property encoded as a method can be safely
> translated to a lazy val, thanks to referential transparency. Unless you
> can demonstrate with absolute certainty that the method is called once and
> one only, then this is a highly desirable change; as you avoid repeatedly
> calling a (potentially high-cost) method. Instead, the results are memoised
> (cached) and simply reused for subsequent invocations.
>
> There is a *small* memory cost in saving this result, but it's almost
> certainly going to be less than load placed on the heap/stack/gc by
> continually re-evaluating the same result.
>
> Another option is to replace the method with a (strictly-evaluated) val,
> especially if it's know for certain that the property *will* be accessed. If
> the property is determined by other members that are also strictly
> evaluated, and if the calculation is sure not e.g. throw a divide by zero
> exception, then this is also safe. It has the added advantage of
> eliminating the cost of testing to see if the property has been memoised yet
> (a vary small cost, but it may be relevant in tight loops). After all, why
> muck about with the extra cost of deferring and later caching a result that
> you *know* is going to be evaluated anyway?
>
>
> Lazy vals and by-name params are both Good Things(tm). It's not without
> reason that many other programming languages choose to make all evaluation
> lazy by default. Lazy evaluation avoid issues of the sort that Tony
> highlighted, they're also essential in amortising the cost of operations
> against purely functional data structures, allowing full immutability
> without incurring a performance hit.
>
> However... Lazy evaluation isn't without problems. Haskell will use
> strictness analysis to determine when strict behaviour can be used to
> improve performance, but it isn't perfect - and one of the main performance
> optimisations available to a Haskell programmer is selectively forcing
> strict evaluation (it's the first item listed under "general techniques"
> here: http://www.haskell.org/haskellwiki/Performance). Lazy evaluation is
> also known to put a lot of pressure on the stack. When your programs must
> run on actual hardware, and not just in theory, then too much laziness can
> make your program blow up with every bit as much finality as not enough
> laziness.
>
>
> But, whatever you do: If the concrete definition of a property is
> immutable, and you can take advantage of referential transparency, then make
> it either a val *or a lazy val*. Don't make it a method and continually
> re-evaluate the thing, because that's just wasteful!
>
>
>
> On 3 October 2011 09:01, Tony Morris wrote:
>
>> On 10/03/2011 05:41 PM, Ittay Dror wrote:
>>> Hi Tony,
>>>
>>> Can you please elaborate?
>>>
>>> Out of pure guesswork, I assume you're against methods with empty
>>> parenthesis. Guessing more, it is because pure no-arg methods are
>>> simply constant methods (returning the same value) with the added
>>> benefit vs. vals of being lazy. How am I doing so far?
>>>
>>> Having said that, if someone (very very stupid, I know) chooses to use
>>> methods with side effects (is a princess, too lazy to learn), are
>>> there any other objections to the use of () as a hint to those side
>>> effects? Obviously, only a visual hint, but better than a kick in the
>>> pants..
>>>
>>> Ittay
>> My objections to using () to denote any meaning whatsoever are very
>> similar to my objections to crystal healing as a method of medicinal
>> treatment. Ineffective placebo at best, dangerous in practice. Let's be
>> clear on that: the very best you will ever achieve is absolutely nothing
>> at all and that is an extremely rare case.
>>
>> Some people have a very hard time with this concept. I will put it
>> another way: by using this technique, you are in the very best possible
>> circumstance, having as much efficacy on your stated intended goal as a
>> chiropractor does on a patient with foraminal stenosis -- which is
>> absolutely nothing at all, absolutely. In practice, when you actually do
>> deploy this technique, the common case is the result of significant
>> adverse consequence. It is not possible, under any circumstance
>> whatsoever, to achieve a positive outcome, similar to crystal healing.
>> Handwave all you like, but placebos are not only departed from reality,
>> but also *dangerous* by proximal cause.
>>
>> HTH
>>
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>

I could not resist doing this little REPL example
(albeit only a little bit related to this discussion)

scala> var tonyIsGoingToShowUsAnExample = false
tonyIsGoingToShowUsAnExample: Boolean = false

scala> def weAreStillWaiting = !tonyIsGoingToShowUsAnExample
weAreStillWaiting: Boolean

scala> while(weAreStillWaiting) {
     |  if (scala.math.random < 0.1) {
     |   tonyIsGoingToShowUsAnExample = true
     |  }
     |  println("weAreStillWaiting")
     | }
weAreStillWaiting
weAreStillWaiting
weAreStillWaiting
weAreStillWaiting
weAreStillWaiting
weAreStillWaiting

scala> var tonyIsGoingToShowUsAnExample = false
tonyIsGoingToShowUsAnExample: Boolean = false

scala> lazy val weAreStillWaiting = !tonyIsGoingToShowUsAnExample
weAreStillWaiting: Boolean

scala> while(weAreStillWaiting) {
     |  if (scala.math.random < 0.1) {
     |   tonyIsGoingToShowUsAnExample = true
     |  }
     |  println("weAreStillWaiting")
     | }
weAreStillWaiting
weAreStillWaiting
weAreStillWaiting
weAreStillWaiting
weAreStillWaiting
weAreStillWaiting
....
weAreStillWaiting
weAreStillWaiting
weAreStillWaiting
weAreStillWaiting
weAreStillWaiting
weAreStillWaiting^C


--
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination

I think a good parallel is having a policy of prefixing a variable name with it's expected type within a dynamic language (like strName or intAge). It is not enforced in any way except as a policy, so it can be dangerous (and wrong) to depend on it.

Derek Williams

On Oct 3, 2011 1:41 AM, "Ittay Dror" <ittay.dror@gmail.com> wrote:
> Hi Tony,
>
> Can you please elaborate?
>
> Out of pure guesswork, I assume you're against methods with empty
> parenthesis. Guessing more, it is because pure no-arg methods are simply
> constant methods (returning the same value) with the added benefit vs. vals
> of being lazy. How am I doing so far?
>
> Having said that, if someone (very very stupid, I know) chooses to use
> methods with side effects (is a princess, too lazy to learn), are there any
> other objections to the use of () as a hint to those side effects?
> Obviously, only a visual hint, but better than a kick in the pants..
>
> Ittay

Sorry, a bit of finger-trouble
disregard the "When" at the end...


On Mon, Oct 3, 2011 at 7:47 PM, Atle Osmoen-Prange <atle.prange@gmail.com> wrote:

I love it when Tony replies "No" to a post in this forum. 
a) I learn a lot of English by reading the posts. b) With a little bit of patience, i get some deeper insight into scala
When 

I love it when Tony replies "No" to a post in this forum. 
a) I learn a lot of English by reading the posts.b) With a little bit of patience, i get some deeper insight into scala
When 

On Sunday, October 2, 2011 4:29:21 PM UTC-5, Tony Morris wrote:

I really resent attempts to explain to me how to communicate by those
for which there has been repeated failures to comprehend already, and
now trying to tell me how to make a point in a context that I was never
trying to make. Just give up on this please.

I really resent being expected to mind-read. Just give up on this please. 

No, I was trying to register my objection that you were wrong on an
extremely important point (why/when to drop ()). I do this *solely* for
the benefit of the poor bastard who asked the original question who has
been bullshitted the whole way. Each time I register objection, this has
been followed up with more and more bullshit.

Most of which was caused because of the way you registered your objection, and the lack of even a _half-sentence_ of factual support for it. 

I don't have to explain why something is nonsense. I get to choose when

I explain why. Not you.

Guess what Tony. You're on a public forum, with readers with a wide range of knowledge and skills. If you make statements like "This is nonsense" with no further explanation, you are wasting everybody's time. For the people who know what you mean, you've made a statement devoid of useful content, and for those who _don't_ know what you mean, you've made a statement that is--devoid of useful content. Great. 
You're a very bright guy. For that reason I would hate to lose your input on the forums. You're also often arrogant and rude and operate under the assumption that people have nothing better to do with their time all day every day than to educate themselves they way you think they should be educated. Make allowance for the fact that for many readers, the time they spend on the forum is maybe break time at work, after which they need to go home to spend time with family, and and you may understand why you expectations are simply not realistic.
Final food for though--I'm fairly bright; not at your level, but well above average. I'm attacking the way you interact on the forums. Many other bright people, ranging I'm guessing from my level on up, are saying similar things, albeit in shorter form. The only one to defend yourself is--you. In any kind of analytical mind that isn't suffering from emotional baggage, this should be cause to reevaluate your strategy.
I'm still looking forward to the book.
Ken

> You're a very bright guy. For that reason I would hate to lose your input on the forums.

same for me by the way

I only tried to be "funny with my example
(and, yes, kind of challenge Tony to come up with minimal "hello world"-like
examples illustrating his statements (so that everybody can benefit from
his knowledge))

Luc



--
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination

This entire thread has become very sad. It exemplifies why a very large
number of JVM-based folk consider Scala to be a joke -- they identify
the Scala community in this mode with Scala and thereby lose the whole
point.

Yours, Depressed of Clapham Junction.

Are you aware that your example involves mutability and thus cannot
serve as an example to illustrate the differences between lazy and
strict evaluation? Haskell uses an effect system to prevent the things
you have shown from happening.

A little explanation: See "evaluation" as the process of replacing a
term by another term, e. g. `f(3)` by `3+2` if `f` is defined as `x => x
+ 2`. There are a couple of evaluation strategies, e. g.:

* strict (sometimes called "by-value") evaluation, which is used in most
popular programming languages -- before replacing `f(term)`, `term` must
be completely evaluated first

* lazy evaluation, with the most notable language being Haskell -- when
replacing a term, the outermost function call is replaced (IIRC, please
correct me if I'm wrong)

There are two important results which can be proven:

(1) If the evaluation of a term terminates using two different
strategies, the result is the same.

(2) If there is an strategy under which the evaluation of a term
terminates, it also terminates under lazy evaluation.

Interestingly enough, most strict languages offer lazy evaluation for
special cases, e. g. `if` - `then` - `else` or the so called "short
circuit" boolean functions `&&` and `||`.

On Mon, Oct 3, 2011 at 9:11 PM, Lars Hupel <hupel@in.tum.de> wrote:

Are you aware that your example involves mutability and thus cannot
serve as an example to illustrate the differences between lazy and
strict evaluation? Haskell uses an effect system to prevent the things
you have shown from happening.

of course I am aware of this
(remember: I mentioned "only a little bit related to this discussion")

my goal was (among others) to show that it is dangerous
to treat defs and lazy vals as equivalent "the brute force way"

I hope that my (agreed, somewhat stupid) example was useful for
some members on the list (especially those who are new to Scala)

And, yes, I'm still waiting for more subtle "hello world"- like
examples coming fom other members of the list showing
(to more experienced Scala users) the semantic difference of
defs and lazy vals without using mutability

do you feel challenged Lars ?

 

A little explanation: See "evaluation" as the process of replacing a
term by another term, e. g. `f(3)` by `3+2` if `f` is defined as `x => x
+ 2`. There are a couple of evaluation strategies, e. g.:

* strict (sometimes called "by-value") evaluation, which is used in most
popular programming languages -- before replacing `f(term)`, `term` must
be completely evaluated first

* lazy evaluation, with the most notable language being Haskell -- when
replacing a term, the outermost function call is replaced (IIRC, please
correct me if I'm wrong)

There are two important results which can be proven:

(1) If the evaluation of a term terminates using two different
strategies, the result is the same.

(2) If there is an strategy under which the evaluation of a term
terminates, it also terminates under lazy evaluation.

Interestingly enough, most strict languages offer lazy evaluation for
special cases, e. g. `if` - `then` - `else` or the so called "short
circuit" boolean functions `&&` and `||`.

I know about (different dialects of) the Church-Rosser theorem
(and its consequences)


anyway, thanks so much for your reply

--
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination

On 3 Oct 2011, at 20:07, Russel Winder wrote:
> This entire thread has become very sad. It exemplifies why a very large
> number of JVM-based folk consider Scala to be a joke -- they identify
> the Scala community in this mode with Scala and thereby lose the whole
> point.
>
> Yours, Depressed of Clapham Junction.

Seconded. Right now, Scala still looks like the best horse to back to me, but it's deeply depressing to see us (the Scala community) doing our best to commit linguicide :-(

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher

Hi guys,
Having been following this thread for a while, trying to sort the wood
from the trees - can I please check that I've got it right?

a) f and f() are not the same thing although they can both be used to
do the same thing in many situations.
b) the f() from is considered a bad thing that probably shouldn't be
there by some people and a necessary evil for java interoperability by
others - and I don't think anyone has said it should be used as the
norm in straight scala.
c) in a completely immutable environment def and lazy val can be used
interchangeably though the compiler does quite different things with
them. There are votes for lazy val because it results in a computation
only being run once, whereas def is run every time (unless some really
clever optimisation is possible). However, there is a counter-argument
to do with GC and small object creation that def might under some
circumstances be more efficient. So maybe this an "optimisation" issue
that should be left until you know performance is critical.
d) non-lazy val forces immediate (strict) evaluation which can
sometimes be a bad thing and is never a necessary thing (which maybe
something to do with some guys named Church and Rosser, if I've
understood the last post correctly).
e) lazy val could be a dangerously bad thing vs def in a mutable environment

If any of the above is incorrect, I would appreciate a helpful comment
on how i've got it wrong.

Tim

On 10/03/11 20:07, Russel Winder wrote:

> This entire thread has become very sad. It exemplifies why a very large
> number of JVM-based folk consider Scala to be a joke -- they identify
> the Scala community in this mode with Scala and thereby lose the whole
> point.

I agree absolutely. scala-users is the first place new people (such as
myself) will usually turn to but unfortunately I think some of the
interactions on it are very destructive. They would be pretty
unacceptable on a core developers list, on a list that's supposed to be
about evangelising Scala they are incredibly counter-productive. I
don't believe scala-users is an appropriate place to bellow at people
for being dullards.

I'm struggling as it is with the rough edges of Scala (e.g. lack of
documentation) and I'm really not interested in the battle of egos that
seems to flare up on scala-users every week or so. If anything I'm
verging on unsubscribing and throwing my Scala book in the bin. But
then again, perhaps the purpose of all the intellectual chest-beating is
to drive people "stupid" people like me away?

Hey Tim,

I like those kind of contributions to the list.
Research stops if there are no doubts any more.

I have no problem admitting that I cannot find
any trivial counter examples for all your statements
(but, maybe, I'm not clever enough to find them immediately).

As far as c) is concerned, I think that (but I may be wrong (!)),
at a certain point in this thread there were statements about
difference in non-termination, but, then again, it is up to more
clever people than me to come up with the standard (counter-)examples
they have in mind.

Luc

On Mon, Oct 3, 2011 at 10:33 PM, Tim Pigden <tim.pigden@optrak.com> wrote:

Hi guys,
Having been following this thread for a while, trying to sort the wood
from the trees - can I please check that I've got it right?

a) f and f() are not the same thing although they can both be used to
do the same thing in many situations.
b) the f() from is considered a bad thing that probably shouldn't be
there by some people and a necessary evil for java interoperability by
others - and I don't think anyone has said it should be used as the
norm in straight scala.
c) in a completely immutable environment def and lazy val can be used
interchangeably though the compiler does quite different things with
them. There are votes for lazy val because it results in a computation
only being run once, whereas def is run every time (unless some really
clever optimisation is possible). However, there is a counter-argument
to do with GC and small object creation that def might under some
circumstances be more efficient. So maybe this an "optimisation" issue
that should be left until you know performance is critical.
d) non-lazy val forces immediate (strict) evaluation which can
sometimes be a bad thing and is never a necessary thing (which maybe
something to do with some guys named Church and Rosser, if I've
understood the last post correctly).
e) lazy val could be a dangerously bad thing vs def in a mutable environment

If any of the above is incorrect, I would appreciate a helpful comment
on how i've got it wrong.

Tim

--
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination