- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: When to Drop "()" in a Function Call
Note that some hold strong objection to using this "convention."
On 01/10/2011 1:10 AM, "Seyed H. HAERI (Hossein)" <hossein [dot] haeri [at] gmail [dot] com> wrote:
Re: When to Drop "()" in a Function Call
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
Re: When to Drop "()" in a Function Call
Guys : let's move this current thread to scala-debate if you wish to continue.
Also, let's try to keep things professional on this list. This is a list for newcomers/users and we *expect* a lot of instruction here.
Profanity is unnecessary in teaching. Period. Please keep it off list.
The tone of this discussion has greatly improved from the original, but I think these kinds of thread do not reflect well on our community. Let's try to focus on the user in this thread. We can all be helpful and meet users *were they are at* on this thread. We don't want to have to moderate this list to keep things PC.
- Josh
Re: When to Drop "()" in a Function Call
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/04/2011 11:06 PM, Josh Suereth wrote:
> Guys : let's move this current thread to scala-debate if you wish to
> continue.
>
> Also, let's try to keep things professional on this list. This is a list
> for newcomers/users and we *expect* a lot of instruction here.
>
> Profanity is unnecessary in teaching. Period. Please keep it off list.
>
> The tone of this discussion has greatly improved from the original, but I
> think these kinds of thread do not reflect well on our community. Let's
> try to focus on the user in this thread. We can all be helpful and meet
> users *were they are at* on this thread. We don't want to have to moderate
> this list to keep things PC.
>
> - Josh
>
I hope for more making sense in the future.
PS: profanity doesn't exist.
Re: When to Drop "()" in a Function Call
That's no reason to use it.
Re: When to Drop "()" in a Function Call
On Mon, Oct 10, 2011 at 8:21 AM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:
If it doesn't exist, you cannot use it.
--
Viktor Klang
Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts
Twitter: @viktorklang
Re: When to Drop "()" in a Function Call
2011/10/10 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>
And yet, he did. Thus we must conclude that it does exist!
Re: When to Drop "()" in a Function Call
2011/10/10 Naftoli Gugenheim <naftoligug [at] gmail [dot] com>
Precisely my point.
--
Viktor Klang
Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts
Twitter: @viktorklang
Re: When to Drop "()" in a Function Call
But, come to think of it, we use things that don't exist, all the time... like time travel or $USD...
Thanks,Razvan
On 2011-10-10, at 5:03 AM, √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com> wrote:
Re: When to Drop "()" in a Function Call
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 [dot] dror [at] gmail [dot] 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
Re: When to Drop "()" in a Function Call
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
Re: When to Drop "()" in a Function Call
In general, Tony, I recommend you re-read this entire thread, particularly your posts. Try to imagine you're another person reading them. You may notice several things that you didn't as you were writing. For one, there is precious, precious little in terms of actual explanation, if any. Yes, you linked to code that demonstrates your point. And you may find there was a lot of energy wasted on writing lines that did not contain any value.
Tony, is there atheistic material on how to develop humility?
On Mon, Oct 3, 2011 at 4:01 AM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
Re: When to Drop "()" in a Function Call
Please don't drag this thread back up on scala-user. Private email or, failing that, scala-debate would be more suitable IMO.
-jason
Re: When to Drop "()" in a Function Call
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 [at] gmail [dot] com> wrote:
--
Kevin Wright
mail: kevin [dot] wright [at] scalatechnology [dot] com
gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev [dot] lee [dot] wright [at] gmail [dot] 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
Re: When to Drop "()" in a Function Call
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/
>>
>>
>>
>
Re: When to Drop "()" in a Function Call
(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
Re: When to Drop "()" in a Function Call
I gave an example. Kevin went right ahead and ignored it. It's so fun giving examples.
On 04/10/2011 2:53 AM, "Luc Duponcheel" <luc [dot] duponcheel [at] gmail [dot] com> wrote:> 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
Re: When to Drop "()" in a Function Call
... http://paste.pocoo.org/show/486746/ ...
sorry, I must have missed the tree in the woods
nice example indeed
but does this particular example not illustrate a difference
in semantics between, on the one hand, val, and,
on the other hand, both def and lazy val?
I'm starting to get more and more convinced that we all agree
about all this and that (somehow) this discussion ran out of hand
because of unfortunate misunderstandings.
Luc
On Mon, Oct 3, 2011 at 10:57 PM, Tony Morris <tmorris [at] tmorris [dot] net> wrote:
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
Re: When to Drop "()" in a Function Call
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/04/2011 07:39 PM, Luc Duponcheel wrote:
> Tony
>
> ... http://paste.pocoo.org/show/486746/ ...
>
> sorry, I must have missed the tree in the woods
>
> nice example indeed
>
> but does this particular example not illustrate a difference
> in semantics between, on the one hand, val, and,
> on the other hand, both def and lazy val?
>
> I'm starting to get more and more convinced that we all agree
> about all this and that (somehow) this discussion ran out of hand
> because of unfortunate misunderstandings.
>
>
Right. This example given could have "def" replaced with "lazy val" to
achieve the same semantics. So just to be clear on this; the following
statements are all false (and it didn't take much to demonstrate it!).
They are all false because they are simply blatantly wrong or use
fallacious reasoning to derive their conclusions. The conclusions of all
the reasoning is false too, but this is not entirely demonstrated in the
above code.
I will attach some commentary for clarity (one last time -- please, I beg).
* "defs can be substituted with vals in purely functional code."
The original claim. Unequivocally false -- demonstrated.
* "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!"
"because ... wasteful" is fallacious reasoning. Nothing is being wasted.
The false claim that we should replace def with lazy val is one that I
have no desire to demonstrate (after the catastrophe of this thread),
but I am more than happy to watch you and giggle if you choose to follow
this advice -- if that's what you want of course, it's for your benefit,
not mine. It is sufficient to say that you would not observe any
differing termination semantics in your program, so it's a completely
different issue, but still a very serious issue -- do not follow this
advice -- it is extremely important, but for other reasons to those
demonstrated.
*cough* space leak *cough* Did someone say... oh never mind.
* '"def property = ..." can (and should) be written instead as "val
property = ..." or "lazy val property = ...", depending on the
computational cost.'
No it most definitely should not. Further, no decision here should be
"dependent on the computational cost." This is both flawed reasoning
accompanied by a false conclusion.
For the benefit of anyone who is "on the fence" on this matter, I am
strongly compelled to advise *against* all the advice given so far. This
includes the advice given regarding the original topic of using () to
denote "side-effect", which I have not addressed (nor will I for now).
Thanks for the reply Luc and for helping bring it back on track. I felt
like I had a n-ary tree of nonsense and if I tried to tackle a leaf, it
would spring a new branch of non-deterministic size!
I shall defer further commentary from here and hope that someone,
anyone, got some sound advice from it. Signing out of this thread.
Re: When to Drop "()" in a Function Call
Tony, I think it would be good to stop this thread now. You have
demonstrated your intellectual superiority in sufficient detail. Let's
keep the precious bandwidth of this group to help people instead of
bolstering egos.
Re: When to Drop "()" in a Function Call
-------- Original-Nachricht --------
> Datum: Tue, 4 Oct 2011 11:39:43 +0200
> Von: Luc Duponcheel
> An: Tony Morris
> CC: Kevin Wright , scala-user [at] googlegroups [dot] com
> Betreff: Re: [scala-user] When to Drop "()" in a Function Call
> Tony
>
> ... http://paste.pocoo.org/show/486746/ ...
>
> sorry, I must have missed the tree in the woods
"not to see the wood for the trees"
>
> nice example indeed
>
> but does this particular example not illustrate a difference
> in semantics between, on the one hand, val, and,
> on the other hand, both def and lazy val?
>
> I'm starting to get more and more convinced that we all agree
> about all this and that (somehow) this discussion ran out of hand
> because of unfortunate misunderstandings.
>
>
>
> Luc
>
>
> On Mon, Oct 3, 2011 at 10:57 PM, Tony Morris wrote:
>
> > I gave an example. Kevin went right ahead and ignored it. It's so fun
> > giving examples.
> > On 04/10/2011 2:53 AM, "Luc Duponcheel"
> wrote:
> > > 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
> >
>
>
>
Re: When to Drop "()" in a Function Call
I even modified the example to use lazy vals, instead of the strict vals that you presented, and it appears to work flawlessly:
http://paste.pocoo.org/show/486746/
Do you have a suitable counter-example, not involving mutability, that demonstrates a case in which a lazy val may be substituted for a method in this fashion?
On 3 October 2011 21:57, Tony Morris <tmorris [at] tmorris [dot] net> wrote:
Re: When to Drop "()" in a Function Call
On 10/04/2011 08:45 AM, Kevin Wright wrote:
> I've looked at your example, but have to say that I couldn't see how
> it demonstrated my claim was wrong. Specifically the suggestion that
> methods can be substituted with lazy vals when only immutable objects
> are involved.
>
> I even modified the example to use lazy vals, instead of the strict
> vals that you presented, and it appears to work flawlessly:
>
> http://paste.pocoo.org/show/486746/
>
> Do you have a suitable counter-example, not involving mutability, that
> demonstrates a case in which a lazy val may be substituted for a
> method in this fashion?
>
>
>
It doesn't stop. I'm done.
Re: When to Drop "()" in a Function Call
On 3 October 2011 23:45, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com> wrote:
Re: When to Drop "()" in a Function Call
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 `||`.
Re: Re: When to Drop "()" in a Function Call
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 ?
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
Re: When to Drop "()" in a Function Call
> 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 ?
Sorry Luc, but that's actually the end of my knowledge when it comes to
term rewriting.
As far as I know, if you only consider semantics, there should be no
difference between `lazy val` and `def`. I vaguely remember something
the Haskell compiler does, where it basically replaces a second
occurrence of an expression by a pointer to the first one (however that
was called).
Or, as Jason said, a `lazy val` is just a cache for a `def` without a
parameter list.
Re: Re: When to Drop "()" in a Function Call
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
Re: Re: When to Drop "()" in a Function Call
Ken
Re: Re: When to Drop "()" in a Function Call
Hi Tim,
Stack Overflow is a better venue for these questions, it tends to be a bit less chatty. http://stackoverflow.com/tags/scala/info
A Scala method can be declared with N parameter sections.
def f // 0 sectionsdef g() // 1 (empty) section def g(a: Any) // 1 sectiondef h(a: Any)(b: Any) // 2 sections
Similary, a method call has N argument lists
f // 0 arg listsg() // 1 arg list
To make Java interop a bit nicer, Scala will let you call a method with one, empty parameter section with zero argument lists. So you can call `javaObect.getA.getB` without the parens.
But Scala will not *remove* an argument list, so this is an error.
f() // too many argument lists.
One more point: the last parameter section can be marked 'implicit'. If you want the compiler to lookup the arguments to pass to the section for you, you do not include an argument list. An example I saw recently was someone confused when calling `toMap`, which takes an implicit paramater to prove that the list contains Tuple2 entries.
List((1, 2), (3, 4)).toMap // okayList((1, 2), (3, 4)).toMap() // wrong!
The standard library and Programming in Scala recommends that you use an empty parameter list when defining a method with side-effects like `mutableCollection.clear()`, and no parameter list for a method that is a 'property accessor', such as `collection.size`. Tony frowns on this convention, for the reasons he stated. But it exists, so you should at least know about it, and decide for yourself how to declare your methods.
A lazy val is just a cached method, without you having to write the cache yourself. The usual trade offs with caching apply, as well as a few special points, such as the lock obtained when initializing the lazy val.
A val member of a class is initialized during the constructor of that class. You don't need to know about those guys to grasp this one.
Using a lazy val as a cache doesn't work if you ever need to invalidate that cache. -jason
Re: Re: When to Drop "()" in a Function Call
Matthew.
Re: Re: When to Drop "()" in a Function Call
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 [dot] pigden [at] optrak [dot] com> wrote:
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
Re: When to Drop "()" in a Function Call
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
Re: When to Drop "()" in a Function Call
What are those objections (if you know) and is an alternative approach recommended?
Re: When to Drop "()" in a Function Call
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.
Re: When to Drop "()" in a Function Call
On 1 October 2011 13:58, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
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.
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...
Re: When to Drop "()" in a Function Call
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 [dot] lee [dot] wright [at] gmail [dot] com> wrote:
Re: When to Drop "()" in a Function Call
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 :)
Re: When to Drop "()" in a Function Call
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!
Re: When to Drop "()" in a Function Call
Ken
Re: When to Drop "()" in a Function Call
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/
>
>
Re: When to Drop "()" in a Function Call
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 [dot] suereth [at] gmail [dot] com> wrote:
Re: When to Drop "()" in a Function Call
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*.
Re: When to Drop "()" in a Function Call
On Saturday, October 1, 2011 6:51:43 PM UTC-5, Tony Morris wrote: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
Re: When to Drop "()" in a Function Call
On 2 October 2011 20:12, Ken McDonald <ykkenmcd [at] gmail [dot] com> wrote:
+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.
Re: When to Drop "()" in a Function Call
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.
Re: When to Drop "()" in a Function Call
On Sunday, October 2, 2011 4:29:21 PM UTC-5, Tony Morris wrote:I really resent being expected to mind-read. Just give up on this please. 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. 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
Re: When to Drop "()" in a Function Call
On 04/10/11 03:57, Ken McDonald wrote:
>
> 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 can stomp your foot all you like and claim that a registered
objection, without explanation, is devoid of value. That doesn't mean
it's true.
I cannot be expected to squash every bit of bullshit out there. You guys
come up with these things -- *you* explain why I should take it
seriously -- be mindful that you might be "overturning facts." I give
quasi-explanations the benefit of the doubt -- maybe you're having a bad
day -- but sometimes, if that's the most thought you're prepared to put
into it, you forfeit any right to demand effort from me.
Re: When to Drop "()" in a Function Call
When you can't take the effort to explain yourself and / or treat others with a basic degree of civility, then spend even less effort and refrain from posting at all.
-- Matt
Re: When to Drop "()" in a Function Call
On 04/10/11 07:26, Matt Russell wrote:
> On Monday, October 3, 2011 10:11:05 PM UTC+1, Tony Morris wrote:
>> Fuck...complete bullshit...stomp your foot...you've been put through some
> shitty university course...I will not pander to princesses...etc
>> ...you forfeit any right to demand effort from me.
> When you can't take the effort to explain yourself and / or treat others
> with a basic degree of civility, then spend even less effort and refrain
> from posting at all.
>
Re: When to Drop "()" in a Function Call
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.