+: is strange

On 21 June 2011 11:23, ngocdaothanh <ngocdaothanh@gmail.com> wrote:

Isn't this strange?

Array(1, 2) +: "hello"
=> scala.collection.immutable.IndexedSeq[Any] = Vector(Array(1, 2), h,
e, l, l, o)

Array(1, 2).+:("hello")
=> Array[Any] = Array(hello, 1, 2)

"hello" +: Array(1, 2)
=> Array[Any] = Array(hello, 1, 2)

"hello".+:(Array(1, 2))
=> scala.collection.immutable.IndexedSeq[Any] = Vector(Array(1, 2), h,
e, l, l, o)

No, it isn't.
Any method name ending with a : is right-associative, so a +: b is desugared as b.+:(a)
Combine that with the implict conversion from a String to a sequence of characters (which is the only way that +: becomes a valid operation on Strings), and everything makes sense.

--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.comkev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wrightquora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"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

Thank you.

It's a pitfall for one to think that it's cooler to write
a +: b
than to write
a.+:(b)

Because the results are not the same.

On 21 June 2011 11:40, ngocdaothanh <ngocdaothanh@gmail.com> wrote:

Thank you.

It's a pitfall for one to think that it's cooler to write
a +: b
than to write
a.+:(b)

Because the results are not the same.

It's also worth noting that these operations come in pairs, so a :+ b is the same as a.:+(b)
This gives a very nice symmetry. For example, imagine I wanted to smooth a sequence of Integers:
  val xs = Seq(3,9,6,1,2,1,8,3,5,7)
Easily enough done by using the sliding operation to take successive groups of 3 numbers, and then averaging them:
  def smooth(xs: Seq[Int]) = xs.sliding(3).map(_.sum/3).toSeq  //returns Seq(6, 5, 3, 1, 3, 4, 5, 5)
The problem is that this smoothed sequence is 2 elements shorter than the original. The solution is to first pad the original sequence at either end, in this case I'll use 0's:
  def smooth(xs: Seq[Int]) = (0 +: xs :+ 0).sliding(3).map(_.sum/3).toSeq   //returns Seq(4, 6, 5, 3, 1, 3, 4, 5, 5, 4)
Voila! 10 elements in, 10 elements out.  The natural symmetry here and the availability of right-associative operations are helping to make the code far cleaner and more readable.
--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.comkev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wrightquora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"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

It's a pitfall to start using a language without understanding some of the basic rules of that language! As Kevin says, methods ending in ':' are right-associative when used infix. Scala's language designers took this approach because it generates a lot of bang for its buck: that is, the readability gains more than offset any problems which arise to using it non-infix (which you will only ever do once, until you realize the mistake).
I agree that a 1-page "Read this first: some potentially suprising syntax" might be a useful addition to the scala documentation/tutorials
Chris

> Date: Tue, 21 Jun 2011 03:40:49 -0700
> Subject: [scala-user] Re: +: is strange
> From: ngocdaothanh@gmail.com
> To: scala-user@googlegroups.com
>
> Thank you.
>
> It's a pitfall for one to think that it's cooler to write
> a +: b
> than to write
> a.+:(b)
>
> Because the results are not the same.

Take it easy Chris.
Many people find these ASCII art method names as a weak feature of the language.
I agree that "ending with :" is part of the language design, maybe not
so basic, but you should read not just the basics to be able to read
code with <:<, >:<, ~~>, @@ and some UTF characters used as method
names.

I guess the reason to have such nicknames for
"methodsWithAMeaningfulName" is because the IDE support was weaker
before.
IDE with code completion makes it as easy to write the long name as
typing the short one without code completion.

On Tue, Jun 21, 2011 at 1:54 PM, Chris Marshall wrote:
> It's a pitfall to start using a language without understanding some of the
> basic rules of that language! As Kevin says, methods ending in ':' are
> right-associative when used infix. Scala's language designers took this
> approach because it generates a lot of bang for its buck: that is, the
> readability gains more than offset any problems which arise to using it
> non-infix (which you will only ever do once, until you realize the mistake).
> I agree that a 1-page "Read this first: some potentially suprising syntax"
> might be a useful addition to the scala documentation/tutorials
> Chris
>
>> Date: Tue, 21 Jun 2011 03:40:49 -0700
>> Subject: [scala-user] Re: +: is strange
>> From: ngocdaothanh@gmail.com
>> To: scala-user@googlegroups.com
>>
>> Thank you.
>>
>> It's a pitfall for one to think that it's cooler to write
>> a +: b
>> than to write
>> a.+:(b)
>>
>> Because the results are not the same.
>

Hi Grzegorz,

On Tue, Jun 21, 2011 at 3:13 PM, Grzegorz Kossakowski
wrote:
> On 21 June 2011 14:05, Martin Grigorov wrote:
>>
>> Take it easy Chris.
>> Many people find these ASCII art method names as a weak feature of the
>> language.
>> I agree that "ending with :" is part of the language design, maybe not
>> so basic, but you should read not just the basics to be able to read
>> code with <:<, >:<, ~~>, @@ and some UTF characters used as method
>> names.
This is what I said here.
>>
>> I guess the reason to have such nicknames for
>> "methodsWithAMeaningfulName" is because the IDE support was weaker
>> before.
>> IDE with code completion makes it as easy to write the long name as
>> typing the short one without code completion.
>
> Martin,
> It's about reading not writing. See Kevin's example.
> I care much more about reading than writing code. This is what most people
> do most of the time, actually.
> --
> Grzegorz Kossakowski
>
>
Do you want to say that reading a sequence of basic and not so basic
ASCII art method names is easier than reading method with normal human
language name ?
With the IDE support improvements I wanted to say that now (year 2011)
is not that cumbersome to write few characters more *once* and read it
as a human easily many times than trying to save some key strokes and
then few weeks/months later to try to extract from your memory WTF
%^&* means.
And this is even more important when you expect your future colleagues
to support your product with you. Or you'll have to give them time to
read the whole language spec before reading your code.

I don't want to say that using ASCII art method names is bad. The
language gives you the possibility to use them but it also gives the
you the right to decide whether to use them or not. I just wanted to
say that Chris was not right to say
"It's a pitfall to start using a language without understanding some
of the basic rules of that language!" and that many of my colleagues
(Java developers) say that they don't like Scala because of the ASCII
method names and compare them with Perl's oneliners which are cool to
see once but not to support in daily job.

On 21/06/2011 14:05, Martin Grigorov wrote:
> I guess the reason to have such nicknames for
> "methodsWithAMeaningfulName" is because the IDE support was weaker
> before.
> IDE with code completion makes it as easy to write the long name as
> typing the short one without code completion.

Although I like meaningful names in my code, I am starting to use short variable names in
small functions.
Although this can be (and have been) argued upon endlessly, some well chosen short names
can add to readability too.
Somehow, I prefer to see
"Foo" :: "Bar" :: "Baz" :: Nil
rather than
Nil.append("Baz").append("Bar").append("Foo")
and some of this notation can have intuitive meaning in some contexts (eg. matrix
operations and other mathematical contexts).

But I agree that it is easy to go overboard with Ascii art (and even more with UTF-8
art...) and some of it made me think Scala is more complex that it is really, the first
time I saw some Scala code.

On 21 June 2011 13:05, Martin Grigorov <martin.grigorov@gmail.com> wrote:

Take it easy Chris.
Many people find these ASCII art method names as a weak feature of the language.

and many more find them incredibly useful and obvious.I, for one, have absolutely no desire to go back to Java's way of dealing with BigDecimal addition

I agree that "ending with :" is part of the language design, maybe not
so basic, but you should read not just the basics to be able to read
code with <:<, >:<, ~~>, @@ and some UTF characters used as method
names.

This is FUD.<:< is complicated because it's working with the type system, not because it's named <:<>:< isn't used anywhere, to the best of my knowledge ~~> also isn't used anywhere (so far as I know).  You may be confusing it with ~>, in which case the challenge is not the method name, but leaning the parser library in general.@@ Again, isn't in the standard library (although we do have ## for hashCode - which isn't hard to understand)
Don't judge the language based on just a few libraries.  Dispatch doesn't define Scala, nor does Lift, or Scalaz 

I guess the reason to have such nicknames for
"methodsWithAMeaningfulName" is because the IDE support was weaker
before.
IDE with code completion makes it as easy to write the long name as
typing the short one without code completion.

This argument quickly breaks down.  Imagine if your IDE substituted every use of == with .equals() and + with .plus()
Even going back and reading a line you had just typed would become harder.  Code is read many, many more times than it's written, so "ease of typing" is about the worst possible thing you can optimise for.  Readability, on the other hand, is about the only metric in town for which optimisation can *never* be too premature.  

On Tue, Jun 21, 2011 at 1:54 PM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:
> It's a pitfall to start using a language without understanding some of the
> basic rules of that language! As Kevin says, methods ending in ':' are
> right-associative when used infix. Scala's language designers took this
> approach because it generates a lot of bang for its buck: that is, the
> readability gains more than offset any problems which arise to using it
> non-infix (which you will only ever do once, until you realize the mistake).
> I agree that a 1-page "Read this first: some potentially suprising syntax"
> might be a useful addition to the scala documentation/tutorials
> Chris
>
>> Date: Tue, 21 Jun 2011 03:40:49 -0700
>> Subject: [scala-user] Re: +: is strange
>> From: ngocdaothanh@gmail.com
>> To: scala-user@googlegroups.com
>>
>> Thank you.
>>
>> It's a pitfall for one to think that it's cooler to write
>> a +: b
>> than to write
>> a.+:(b)
>>
>> Because the results are not the same.
>

--
Kevin Wright

gtalk / msn : kev.lee.wright@gmail.comkev.lee.wright@gmail.commail: kevin.wright@scalatechnology.com
vibe / skype: kev.lee.wrightquora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

On Tue, Jun 21, 2011 at 09:05, Martin Grigorov
wrote:
> Take it easy Chris.
> Many people find these ASCII art method names as a weak feature of the language.
> I agree that "ending with :" is part of the language design, maybe not
> so basic, but you should read not just the basics to be able to read
> code with <:<, >:<, ~~>, @@ and some UTF characters used as method
> names.
>
> I guess the reason to have such nicknames for
> "methodsWithAMeaningfulName" is because the IDE support was weaker
> before.
> IDE with code completion makes it as easy to write the long name as
> typing the short one without code completion.

It doesn't make it easy to _read_ them, and it certainly does nothing
to put more relevant information in the field of view. Notation is
very important -- a lot of mathematical breakthroughs resulted from
improved notation. Hell, the fact that people nowadays are capable of
basic arithmetic rests in no small measure in the superior notation of
digits over other systems (eg, roman numerals).

And while people blithely proclaim that longer identifiers are better,
studies have not supported that. Sure, when you have never seen a
method previously, it is easier to gather what it does if its name is
a description of what it does, but every time afterwards it will just
be a burden -- you'll have to read the description to assert what
method is that, instead of quickly identifying it from the 3~5
characters the mind identifies at a time.

Anyway, to each its own, but I certainly find the first line above
immediately more informative than the second.

'<' +: "root" :+ '>'
"root".prepend('<').append('>')

>
> '<' +: "root" :+ '>'
> "root".prepend('<').append('>')
>

i think ceylon pushed that even further:
print("<" root ">")

you can omit the "+"

This argument quickly breaks down.  Imagine if your IDE substituted every use of == with .equals() and + with .plus()

It would be neat if the major IDEs could support infix desugaring and expanding symbols to the equivalent textual names. I quite like symbols but sometimes it would be nice to get a tooltip with the fully verbose version.
Matthe4w
--
Dr Matthew PocockVisitor, School of Computing Science, Newcastle Universitymailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozer(0191) 2566550

On Tue, Jun 21, 2011 at 10:48, Dennis Haupt wrote: > >> >> '<' +: "root" :+ '>' >> "root".prepend('<').append('>') >> > > i think ceylon pushed that even further: > print("<" root ">") > > you can omit the "+" Cool! And it does the same thing with 0 +: List(1, 2, 3, 4) :+ 5,
+:

paragraph

:+
, or, in fact, with any type I create on all collection types?

On Tue, Jun 21, 2011 at 10:47, Matthew Pocock
wrote:
>>
>> This argument quickly breaks down.  Imagine if your IDE substituted every
>> use of == with .equals() and + with .plus()
>
> It would be neat if the major IDEs could support infix desugaring and
> expanding symbols to the equivalent textual names. I quite like symbols but
> sometimes it would be nice to get a tooltip with the fully verbose version.
> Matthe4w

Showing the definition and doc for the method on the tool tip is
certainly a proper task for an IDE.

not sure where the limits are. ask here: http://www.ceylonproject.com/ -------- Original-Nachricht -------- > Datum: Tue, 21 Jun 2011 11:03:44 -0300 > Von: Daniel Sobral > An: Dennis Haupt > CC: martin.grigorov@gmail.com, scala-user@googlegroups.com, oxbow_lakes@hotmail.com > Betreff: Re: [scala-user] Re: +: is strange > On Tue, Jun 21, 2011 at 10:48, Dennis Haupt wrote: > > > >> > >> '<' +: "root" :+ '>' > >> "root".prepend('<').append('>') > >> > > > > i think ceylon pushed that even further: > > print("<" root ">") > > > > you can omit the "+" > > Cool! And it does the same thing with 0 +: List(1, 2, 3, 4) :+ 5, >
+:

paragraph

:+
, or, in fact, with any type I > create on all collection types? > >

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 21/06/11 20:56, Kevin Wright wrote:
> It's also worth noting that these operations come in pairs, so a :+
> b is the same as a.:+(b)
>
> This gives a very nice symmetry.

My favourite is adding a binary map on binary covariant functors:

f <-: either :-> g
f <-: tuple2 :-> g

e.g.

scala> val j = ("boobs" + _) <-: ("abc", 9) :-> (88+)
j: (java.lang.String, Int) = (boobsabc,97)

On Tuesday June 21 2011, Dennis Haupt wrote:
> not sure where the limits are.
> ask here: http://www.ceylonproject.com/
>
> ...

Ceylon? Someone misses the glory days of the British Empire!

As for asking there, the only links on that page are the "subscribe to
our manifesto^Wnewsletter" and "MediaLoot" (and I'm not sure I like the
connotation of "loot...").

RRS

Can Ceylon compiler yet?

On Tue, Jun 21, 2011 at 10:13 AM, Dennis Haupt <h-star@gmx.de> wrote:

not sure where the limits are.
ask here: http://www.ceylonproject.com/

-------- Original-Nachricht --------
> Datum: Tue, 21 Jun 2011 11:03:44 -0300
> Von: Daniel Sobral <dcsobral@gmail.com>
> An: Dennis Haupt <h-star@gmx.de>
> CC: martin.grigorov@gmail.com, scala-user@googlegroups.com, oxbow_lakes@hotmail.com
> Betreff: Re: [scala-user] Re: +: is strange

> On Tue, Jun 21, 2011 at 10:48, Dennis Haupt <h-star@gmx.de> wrote:
> >
> >>
> >> '<' +: "root" :+ '>'
> >> "root".prepend('<').append('>')
> >>
> >
> > i think ceylon pushed that even further:
> > print("<" root ">")
> >
> > you can omit the "+"
>
> Cool! And it does the same thing with 0 +: List(1, 2, 3, 4) :+ 5,
> <br/> +: <p>paragraph</p> :+ <br/>, or, in fact, with any type I
> create on all collection types?
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.

For eithers, that one helps:
implicit def throwable2Either[T >: Throwable](t: T) = new {  def <->[V](v: V): T Either V = {    Option(t).map(Left(_)).getOrElse(Right(v))   }}
var t = new Exceptiont <-> null
t = nullt <-> 3
On Tue, Jun 21, 2011 at 11:07 AM, Tony Morris <tonymorris@gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 21/06/11 20:56, Kevin Wright wrote:
> It's also worth noting that these operations come in pairs, so a :+
> b is the same as a.:+(b)
>
> This gives a very nice symmetry.

My favourite is adding a binary map on binary covariant functors:

f <-: either :-> g
f <-: tuple2 :-> g

e.g.

scala> val j = ("boobs" + _) <-: ("abc", 9) :-> (88+)
j: (java.lang.String, Int) = (boobsabc,97)


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4ApYQACgkQmnpgrYe6r61ePgCfTjMoDwG1Kcso6t/NhSXSWV2F
J+UAoKxxuVshRPyUYxsWl43wGJfhiO+d
=6KxE
-----END PGP SIGNATURE-----

--
Lucas B. Torri

not yet, afaik -------- Original-Nachricht -------- > Datum: Tue, 21 Jun 2011 10:28:33 -0400 > Von: Josh Suereth > An: Dennis Haupt > CC: Daniel Sobral , oxbow_lakes@hotmail.com, scala-user@googlegroups.com, martin.grigorov@gmail.com > Betreff: Re: [scala-user] Re: +: is strange > Can Ceylon compiler yet? > > On Tue, Jun 21, 2011 at 10:13 AM, Dennis Haupt wrote: > > > not sure where the limits are. > > ask here: http://www.ceylonproject.com/ > > > > -------- Original-Nachricht -------- > > > Datum: Tue, 21 Jun 2011 11:03:44 -0300 > > > Von: Daniel Sobral > > > An: Dennis Haupt > > > CC: martin.grigorov@gmail.com, scala-user@googlegroups.com, > > oxbow_lakes@hotmail.com > > > Betreff: Re: [scala-user] Re: +: is strange > > > > > On Tue, Jun 21, 2011 at 10:48, Dennis Haupt wrote: > > > > > > > >> > > > >> '<' +: "root" :+ '>' > > > >> "root".prepend('<').append('>') > > > >> > > > > > > > > i think ceylon pushed that even further: > > > > print("<" root ">") > > > > > > > > you can omit the "+" > > > > > > Cool! And it does the same thing with 0 +: List(1, 2, 3, 4) :+ 5, > > >
+:

paragraph

:+
, or, in fact, with any type I > > > create on all collection types? > > > > > > > > > -- > > > Daniel C. Sobral > > > > > > I travel to the future all the time. > >

בתאריך יום שלישי, 21 ביוני 2011 15:32:43 UTC+3, מאת martin-g:

Hi Grzegorz,

On Tue, Jun 21, 2011 at 3:13 PM, Grzegorz Kossakowski
<grzegorz.k...@gmail.com> wrote:
> On 21 June 2011 14:05, Martin Grigorov <martin....@gmail.com> wrote:
>>
>> Take it easy Chris.
>> Many people find these ASCII art method names as a weak feature of the
>> language.
>> I agree that "ending with :" is part of the language design, maybe not
>> so basic, but you should read not just the basics to be able to read
>> code with <:<, >:<, ~~>, @@ and some UTF characters used as method
>> names.
This is what I said here.
>>
>> I guess the reason to have such nicknames for
>> "methodsWithAMeaningfulName" is because the IDE support was weaker
>> before.
>> IDE with code completion makes it as easy to write the long name as
>> typing the short one without code completion.
>
> Martin,
> It's about reading not writing. See Kevin's example.
> I care much more about reading than writing code. This is what most people
> do most of the time, actually.
> --
> Grzegorz Kossakowski
>
>
Do you want to say that reading a sequence of basic and not so basic
ASCII art method names is easier than reading method with normal human
language name ?
With the IDE support improvements I wanted to say that now (year 2011)
is not that cumbersome to write few characters more *once* and read it
as a human easily many times than trying to save some key strokes and
then few weeks/months later to try to extract from your memory WTF
%^&* means.

(Late to the party, hope I'm not repeating points that were already made)

It depends on how much you use those operators. Imagine that this code:
if (salary > 100) {
  bonus = 100
}

would instead be written without operators:
if (salary.isLargerThan(100)) then
  bonus isSetTo 100
end

Which one is more readable?

All operators that we're used to were invented some time. The equal sign (=) was invented in 1557: http://en.wikipedia.org/wiki/Equals_sign

Ittay
 

And this is even more important when you expect your future colleagues
to support your product with you. Or you'll have to give them time to
read the whole language spec before reading your code.

I don't want to say that using ASCII art method names is bad. The
language gives you the possibility to use them but it also gives the
you the right to decide whether to use them or not. I just wanted to
say that Chris was not right to say
"It's a pitfall to start using a language without understanding some
of the basic rules of that language!" and that many of my colleagues
(Java developers) say that they don't like Scala because of the ASCII
method names and compare them with Perl's oneliners which are cool to
see once but not to support in daily job.

On Tue, Jun 21, 2011 at 9:56 AM, Ittay Dror <ittay.dror@gmail.com> wrote:

It depends on how much you use those operators. Imagine that this code:
if (salary > 100) {
  bonus = 100
}

would instead be written without operators:
if (salary.isLargerThan(100)) then
  bonus isSetTo 100
end

Which one is more readable?

How readable is this?

如果工资大于100则奖金设置为100

It all has to do with familiarity. Personally, I get cognitive overload from all the symbol names in the collections library. For basic mathematical operators I don't. Probably because they are applicable in many other contexts, plus I learned them as a kid, which always helps :-)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/06/11 00:56, Ittay Dror wrote:
>
> (Late to the party, hope I'm not repeating points that were already
> made)
>
> It depends on how much you use those operators. Imagine that this
> code: if (salary > 100) { bonus = 100 }
>
> would instead be written without operators: if
> (salary.isLargerThan(100)) then bonus isSetTo 100 end
>
> Which one is more readable?
>

FTFY

if start salary invoke isLargerThan start one hundred finish finish then
bonus isSetTo one hundred
end

By the way, the entire discussion about naming identifiers is a
distraction from the important stuff -- don't get sucked in too far.

Am 22.06.2011 00:12, schrieb Tony Morris:
>

On 22/06/11 00:56, Ittay Dror wrote:

> (Late to the party, hope I'm not repeating points that were already
> made)

> It depends on how much you use those operators. Imagine that this
> code: if (salary > 100) { bonus = 100 }

> would instead be written without operators: if
> (salary.isLargerThan(100)) then bonus isSetTo 100 end

> Which one is more readable?


FTFY

if start salary invoke isLargerThan start one hundred finish finish then
  bonus isSetTo one hundred
end

i can make that worse:
call(write("100") to ("bonus")) under condition (equals(compare("salary") to ("100"),"firstIsBigger"))

personally, this is my favorite:
salary > 100 ? {bonus =  100}

? is stolen from java and its second parameter is optional. i pimped my lib.

By the way, the entire discussion about naming identifiers is a
distraction from the important stuff -- don't get sucked in too far.

1024x768 21 false false false DE X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Normale Tabelle"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-hansi-font-family:Calibri; mso-bidi-font-family:"Times New Roman"; mso-fareast-language:EN-US;}

[Nils Kilden-Pedersen]

> It all has to do with familiarity. Personally, I get cognitive overload

> from all the symbol names in the collections library. For basic

> mathematical operators I don't. Probably because they are applicable in

> many other contexts, plus I learned them as a kid, which always helps

> :-)

 

Well, "kid", ≠, ∩, ℮, √, ∞, ∆,∑, log,∫

put that in order of the age when you learned it.

Or better: Take http://en.wikipedia.org/wiki/List_of_mathematical_symbols

and sort them this way.

Honestly, many of them I have never seen in my life.

But I know, if I ever will get in contact with the

topic where they have been invented for, I will have to

learn them.

I.e: Learning the language of the domain we enter will

never stop.

 

Same is true in programming languages. I have to learn

their paradigms, I have to learn their syntax, and yes,

sometimes their symbols which *may* express the paradigms

much better than text.

 

The thing is, that some symbols are kind of pictograms

and immediately produce a recognisable meaning

(see the balance of = and the imbalance of < and > ),

others are not. And the more of the latter you have,

the more difficult things are.

 

The thing is, that some people now blame Scala for

the typical habit of mathematicians to introduce symbols

for whatever.

But they normally don't do it just for fun.

Did anyone stand up and shout when the BNF was introduced to

describe grammars? Did anyone say: Let’s stay with textual

descriptions?

 

I at least got a better tool for thinking with the

<: and >: operator than with Java’s extends and super

constructs, which as keywords are even ambiguously defined.

The same expressiveness is true for parser combinators

(“BNF in Scala”).

 

[Tony Morris]

> By the way, the entire discussion about naming identifiers is a

> distraction from the important stuff -- don't get sucked in too far.

 

Right. But OTOH it may be interesting from a psychological

perspective (and thus for language designers).

It is interesting for me to see, how much my daily job with

its influences and different people has blurred the fact

that programming is much better done with mathematical

approach in mind than with the paradigm that we are working

in a virtual construction industry (much too often management view,

sometimes driven by the too easily adopted notion of “object” oriented

programming and “component”s and “module”s).

Learning more and more of FP by turning to Scala healed that for me.

 

Now no more about this topic from me.

 

KR

Det

 

On Tue, Jun 21, 2011 at 6:12 PM, Tony Morris <tonymorris@gmail.com> wrote:

By the way, the entire discussion about naming identifiers is a
distraction from the important stuff -- don't get sucked in too far.

What is important about the important stuff? Is it important in an absolute sense or relative to something else? In an objective sense or to you? And, what is importance?

boobs. lol

> Date: Wed, 22 Jun 2011 00:07:00 +1000
> From: tonymorris@gmail.com
> To: scala-user@googlegroups.com
> Subject: Re: [scala-user] Re: +: is strange
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 21/06/11 20:56, Kevin Wright wrote:
> > It's also worth noting that these operations come in pairs, so a :+
> > b is the same as a.:+(b)
> >
> > This gives a very nice symmetry.
>
> My favourite is adding a binary map on binary covariant functors:
>
> f <-: either :-> g
> f <-: tuple2 :-> g
>
> e.g.
>
> scala> val j = ("boobs" + _) <-: ("abc", 9) :-> (88+)
> j: (java.lang.String, Int) = (boobsabc,97)
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4ApYQACgkQmnpgrYe6r61ePgCfTjMoDwG1Kcso6t/NhSXSWV2F
> J+UAoKxxuVshRPyUYxsWl43wGJfhiO+d
> =6KxE
> -----END PGP SIGNATURE-----
>

On 22 June 2011 08:39, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

boobs. lol

It's not a laughing matter, and could well be an early warning sign of addiction...Cheesing is no joke, and South Park certainly highlighted the risks enough for *this* concerned citizen!

 

> Date: Wed, 22 Jun 2011 00:07:00 +1000
> From: tonymorris@gmail.com
> To: scala-user@googlegroups.com
> Subject: Re: [scala-user] Re: +: is strange
>
>
> On 21/06/11 20:56, Kevin Wright wrote:
> > It's also worth noting that these operations come in pairs, so a :+
> > b is the same as a.:+(b)
> >
> > This gives a very nice symmetry.
>
> My favourite is adding a binary map on binary covariant functors:
>
> f <-: either :-> g
> f <-: tuple2 :-> g
>
> e.g.
>
> scala> val j = ("boobs" + _) <-: ("abc", 9) :-> (88+)
> j: (java.lang.String, Int) = (boobsabc,97)
>
> 

On Wednesday 22 June 2011, Naftoli Gugenheim wrote:
> On Tue, Jun 21, 2011 at 6:12 PM, Tony Morris
wrote:
> > By the way, the entire discussion about naming identifiers is a
> > distraction from the important stuff -- don't get sucked in too
> > far.
>
> What is important about the important stuff? Is it important in an
> absolute sense or relative to something else? In an objective sense
> or to you? And, what is importance?

"... important in an absolute sense ..."

Really? I feel quite certain that importance is entirely subjective and
hence also relative.

Randall Schulz

Exactly, that was precisely my point.

On Wed, Jun 22, 2011 at 9:01 AM, Randall R Schulz <rschulz@sonic.net> wrote:

On Wednesday 22 June 2011, Naftoli Gugenheim wrote:
> On Tue, Jun 21, 2011 at 6:12 PM, Tony Morris <tonymorris@gmail.com>
wrote:
> > By the way, the entire discussion about naming identifiers is a
> > distraction from the important stuff -- don't get sucked in too
> > far.
>
> What is important about the important stuff? Is it important in an
> absolute sense or relative to something else? In an objective sense
> or to you? And, what is importance?

"... important in an absolute sense ..."

Really? I feel quite certain that importance is entirely subjective and
hence also relative.


Randall Schulz

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You're right that the behavior described by the OP is perfectly in line
with Scala's associativity rules. But it's also strange and confusing
to newcomers. I'm not saying one shouldn't RTFM, but it seems desirable
for new users to encounter as few WTF moments as possible.

I don't doubt that the current associativity rules provide some bang for
the buck - I've been impressed that (almost?) everything in Scala is the
result of thoughtful consideration of tradeoffs - but a FAQ entry on
this issue seems like the very least one could do for merely mortal
developers like me.

Of course, such a FAQ entry would give ammo to those who say Scala is
too complicated, but in that regard it's probably no worse than this
thread (and the others like it that undoubtedly exist in the mailing
list archives).

On 06/21/2011 06:27 AM, Kevin Wright wrote:
>
>
> On 21 June 2011 11:23, ngocdaothanh > wrote:
>
> Isn't this strange?
>
> Array(1, 2) +: "hello"
> => scala.collection.immutable.IndexedSeq[Any] = Vector(Array(1, 2), h,
> e, l, l, o)
>
> Array(1, 2).+:("hello")
> => Array[Any] = Array(hello, 1, 2)
>
> "hello" +: Array(1, 2)
> => Array[Any] = Array(hello, 1, 2)
>
> "hello".+:(Array(1, 2))
> => scala.collection.immutable.IndexedSeq[Any] = Vector(Array(1, 2), h,
> e, l, l, o)
>
>
>
> No, it isn't.
>
> Any method name ending with a : is right-associative, so a +: b is
> desugared as b.+:(a)
>
> Combine that with the implict conversion from a String to a sequence of
> characters (which is the only way that +: becomes a valid operation on
> Strings), and everything makes sense.
>
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I see no reason to give a crap about people who think that "Scala is
too complicated", which we all know really means, "I don't get
understand programming in general and I refuse to change this." I see
reason to be proactively dismissive of such claims.

This poor newcomer hasn't yet it had it pointed out that calling +: is
a bad idea, regardless of its name. This makes me sad -- I wish we
weren't so obsessed with such an unimportant agenda as identifier
names, simply because it is easier. HTFU.

On 23/06/11 06:39, Clint Gilbert wrote:
> You're right that the behavior described by the OP is perfectly in
> line with Scala's associativity rules. But it's also strange and
> confusing to newcomers. I'm not saying one shouldn't RTFM, but it
> seems desirable for new users to encounter as few WTF moments as
> possible.
>
> I don't doubt that the current associativity rules provide some
> bang for the buck - I've been impressed that (almost?) everything
> in Scala is the result of thoughtful consideration of tradeoffs -
> but a FAQ entry on this issue seems like the very least one could
> do for merely mortal developers like me.
>
> Of course, such a FAQ entry would give ammo to those who say Scala
> is too complicated, but in that regard it's probably no worse than
> this thread (and the others like it that undoubtedly exist in the
> mailing list archives).
>
> On 06/21/2011 06:27 AM, Kevin Wright wrote:
>
>
>> On 21 June 2011 11:23, ngocdaothanh <ngocdaothanh@gmail.com
>> > wrote:
>
>> Isn't this strange?
>
>> Array(1, 2) +: "hello" =>
>> scala.collection.immutable.IndexedSeq[Any] =
> Vector(Array(1, 2), h,
>> e, l, l, o)
>
>> Array(1, 2).+:("hello") => Array[Any] = Array(hello, 1, 2)
>
>> "hello" +: Array(1, 2) => Array[Any] = Array(hello, 1, 2)
>
>> "hello".+:(Array(1, 2)) =>
>> scala.collection.immutable.IndexedSeq[Any] =
> Vector(Array(1, 2), h,
>> e, l, l, o)
>
>
>
>> No, it isn't.
>
>> Any method name ending with a : is right-associative, so a +: b
>> is desugared as b.+:(a)
>
>> Combine that with the implict conversion from a String to a
> sequence of
>> characters (which is the only way that +: becomes a valid
>> operation on Strings), and everything makes sense.
>
>
>> -- Kevin Wright
>
>> gtalk / msn : kev.lee.wright@gmail.com
>
>> mail:
> kevin.wright@scalatechnology.com
>> vibe / skype:
>> kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter:
>> @thecoda
>
>> "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
>
>

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4CanQACgkQmnpgrYe6r63nZgCgh51OjgGOp9pj9PH/xJfMBSnl
5uUAnic0FfbaZHFXfpa4NQDfPjAnrJVj
=Agrw
-----END PGP SIGNATURE-----

HI Tony,

I see no reason to give a crap about people who think that "Scala is
too complicated", which we all know really means, "I don't get
understand programming in general and I refuse to change this."

I'm sure this is the case for some people, but not for all.You can't (and shouldn't even try to) please all people, but correctly-pitched documentation (user-oriented, getting-started, faq, tutorials, ...) would make scala accessible to more people. Who knows? They may even start to understand programming in general.  

This poor newcomer hasn't yet it had it pointed out that calling +: is
a bad idea, regardless of its name.

Depends on the collection, doesn't it. It's bad for List. It should be almost free on a persistent vector. @complexity, anyone?
Matthew
--
Dr Matthew PocockVisitor, School of Computing Science, Newcastle Universitymailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozer(0191) 2566550

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/06/11 20:23, Matthew Pocock wrote:
> HI Tony,
>
>
>> I see no reason to give a crap about people who think that "Scala
>> is too complicated", which we all know really means, "I don't
>> get understand programming in general and I refuse to change
>> this."
>>
>
> I'm sure this is the case for some people, but not for all.You
> can't (and shouldn't even try to) please all people, but
> correctly-pitched documentation (user-oriented, getting-started,
> faq, tutorials, ...) would make scala accessible to more people.
> Who knows? They may even start to understand programming in
> general.

It is my experience, and that of others who are serious about learning
and teaching, that appeasement of this kind of silliness is directly
detrimental to the objective of coming to learn. However, I yearn for
more robust data than such anecdotes, despite their universality.

>
>
>> This poor newcomer hasn't yet it had it pointed out that calling
>> +: is a bad idea, regardless of its name.
>>
>
> Depends on the collection, doesn't it. It's bad for List. It should
> be almost free on a persistent vector. @complexity, anyone?

Yes. I assumed List, perhaps hastily.

>
> Matthew
>

On 23 June 2011 11:47, Tony Morris <tonymorris@gmail.com> wrote:

> > I'm sure this is the case for some people, but not for all.You
> can't (and shouldn't even try to) please all people, but
> correctly-pitched documentation (user-oriented, getting-started,
> faq, tutorials, ...) would make scala accessible to more people.
> Who knows? They may even start to understand programming in
> general.


It is my experience, and that of others who are serious about learning
and teaching, that appeasement of this kind of silliness is directly
detrimental to the objective of coming to learn. However, I yearn for
more robust data than such anecdotes, despite their universality.

My experience with BioJava was that the things you call "appeasement" but which I call "appropriate and targeted documentation" is massively useful in attracting new users and avoiding gumming up the mailing list with noob questions and gripes based upon misinformation.
http://www.slideshare.net/rbowen/write-a-better-fm
Matthew --
Dr Matthew PocockVisitor, School of Computing Science, Newcastle Universitymailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozer(0191) 2566550

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/06/11 21:24, Matthew Pocock wrote:
> On 23 June 2011 11:47, Tony Morris wrote:
>
>>>
>>> I'm sure this is the case for some people, but not for all.You
>>> can't (and shouldn't even try to) please all people, but
>>> correctly-pitched documentation (user-oriented,
>>> getting-started, faq, tutorials, ...) would make scala
>>> accessible to more people. Who knows? They may even start to
>>> understand programming in general.
>>
>>
>> It is my experience, and that of others who are serious about
>> learning and teaching, that appeasement of this kind of silliness
>> is directly detrimental to the objective of coming to learn.
>> However, I yearn for more robust data than such anecdotes,
>> despite their universality.
>
>
> My experience with BioJava was that the things you call
> "appeasement" but which I call "appropriate and targeted
> documentation" is massively useful in attracting new users and
> avoiding gumming up the mailing list with noob questions and gripes
> based upon misinformation.
>
> http://www.slideshare.net/rbowen/write-a-better-fm
>
> Matthew
>
I was referring to the kind of appeasement in the original discussion.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Martin, hi List,

> With the IDE support improvements I wanted to say that now (year 2011)
> is not that cumbersome to write few characters more *once* and read it
> as a human easily many times than trying to save some key strokes and
> then few weeks/months later to try to extract from your memory WTF
> %^&* means.

Well - did you notice, that Java, C, C++, C#, ... allow methodnames like
'Ouuua', 'Fzrrtzsltzzflz' and 'LliIi1iIiiI1l'?

Isn't it a horror? Think about abuse possibilities! Endless!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes I wrote BKTree and I appreciate your sincerity, but this list is
not the place to have these discussions. Perhaps elsewhere. I assure
you, I understand your concerns perfectly well.

On 23/06/11 21:40, Martin Grigorov wrote:
> Hi Tony,
>
> I'm not sure whether you understood my concerns in my previous
> mails. I understand what is the purpose of trailing colon in the
> method name. It is documented well. My problem is with using hard
> to read and remember member names (ASCII/UTF art), not with
> standard comparison operators like your example or with method
> names which use names from the specific domain (like maths).
>
> For example: what is the reason to choose method name like '-?-'
> in
> https://github.com/scalaz/scalaz/blob/master/core/src/main/scala/scalaz/BKTree.scala#L42
>
>
?
> This class has no much documentation. It has a link to Haskell
> implementation where there are no fancy names like -?-, =?=, or
> |=|. So it seems the author of BKTree.scala chose these names.
> Probably the author(s) of Haskell's impl are not that smart to
> choose these "better" names. I don't know and since there is no
> scaladoc I cannot know unless I ask in the mailing lists.
>
> Excuse me if you are not the author of BKTree.scala but even in
> this case I guess you will know the answer why these names are
> preferred and not documented. Because reading
> http://scalaz.github.com/scalaz/scalaz-2.9.0-1-6.0.1/doc/index.html#scalaz.BKTree
>
>
I cannot understand when to use these methods. I have to read the
> source to understand what -?- does. And if I have to read the full
> source for each function/class of your library to be able to use
> it then I'd say "no. thank you" even if you are too smart.
>
>
> On Thu, Jun 23, 2011 at 1:47 PM, Tony Morris
> wrote:
>>
> On 23/06/11 20:23, Matthew Pocock wrote:
>>>> HI Tony,
>>>>
>>>>
>>>>> I see no reason to give a crap about people who think that
>>>>> "Scala is too complicated", which we all know really means,
>>>>> "I don't get understand programming in general and I refuse
>>>>> to change this."
>>>>>
>>>>
>>>> I'm sure this is the case for some people, but not for
>>>> all.You can't (and shouldn't even try to) please all people,
>>>> but correctly-pitched documentation (user-oriented,
>>>> getting-started, faq, tutorials, ...) would make scala
>>>> accessible to more people. Who knows? They may even start to
>>>> understand programming in general.
>
>
> It is my experience, and that of others who are serious about
> learning and teaching, that appeasement of this kind of silliness
> is directly detrimental to the objective of coming to learn.
> However, I yearn for more robust data than such anecdotes, despite
> their universality.
>
>>>>
>>>>
>>>>> This poor newcomer hasn't yet it had it pointed out that
>>>>> calling +: is a bad idea, regardless of its name.
>>>>>
>>>>
>>>> Depends on the collection, doesn't it. It's bad for List. It
>>>> should be almost free on a persistent vector. @complexity,
>>>> anyone?
>
> Yes. I assumed List, perhaps hastily.
>
>>>>
>>>> Matthew
>>>>
>
>
>>
>>

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4DJsEACgkQmnpgrYe6r61bXgCgyJ6Qi9wC1zkLXhNYycAwvxsl
+oAAoMo8U0eQhiBxnyL92vMptQjZd+sx
=TEpg
-----END PGP SIGNATURE-----

Hi Tony,

I'm not sure whether you understood my concerns in my previous mails.
I understand what is the purpose of trailing colon in the method name.
It is documented well.
My problem is with using hard to read and remember member names
(ASCII/UTF art), not with standard comparison operators like your
example or with method names which use names from the specific domain
(like maths).

For example: what is the reason to choose method name like '-?-' in
https://github.com/scalaz/scalaz/blob/master/core/src/main/scala/scalaz/...
?
This class has no much documentation. It has a link to Haskell
implementation where there are no fancy names like -?-, =?=, or |=|.
So it seems the author of BKTree.scala chose these names.
Probably the author(s) of Haskell's impl are not that smart to choose
these "better" names. I don't know and since there is no scaladoc I
cannot know unless I ask in the mailing lists.

Excuse me if you are not the author of BKTree.scala but even in this
case I guess you will know the answer why these names are preferred
and not documented. Because reading
http://scalaz.github.com/scalaz/scalaz-2.9.0-1-6.0.1/doc/index.html#scal...
I cannot understand when to use these methods. I have to read the
source to understand what -?- does. And if I have to read the full
source for each function/class of your library to be able to use it
then I'd say "no. thank you" even if you are too smart.

On Thu, Jun 23, 2011 at 1:47 PM, Tony Morris wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 23/06/11 20:23, Matthew Pocock wrote:
>> HI Tony,
>>
>>
>>> I see no reason to give a crap about people who think that "Scala
>>> is too complicated", which we all know really means, "I don't
>>> get understand programming in general and I refuse to change
>>> this."
>>>
>>
>> I'm sure this is the case for some people, but not for all.You
>> can't (and shouldn't even try to) please all people, but
>> correctly-pitched documentation (user-oriented, getting-started,
>> faq, tutorials, ...) would make scala accessible to more people.
>> Who knows? They may even start to understand programming in
>> general.
>
>
> It is my experience, and that of others who are serious about learning
> and teaching, that appeasement of this kind of silliness is directly
> detrimental to the objective of coming to learn. However, I yearn for
> more robust data than such anecdotes, despite their universality.
>
>>
>>
>>> This poor newcomer hasn't yet it had it pointed out that calling
>>> +: is a bad idea, regardless of its name.
>>>
>>
>> Depends on the collection, doesn't it. It's bad for List. It should
>> be almost free on a persistent vector. @complexity, anyone?
>
> Yes. I assumed List, perhaps hastily.
>
>>
>> Matthew
>>
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4DGcoACgkQmnpgrYe6r60GogCfd1eGp224JbbEjhQmD+tj97Eb
> WSwAnRbUGrFYqGnb4+coFI1OSbHR3x6/
> =GrVS
> -----END PGP SIGNATURE-----
>
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 22.06.2011 06:20, schrieb HamsterofDeath:

> personally, this is my favorite:
> salary > 100 ? {bonus = 100}
>
> ? is stolen from java and its second parameter is optional. i pimped my lib.

With an implicit conversion from Bool to Int, like in C, you can use:

bonus = 100 * (salary > 100)

scala> implicit def Boolean2Int (b: Boolean) : Int = if (b) 1 else 0
Boolean2Int: (b: Boolean)Int

scala> val bonus = 100 * (salary > 100)
bonus: Int = 0

scala> val bonus = 100 * (salary > 10)
bonus: Int = 100

If you're used to the conversion boolean-Int, and used this method 2 or
3 times, it is really easy, while a bit surprising for a beginner.

Hi Stefan,

I hope the message I just sent makes me more clear what I mean.

On Thu, Jun 23, 2011 at 2:40 PM, Stefan Wagner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Martin, hi List,
>
>> With the IDE support improvements I wanted to say that now (year 2011)
>> is not that cumbersome to write few characters more *once* and read it
>> as a human easily many times than trying to save some key strokes and
>> then few weeks/months later to try to extract from your memory WTF
>> %^&* means.
>
> Well - did you notice, that Java, C, C++, C#, ... allow methodnames like
> 'Ouuua', 'Fzrrtzsltzzflz' and 'LliIi1iIiiI1l'?
Yes, you can.
But how many times you have seen such names in practice ?
Can you point me to such name in any GitHub project ?

>
> Isn't it a horror? Think about abuse possibilities! Endless!
>
> - --
>
> Tschööö--->...Stefan
> - ---------------------------
> Don't visit my homepage at:
> http://home.arcor-online.net/hirnstrom
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4DJhQACgkQQeATqGpDnRptXACgkj97MHbvc38fzkGg0RrTjKW/
> RAwAn04YJ98xkoHwPMcB2xfcTYNVW0zZ
> =HKWm
> -----END PGP SIGNATURE-----
>

despite the fact that this is now more of a flame thread (in my opinion), i've actually learned more than i expected about :+ :))
regards, jiri

On Thu, Jun 23, 2011 at 1:44 PM, Martin Grigorov <martin.grigorov@gmail.com> wrote:

Hi Stefan,

I hope the message I just sent makes me more clear what I mean.

On Thu, Jun 23, 2011 at 2:40 PM, Stefan Wagner <hirnstrom@arcor.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Martin, hi List,
>
>> With the IDE support improvements I wanted to say that now (year 2011)
>> is not that cumbersome to write few characters more *once* and read it
>> as a human easily many times than trying to save some key strokes and
>> then few weeks/months later to try to extract from your memory WTF
>> %^&* means.
>
> Well - did you notice, that Java, C, C++, C#, ... allow methodnames like
> 'Ouuua', 'Fzrrtzsltzzflz' and 'LliIi1iIiiI1l'?
Yes, you can.
But how many times you have seen such names in practice ?
Can you point me to such name in any GitHub project ?

>
> Isn't it a horror? Think about abuse possibilities! Endless!
>
> - --
>
> Tschööö--->...Stefan
> - ---------------------------
> Don't visit my homepage at:
> http://home.arcor-online.net/hirnstrom
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4DJhQACgkQQeATqGpDnRptXACgkj97MHbvc38fzkGg0RrTjKW/
> RAwAn04YJ98xkoHwPMcB2xfcTYNVW0zZ
> =HKWm
> -----END PGP SIGNATURE-----
>

--
web: http://www.dredwerkz.czblog: http://dr3dwerkz.blogspot.com/
code: https://github.com/g0dd4rd
group: http://groups.google.com/group/dr3dwerkz
music: http://profile.ultimate-guitar.com/g0dd4rd/
twitter: http://twitter.com/#!/g0dd4rd
profile: http://www.google.com/profiles/g0dd4rd
icq: 218 659 431

On Thu, Jun 23, 2011 at 08:47:38PM +1000, Tony Morris wrote:
> Yes. I assumed List, perhaps hastily.

It was Array in the original question. Which doesn't make it better.

- Florian.

We will point you to poorly named Java methods, if you can find something called  "%^&*" in  a Scala library.

> From: martin.grigorov@gmail.com
>> But how many times you have seen such names in practice ?
> Can you point me to such name in any GitHub project ?

If you look at the function declaration it is pretty clear what each
of these does. Just follow the types. If you do there is only a
single implementation for each function that makes any sense.

On Thu, Jun 23, 2011 at 4:42 AM, Martin Grigorov
wrote:
> Hi Tony,
>
> I'm not sure whether you understood my concerns in my previous mails.
> I understand what is the purpose of trailing colon in the method name.
> It is documented well.
> My problem is with using hard to read and remember member names
> (ASCII/UTF art), not with standard comparison operators like your
> example or with method names which use names from the specific domain
> (like maths).
>
> For example: what is the reason to choose method name like '-?-' in
> https://github.com/scalaz/scalaz/blob/master/core/src/main/scala/scalaz/...
> ?
> This class has no much documentation. It has a link to Haskell
> implementation where there are no fancy names like -?-, =?=, or |=|.
> So it seems the author of BKTree.scala chose these names.
> Probably the author(s) of Haskell's impl are not that smart to choose
> these "better" names. I don't know and since there is no scaladoc I
> cannot know unless I ask in the mailing lists.
>
> Excuse me if you are not the author of BKTree.scala but even in this
> case I guess you will know the answer why these names are preferred
> and not documented. Because reading
> http://scalaz.github.com/scalaz/scalaz-2.9.0-1-6.0.1/doc/index.html#scal...
> I cannot understand when to use these methods. I have to read the
> source to understand what -?- does. And if I have to read the full
> source for each function/class of your library to be able to use it
> then I'd say "no. thank you" even if you are too smart.
>
> On Thu, Jun 23, 2011 at 1:47 PM, Tony Morris wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 23/06/11 20:23, Matthew Pocock wrote:
>>> HI Tony,
>>>
>>>
>>>> I see no reason to give a crap about people who think that "Scala
>>>> is too complicated", which we all know really means, "I don't
>>>> get understand programming in general and I refuse to change
>>>> this."
>>>>
>>>
>>> I'm sure this is the case for some people, but not for all.You
>>> can't (and shouldn't even try to) please all people, but
>>> correctly-pitched documentation (user-oriented, getting-started,
>>> faq, tutorials, ...) would make scala accessible to more people.
>>> Who knows? They may even start to understand programming in
>>> general.
>>
>>
>> It is my experience, and that of others who are serious about learning
>> and teaching, that appeasement of this kind of silliness is directly
>> detrimental to the objective of coming to learn. However, I yearn for
>> more robust data than such anecdotes, despite their universality.
>>
>>>
>>>
>>>> This poor newcomer hasn't yet it had it pointed out that calling
>>>> +: is a bad idea, regardless of its name.
>>>>
>>>
>>> Depends on the collection, doesn't it. It's bad for List. It should
>>> be almost free on a persistent vector. @complexity, anyone?
>>
>> Yes. I assumed List, perhaps hastily.
>>
>>>
>>> Matthew
>>>
>>
>>
>> - --
>> Tony Morris
>> http://tmorris.net/
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk4DGcoACgkQmnpgrYe6r60GogCfd1eGp224JbbEjhQmD+tj97Eb
>> WSwAnRbUGrFYqGnb4+coFI1OSbHR3x6/
>> =GrVS
>> -----END PGP SIGNATURE-----
>>
>>
>

Hi,

I'm starting to regret now that I expressed the negative feedback I
heart several times and I also support with you (the community).
I also received few personal directed mails which I find as a bad manner.

@Chris: https://github.com/scalaz/scalaz/blob/master/core/src/main/scala/scalaz/...
Pick your favorite method name.

@Richard: True, but I still find documentation useful.

@Tony: Thank you!

I will not participate any longer in this particular discussion. Just
ignore the feedback.

On Thu, Jun 23, 2011 at 10:59 PM, Richard Wallace
wrote:
> If you look at the function declaration it is pretty clear what each
> of these does.  Just follow the types.  If you do there is only a
> single implementation for each function that makes any sense.
>
> On Thu, Jun 23, 2011 at 4:42 AM, Martin Grigorov
> wrote:
>> Hi Tony,
>>
>> I'm not sure whether you understood my concerns in my previous mails.
>> I understand what is the purpose of trailing colon in the method name.
>> It is documented well.
>> My problem is with using hard to read and remember member names
>> (ASCII/UTF art), not with standard comparison operators like your
>> example or with method names which use names from the specific domain
>> (like maths).
>>
>> For example: what is the reason to choose method name like '-?-' in
>> https://github.com/scalaz/scalaz/blob/master/core/src/main/scala/scalaz/...
>> ?
>> This class has no much documentation. It has a link to Haskell
>> implementation where there are no fancy names like -?-, =?=, or |=|.
>> So it seems the author of BKTree.scala chose these names.
>> Probably the author(s) of Haskell's impl are not that smart to choose
>> these "better" names. I don't know and since there is no scaladoc I
>> cannot know unless I ask in the mailing lists.
>>
>> Excuse me if you are not the author of BKTree.scala but even in this
>> case I guess you will know the answer why these names are preferred
>> and not documented. Because reading
>> http://scalaz.github.com/scalaz/scalaz-2.9.0-1-6.0.1/doc/index.html#scal...
>> I cannot understand when to use these methods. I have to read the
>> source to understand what -?- does. And if I have to read the full
>> source for each function/class of your library to be able to use it
>> then I'd say "no. thank you" even if you are too smart.
>>
>> On Thu, Jun 23, 2011 at 1:47 PM, Tony Morris wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 23/06/11 20:23, Matthew Pocock wrote:
>>>> HI Tony,
>>>>
>>>>
>>>>> I see no reason to give a crap about people who think that "Scala
>>>>> is too complicated", which we all know really means, "I don't
>>>>> get understand programming in general and I refuse to change
>>>>> this."
>>>>>
>>>>
>>>> I'm sure this is the case for some people, but not for all.You
>>>> can't (and shouldn't even try to) please all people, but
>>>> correctly-pitched documentation (user-oriented, getting-started,
>>>> faq, tutorials, ...) would make scala accessible to more people.
>>>> Who knows? They may even start to understand programming in
>>>> general.
>>>
>>>
>>> It is my experience, and that of others who are serious about learning
>>> and teaching, that appeasement of this kind of silliness is directly
>>> detrimental to the objective of coming to learn. However, I yearn for
>>> more robust data than such anecdotes, despite their universality.
>>>
>>>>
>>>>
>>>>> This poor newcomer hasn't yet it had it pointed out that calling
>>>>> +: is a bad idea, regardless of its name.
>>>>>
>>>>
>>>> Depends on the collection, doesn't it. It's bad for List. It should
>>>> be almost free on a persistent vector. @complexity, anyone?
>>>
>>> Yes. I assumed List, perhaps hastily.
>>>
>>>>
>>>> Matthew
>>>>
>>>
>>>
>>> - --
>>> Tony Morris
>>> http://tmorris.net/
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.10 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iEYEARECAAYFAk4DGcoACgkQmnpgrYe6r60GogCfd1eGp224JbbEjhQmD+tj97Eb
>>> WSwAnRbUGrFYqGnb4+coFI1OSbHR3x6/
>>> =GrVS
>>> -----END PGP SIGNATURE-----
>>>
>>>
>>
>

SCNR to comment again here:

> If you look at the function declaration it is pretty clear what each
> of these does. Just follow the types. If you do there is only a
> single implementation for each function that makes any sense.

And here we are exactly at the core of the problems people have with FP,
Scalaz and some answers in this list.

Most of the people coming from the typical programming world out there
are not able to do this. Our brain has been trained over years with
ignorance of this type of thinking.
Much too OO-ey, too imperatively. Much too control-flow-based instead
of transformation based, too few generalisations and abstractions.
(I recently became aware of this in discussions with colleagues)

So the question is: How to get training/guidance into that matter?
Some good books which explain that using Scala are helpful, e.g. the
upcoming "Scala in Depth" is a good first step in this direction.

A good introductory book exactly about this topic (say: "Thinking in Types"
or "Thinking in Transformations" or so) which would train this capability
by locking up Scalaz would be immediately on my wishlist.

Until then, the art of looking at a declaration and getting the only possible
implementation keeps being a sudoku game. If interested in it, it can give
you an entertaining hour or two.

KR
Det

type Developing[P] = P with SomeLackOfKnowledge with EarnestWishToLearn
type Skilled[P] = P with BetterUnderstanding

type SuccessfulDevelopment[P] = (Developing[P], GoodGuidance) => Skilled[P]

I've started using a variation of Tony's "Further Understanding
Option" post as an interview question for people looking to join my
team, precisely because any reasonably capable human being *should* be
able to work out that there is only one way get a B when given an A
and an A=>B

On Mon, Jun 27, 2011 at 3:34 PM, Detering Dirk
wrote:
> SCNR to comment again here:
>
>> If you look at the function declaration it is pretty clear what each
>> of these does.  Just follow the types.  If you do there is only a
>> single implementation for each function that makes any sense.
>
> And here we are exactly at the core of the problems people have with FP,
> Scalaz and some answers in this list.
>
> Most of the people coming from the typical programming world out there
> are not able to do this. Our brain has been trained over years with
> ignorance of this type of thinking.
> Much too OO-ey, too imperatively. Much too control-flow-based instead
> of transformation based, too few generalisations and abstractions.
> (I recently became aware of this in discussions with colleagues)
>
> So the question is: How to get training/guidance into that matter?
> Some good books which explain that using Scala are helpful, e.g. the
> upcoming "Scala in Depth" is a good first step in this direction.
>
> A good introductory book exactly about this topic (say: "Thinking in Types"
> or "Thinking in Transformations" or so) which would train this capability
> by locking up Scalaz would be immediately on my wishlist.
>
> Until then, the art of looking at a declaration and getting the only possible
> implementation keeps being a sudoku game. If interested in it, it can give
> you an entertaining hour or two.
>
> KR
> Det
>
> type Developing[P] = P with SomeLackOfKnowledge with EarnestWishToLearn
> type Skilled[P]    = P with BetterUnderstanding
>
> type SuccessfulDevelopment[P] = (Developing[P], GoodGuidance) => Skilled[P]
>

I am sorry to see the discussion degenerate like this. Here's my opinion:

Are symbolic names useful? Clearly yes.

Can they be mis-used? Of course, as can ASCII names.

Are some of the examples mentioned here useful or not? I have no opinion on this. There are many Scala libraries out there. Some of them use different naming conventions than others. When discussing these, keep it to the specific names and the specific library and please do not assume that every naming convention you see is the universally enforced Scala style. The style guide says to use symbolic names with care and to keep in mind the learning effort. Everybody has to decide for themselves the tradeoffs.

Does it mean that names are arbitrary and not worthy of discussion on this list? No. We need to take seriously the learning curve of beginning users. Names do matter. And armchair lecturing is not something we want on this list.

Thanks

 -- Martin


On Mon, Jun 27, 2011 at 4:42 PM, Alec Zorab <aleczorab@googlemail.com> wrote:

I've started using a variation of Tony's "Further Understanding
Option" post as an interview question for people looking to join my
team, precisely because any reasonably capable human being *should* be
able to work out that there is only one way get a B when given an A
and an A=>B

On Mon, Jun 27, 2011 at 3:34 PM, Detering Dirk
<Dirk.Detering@bitmarck.de> wrote:
> SCNR to comment again here:
>
>> If you look at the function declaration it is pretty clear what each
>> of these does.  Just follow the types.  If you do there is only a
>> single implementation for each function that makes any sense.
>
> And here we are exactly at the core of the problems people have with FP,
> Scalaz and some answers in this list.
>
> Most of the people coming from the typical programming world out there
> are not able to do this. Our brain has been trained over years with
> ignorance of this type of thinking.
> Much too OO-ey, too imperatively. Much too control-flow-based instead
> of transformation based, too few generalisations and abstractions.
> (I recently became aware of this in discussions with colleagues)
>
> So the question is: How to get training/guidance into that matter?
> Some good books which explain that using Scala are helpful, e.g. the
> upcoming "Scala in Depth" is a good first step in this direction.
>
> A good introductory book exactly about this topic (say: "Thinking in Types"
> or "Thinking in Transformations" or so) which would train this capability
> by locking up Scalaz would be immediately on my wishlist.
>
> Until then, the art of looking at a declaration and getting the only possible
> implementation keeps being a sudoku game. If interested in it, it can give
> you an entertaining hour or two.
>
> KR
> Det
>
> type Developing[P] = P with SomeLackOfKnowledge with EarnestWishToLearn
> type Skilled[P]    = P with BetterUnderstanding
>
> type SuccessfulDevelopment[P] = (Developing[P], GoodGuidance) => Skilled[P]
>

--
----------------------------------------------
Martin Odersky
Prof., EPFL and CEO, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Haha, so I know where to go when looking for a job!

On 28/06/11 00:42, Alec Zorab wrote:
> I've started using a variation of Tony's "Further Understanding
> Option" post as an interview question for people looking to join
> my team, precisely because any reasonably capable human being
> *should* be able to work out that there is only one way get a B
> when given an A and an A=>B
>
> On Mon, Jun 27, 2011 at 3:34 PM, Detering Dirk
> wrote:
>> SCNR to comment again here:
>>
>>> If you look at the function declaration it is pretty clear what
>>> each of these does. Just follow the types. If you do there is
>>> only a single implementation for each function that makes any
>>> sense.
>>
>> And here we are exactly at the core of the problems people have
>> with FP, Scalaz and some answers in this list.
>>
>> Most of the people coming from the typical programming world out
>> there are not able to do this. Our brain has been trained over
>> years with ignorance of this type of thinking. Much too OO-ey,
>> too imperatively. Much too control-flow-based instead of
>> transformation based, too few generalisations and abstractions.
>> (I recently became aware of this in discussions with colleagues)
>>
>> So the question is: How to get training/guidance into that
>> matter? Some good books which explain that using Scala are
>> helpful, e.g. the upcoming "Scala in Depth" is a good first step
>> in this direction.
>>
>> A good introductory book exactly about this topic (say: "Thinking
>> in Types" or "Thinking in Transformations" or so) which would
>> train this capability by locking up Scalaz would be immediately
>> on my wishlist.
>>
>> Until then, the art of looking at a declaration and getting the
>> only possible implementation keeps being a sudoku game. If
>> interested in it, it can give you an entertaining hour or two.
>>
>> KR Det
>>
>> type Developing[P] = P with SomeLackOfKnowledge with
>> EarnestWishToLearn type Skilled[P] = P with
>> BetterUnderstanding
>>
>> type SuccessfulDevelopment[P] = (Developing[P], GoodGuidance) =>
>> Skilled[P]
>>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The brain is mutable. I have seen it happen, many times (and of
course, I have studied psych at tertiary level and continue to do so
in my armchair).

How often do you think I have to listen to these kind of rants? Much
more than each individual provides them right? Of course.

Don't take it personally -- you're just exhibiting one of the steps as
you struggle to come to terms with a particular topic. I absolutely
promise you this. If I were to coach you, I'd dismiss what you have
said, so as not to continue entertaining the distraction, then focus
on the subject matter. There is no "problem" for anyone to address
except perhaps this one.

It's not impossible. It's not even that difficult -- most people look
back at themselves and laugh. It can be done.

On 28/06/11 00:34, Detering Dirk wrote:
> SCNR to comment again here:
>
>> If you look at the function declaration it is pretty clear what
>> each of these does. Just follow the types. If you do there is
>> only a single implementation for each function that makes any
>> sense.
>
> And here we are exactly at the core of the problems people have
> with FP, Scalaz and some answers in this list.
>
> Most of the people coming from the typical programming world out
> there are not able to do this. Our brain has been trained over
> years with ignorance of this type of thinking. Much too OO-ey, too
> imperatively. Much too control-flow-based instead of transformation
> based, too few generalisations and abstractions. (I recently became
> aware of this in discussions with colleagues)
>
> So the question is: How to get training/guidance into that matter?
> Some good books which explain that using Scala are helpful, e.g.
> the upcoming "Scala in Depth" is a good first step in this
> direction.
>
> A good introductory book exactly about this topic (say: "Thinking
> in Types" or "Thinking in Transformations" or so) which would train
> this capability by locking up Scalaz would be immediately on my
> wishlist.
>
> Until then, the art of looking at a declaration and getting the
> only possible implementation keeps being a sudoku game. If
> interested in it, it can give you an entertaining hour or two.
>
> KR Det
>
> type Developing[P] = P with SomeLackOfKnowledge with
> EarnestWishToLearn type Skilled[P] = P with BetterUnderstanding
>
> type SuccessfulDevelopment[P] = (Developing[P], GoodGuidance) =>
> Skilled[P]