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

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

Hi guys,

Hi Tim, 

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?

Stack Overflow is a better venue for these questions, it tends to be a bit less chatty. http://stackoverflow.com/tags/scala/info  

a) f and f() are not the same thing although they can both be used to
do the same thing in many situations.

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! 

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 

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.  

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.

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.  

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

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.  

e) lazy val could be a dangerously bad thing vs def in a mutable environment

Using a lazy val as a cache doesn't work if you ever need to invalidate that cache.  -jason

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.duponcheel@gmail.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

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.

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

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

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

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?

On 3 October 2011 21:57, Tony Morris <tmorris@tmorris.net> 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" <luc.duponcheel@gmail.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

That last bit should have read "...may NOT be substituted..."

On 3 October 2011 23:45, Kevin Wright <kev.lee.wright@gmail.com> 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?

On 3 October 2011 21:57, Tony Morris <tmorris@tmorris.net> 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" <luc.duponcheel@gmail.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

Thank you Jason for a really clear, constructive and instructive answer to a good question.
Matthew.

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.

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.



Luc


On Mon, Oct 3, 2011 at 10:57 PM, Tony Morris <tmorris@tmorris.net> 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" <luc.duponcheel@gmail.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

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

reality goes far beyond imagination

-------- Original-Nachricht --------
> Datum: Tue, 4 Oct 2011 11:39:43 +0200
> Von: Luc Duponcheel
> An: Tony Morris
> CC: Kevin Wright , scala-user@googlegroups.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
> >
>
>
>

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

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

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

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.

I think there are a lot of people (not necessarily in this discussion) who would disagree with this when f has side effects. foo.f is most naturally read as accessing a value in foo (even if that's not what's actually happening), foo.f() make clear that a method is being called. So regardless of what purists may argue, using () to indicate f has side effects is intuitive and probably pretty useful.

Ken

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.

PS: profanity doesn't exist.

That's no reason to use it.

Tony, those were a lot of words, and those similes were like the sky, but you haven't stated what the danger actually is.
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@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/

On Mon, Oct 10, 2011 at 8:47 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Tony, those were a lot of words, and those similes were like the sky, but you haven't stated what the danger actually is.
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?

Please don't drag this thread back up on scala-user. Private email or, failing that, scala-debate would be more suitable IMO.
-jason 

On Mon, Oct 10, 2011 at 8:21 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

PS: profanity doesn't exist.

That's no reason to use it.

If it doesn't exist, you cannot use it.
 


--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

2011/10/10 √iktor Ҡlang <viktor.klang@gmail.com>

On Mon, Oct 10, 2011 at 8:21 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

PS: profanity doesn't exist.

That's no reason to use it.

If it doesn't exist, you cannot use it.
 

And yet, he did. Thus we must conclude that it does exist!
 

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

2011/10/10 Naftoli Gugenheim <naftoligug@gmail.com>

2011/10/10 √iktor Ҡlang <viktor.klang@gmail.com>

On Mon, Oct 10, 2011 at 8:21 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

PS: profanity doesn't exist.

That's no reason to use it.

If it doesn't exist, you cannot use it.
 

And yet, he did. Thus we must conclude that it does exist!

Precisely my point.
 

 

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

Well then, we got ourselves one of them Greek paradoxes, eh?
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.klang@gmail.com> wrote:

2011/10/10 Naftoli Gugenheim < (naftoligug [at] gmail [dot] com>

2011/10/10 √iktor Ҡlang < (viktor [dot] klang [at] gmail [dot] com>

On Mon, Oct 10, 2011 at 8:21 AM, Naftoli Gugenheim < (naftoligug [at] gmail [dot] com> wrote:

PS: profanity doesn't exist.

That's no reason to use it.

If it doesn't exist, you cannot use it.
 

And yet, he did. Thus we must conclude that it does exist!

Precisely my point.
 

 

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang