Som Snytt | 22 Jul 07:12 2014
Picon

Maybe braces really are parens


I find it mildly peeve-inducing when people say that braces and parens are somehow interchangeable, but here is more evidence in their favor:

def f() {}  // an empty procedure

gets rewritten to

def f() = ()

Also, it's certainly a measure of some degree of desuetude in the community that this is what passes for Scala debate these days.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Scala Mailing Lists | 21 Jul 15:32 2014
Picon
Picon

Mailing list reminder: Scala-debate

Welcome to the "Scala-debate" mailing list.

This automatic reminder is sent once a month to the list,
to keep subscribers up-to-date with the mailing list services,
and to help keeping the list on topic.

-------------------------------------------------------------------

The "Scala-debate" mailing list:

This list is a more relaxed forum for Scala discussions
that would probably be off-topic or too convoluted for
the other lists, but that may still be quite interesting
to follow for a selected readership.

In particular, the following are appropriate:

  * threads that evolved beyond their initial topic,
      and have become too long or convoluted to be
      of interest to most readers
  * threads discussing extremely specialized topics
  * threads that are mostly speculative in nature,
      out-of-the-box thinking, philosophical views
      (as long as they are still somehow related
      to Scala)
  * debates (of course)

The "Scala-debate" list is the natural destination of all
the threads that start on other mailing lists, but are no
longer on topic on their original list, or have turned
into an in-depth debate about something.

-------------------------------------------------------------------

Other information:

There are several Scala lists devoted to individual topics (and
more may be created in the future). For the full list, please
see: http://www.scala-lang.org/node/199

Try to avoid cross-posting whenever possible. If you can, select
the list that is closer to your topic and post in that list only.
In any case, never cross-post replies.

If you ever want to unsubscribe from this list, just visit this
page: http://groups.google.com/group/scala-debate/subscribe
or send an email to scala-debate+unsubscribe <at> googlegroups.com

Thank you!
The Scala Team

--

-- 
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Malte Isberner | 19 Jul 06:50 2014
Picon

Updated method for case classes

Hi,

I have been using Scala for about a month now, and what I like most about it is how it allows you to write very concise code - even more so since I almost exclusively used Java for the last couple of years. I'd like to discuss a pattern I found myself using frequently when working with immutable objects/case classes, and I wonder if this might be something general enough to be added to the language (as an additional synthetic, autogenerated method for case classes).

I often use case classes whose values are immutable collections, such as Maps. In many use cases, I need to "modify" (in an immutable fashion) exactly one of the instance fields, say a map. Of course I could write obj.copy(map = obj.map.updated(key, value)), which however is inconvenient if obj is not a val, but a more complex expression. My first solution was to introduce methods such as
def withUpdatedMap(key: K, value: V) = copy(map = map.updated(key, value))
but this gets tedious as the number of use cases grows: what about mapValues, remove (-) and so on?

I finally came up with this solution: https://gist.github.com/misberner/eec5e74f759353da3384 , which allows me to rewrite the above concisely by using the underscore symbol, as, e.g.,
obj.updated(map = _.updated(key, value)), or obj.updated(map = _.mapValues(-_))
It might be a little bit ugly to use the same parameter names for functions that are used for the fields, but I think this definitely contributes to the readability and descriptiveness of the updated() invocation.

I almost made a habit of adding this method to my case classes, and I actually use it more often than the copy method now. I think it'd be very useful if the compiler would autogenerate this method, as it does with copy (even though implementing it by hand is not that big of a deal, but neither would it be to implement copy).

Looking forward to hear your opinions.

Best regards,
Malte

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Rich Oliver | 10 Jul 17:57 2014
Picon

Do we need Collection[T <: Any] classes?

This is a question for both the general case of a high level language and the particular case of a high level language targeting the JVM. It is intended to stimulate debate and increase theoretical understanding but there is absolutely no intention on my part to imply criticism of Scala's past design choices. However I personally find it very helpful to understand the reason for design choices: Basic principle / interop with JVM / interop with Java / following established conventions etc.

I consider myself very pro Objected Orientated programming to the point of paranoia, always suspecting extreme functional types (of people) of seeking to abolish inheritance. In one sense no existing language is object oriented enough for me: providing strong static typing, fully constructor multiple inheritance and proper handling of variance. But having Collection classes that take a type parameter inherited from Any seems totally inappropriate.

So there should be a collection inheritance heirachy based on T <: AnyRef and then separate collection heirachies for say

8 byte values
16 byte values
24 byte values
32 byte values

arguably there should also be hierarchies for 4 and 12 byte values.

Some kind of Macros could generate the different hierarchies to keep the code DRY. Map functions could map between them, but they should not under any circumstances be connected by inheritance. I really can't see the need for having collections that contain both ref and value types, but even if there are people who would use them I don't think that justifies the great damage that over generic hierarchies create. The above could handle C# style structs. In similar vein there is the slogan "everything is an object". To which my reaction is: no its not and what on earth is gained by pretending that it is? I can see how there might be advantages for Dynamic languages but not for Static.

In an ideal world I don't think == should be inherited from Any either. Then a RefSet[+T <: AnyRef] class could be covariant.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Som Snytt | 5 Jul 02:37 2014
Picon

Softwear


I don't mean to start a language flame war, but Scala has better t-shirts, if only I knew how to get one.

http://blog.xamarin.com/run-a-f-sharp-app-get-a-f-sharp-shirt/


--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Som Snytt | 27 Jun 04:32 2014
Picon

Option Viktor


Sorry if this is an old one, but I just read this today.

http://unicode.org/reports/tr46/

For transitional use, the Compatibility Processing also allows domain names containing symbols and punctuation that were valid in IDNA2003, such as √.com (which has an associated web page). Such domain names containing symbols will gradually disappear as registries shift to IDNA2008.

The web site describes "option V", but it turns out that "option V" has nothing to do with Akka.

http://xn--19g.com/  <http://√.com/>

For that rare pernicious Akka bug...

"We can always deploy -- option √ !!!"




--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Alexandru Nedelcu | 26 Jun 14:22 2014

The Clash of Lambdas Benchmark

Hi,

There's an interesting benchmarks circulating lately:

The benchmark is sort of comparing libraries, rather than languages, but I think 2 things are sticking out of it in regards to the apparent poor performance of Scala:

1. collections really need specialization, as working with primitives is really common and the price paid for boxing primitives is a performance killer 
2. Scala's Views are really terrible - which is odd for a standard library of an FP language exposing immutable collections as the default 

I was wondering if there are plans to address the above.

--
Alexandru Nedelcu
www.bionicspirit.com

PGP Public Key:
https://bionicspirit.com/key.aexpk

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Dimitar Georgiev | 23 Jun 10:16 2014
Picon

real arguments in favor of dynamic typing

Hello,

Happily exploring the Scala  world for a couple of years now, and Haskell more recently, I'm now looking for some good piece of writing which advocates for dynamic typing in an objective manner. That is, I want to broaden my horizons by learning to write some Underscore , or some Clojure, but I can't find good arguments to invest this precious time.

Most of the stuff I find on the internet on this topic is disappointingly mediocre opinion pieces, or stuff that is just plain wrong. For an example of the latter, see the top-rated answer of
http://programmers.stackexchange.com/questions/122205/what-is-the-supposed-productivity-gain-of-dynamic-typing

Does there exist some piece of writing on the topic that at least tries to have a scientific approach? Maths will of course be best. I could also settle for a philosophical piece, if it is careful with opinions.

Regards, Dimitar

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Scala Mailing Lists | 21 Jun 15:32 2014
Picon
Picon

Mailing list reminder: Scala-debate

Welcome to the "Scala-debate" mailing list.

This automatic reminder is sent once a month to the list,
to keep subscribers up-to-date with the mailing list services,
and to help keeping the list on topic.

-------------------------------------------------------------------

The "Scala-debate" mailing list:

This list is a more relaxed forum for Scala discussions
that would probably be off-topic or too convoluted for
the other lists, but that may still be quite interesting
to follow for a selected readership.

In particular, the following are appropriate:

  * threads that evolved beyond their initial topic,
      and have become too long or convoluted to be
      of interest to most readers
  * threads discussing extremely specialized topics
  * threads that are mostly speculative in nature,
      out-of-the-box thinking, philosophical views
      (as long as they are still somehow related
      to Scala)
  * debates (of course)

The "Scala-debate" list is the natural destination of all
the threads that start on other mailing lists, but are no
longer on topic on their original list, or have turned
into an in-depth debate about something.

-------------------------------------------------------------------

Other information:

There are several Scala lists devoted to individual topics (and
more may be created in the future). For the full list, please
see: http://www.scala-lang.org/node/199

Try to avoid cross-posting whenever possible. If you can, select
the list that is closer to your topic and post in that list only.
In any case, never cross-post replies.

If you ever want to unsubscribe from this list, just visit this
page: http://groups.google.com/group/scala-debate/subscribe
or send an email to scala-debate+unsubscribe <at> googlegroups.com

Thank you!
The Scala Team

--

-- 
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Rüdiger Möller | 15 Jun 02:38 2014
Picon

Fwd: Re: [scala-user] What's up with Paul Phillips?


i accidentally replied private ,,,
---------- Forwarded message ----------
From: Rüdiger Möller <moru0011 <at> gmail.com>
Date: 2014-06-14 18:36 GMT+02:00
Subject: Re: [scala-debate] Re: [scala-user] What's up with Paul Phillips?
To: Kevin Wright <kev.lee.wright <at> gmail.com>


elegance+conciseness and readability are not necessary the same. E.g. operator overloading is fine for the author but can be hell in a team/large project/libraries. "<<?" just has no inherent meaning, so it can mean anything ..
2cnd: invisible stuff like type coercion (e.g. C++ cast operator overloading) are only helpful in writing code (overdone type inference can yield similar "obfuscation" effects for a code reader). So while in general fewer lines mean better readability, it is not necessarily this way. Else "Brainfuck" would be the most readable language ever :-).


2014-06-14 17:52 GMT+02:00 Kevin Wright <kev.lee.wright <at> gmail.com>:

At what point did elegance+conciseness and readability become orthogonal concepts?


On 14 June 2014 16:43, Rüdiger Möller <moru0011 <at> gmail.com> wrote:
As an experienced industry level developer/architect I am shocked. I am just observing Scala from the sidelines, however
I'd say some of his (in large parts valid) points are signs of death or extreme danger, e.g.

* never thought about it: (too) advanced type-inference is very dangerous as it destroys predictability and creates a strong dependency of the concrete language to the current compiler implementation (which seems quite messy currently).
* inability to tell wether behaviour is a bug or a feature sounds also very dangerous. Very C++'ish
* what he told about behind-the-scenes handling of primitive types and the amount of checks generated also does not sound good ..

If the fundamental parts of his critique are valid (I am not too deep into Scala to judge), than the language in its current state is definitively a failure. Predictability+Readability are so much more important (like 1000 times) than elegance, conciseness in industrial-level large scale projects.

Seriously, you should consider a "reboot" with a tighter, simpler spec and a reduced "Scala-the good parts" reimplementation.

Am Donnerstag, 30. Januar 2014 21:21:24 UTC+1 schrieb Eric Kolotyluk:
Thanks Curtis, I just watched this too because of your post.

To answer your last question: NO, we don't have to throw the baby out with the bath water.

On the surface, Paul's presentation smells like crazy talk, but after watching it sincerely, it does not smell bad. He has some really valid points to make about Scala, and the Scala collections API.

When I look at this from a User Interface perspective (because that is one of my specialties), my most important principle in UI Design is the WTF Principle. If a user looks at your User Interface Design and Implementation and says "What The Fuck?" the design and implementation is a failure, a defect. In Scala the language is the design, and the APIs are the implementation, and Paul as quite dramatically shared many of my personal WTF moments in Scala, he really resonates with what I feel as a user of Scala and the APIs. The Scala APIs are the User Interface to the developers.

The most important thing I have ever learned from Martin Odersky is the importance of being able to "reason about code" and Paul Phillips really reinforces this principle. Scala, and Functional Programming in particular, offers great hope in being able to reason well about code. But, quite frankly, some of of the APIs I have seen completely contradict the principle of being able to reason about code. Whenever I read the ScalaDoc my first reaction is: "this is way fucking worse than reading .NET docs on their APIs." In this sense, ScalaDoc is a complete failure to me in having any hope of reasoning about Scala and its APIs. ScalaDocs are written for a small, elite group of idiot savants, and has little utility for general programmers, or even mere mortals.

In a nutshell, I still believe in Scala, but I would hope that some people, some influential people, will watch Paul's presentation, take it to heart, and make some serious attempts to bring some sanity back to Scala, and especially the APIs.

I personally don't care if the language changes, and I would rather use some new and different APIs than what I currently see. Sure, leave the old shit there for backwards compatibility, but I hope someone can come along and 'save' Scala, and make a version that stays more true to "being able to reason about code" especially for mere mortals.

In a nutshell, Scala is still way more fun to use that Java.

Cheers, Eric

On 1/30/2014 10:13 AM, Curtis Stanford wrote:
I just watched a 30-minute rant from Paul Phillips about how terribly, unredeemably screwed up scala is, especially the collections library. He knows what he's talking about, being a co-founder of Typesafe and working for 5 years on the scala compiler and libraries. But he says he's not anti-scala? 

He has some valid points but the whole thing just seemed like he had some kind of axe to grind and was incredibly frustrated and vindictive. In the end, it just made me question my decision to use scala. No, scala is not perfect but is better than the other JVM alternatives IMHO. Can we do better? Sure. Do we have to throw out scala to do better? I don't know anymore...



--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Rüdiger Möller | 15 Jun 02:37 2014
Picon

Fwd: Re: [scala-user] What's up with Paul Phillips?



---------- Forwarded message ----------
From: Rüdiger Möller <moru0011 <at> gmail.com>
Date: 2014-06-14 20:08 GMT+02:00
Subject: Re: [scala-debate] Re: [scala-user] What's up with Paul Phillips?
To: Kevin Wright <kev.lee.wright <at> gmail.com>


You asked for an example where elegance != readability and I gave 2. I agree most of the time short code is readable code. However there is a point where obfuscation starts :-) and from an industry perspective restricting here is good (from a fun factor perspective it isn't ofc).
Again the most elegant solution is not the most understandable (think of the average joe .. he makes up like 50% of the developing workforce).


2014-06-14 18:49 GMT+02:00 Kevin Wright <kev.lee.wright <at> gmail.com>:

" operator overloading is fine for the author but can be hell in a team/large project/libraries. "<<?" just has no inherent meaning, so it can mean anything"

That's not about elegance, it's about choosing sane names for things.  I have yet to hear anyone complain that Java's BigInts would be hell to test if they could be added with a `+`.
Similarly, you'd be in a world of pain if your method named "copyPuppyPhoto" actually set off the nukes.

All names can be abused, or badly chosen.  It's poor reasoning to single out "operator overloading" for blame here.


As for Brainfuck... Seriously, show me any meaningful program where it would take less code than Scala.


On 14 June 2014 17:36, Rüdiger Möller <moru0011 <at> gmail.com> wrote:
elegance+conciseness and readability are not necessary the same. E.g. operator overloading is fine for the author but can be hell in a team/large project/libraries. "<<?" just has no inherent meaning, so it can mean anything ..
2cnd: invisible stuff like type coercion (e.g. C++ cast operator overloading) are only helpful in writing code (overdone type inference can yield similar "obfuscation" effects for a code reader). So while in general fewer lines mean better readability, it is not necessarily this way. Else "Brainfuck" would be the most readable language ever :-).


2014-06-14 17:52 GMT+02:00 Kevin Wright <kev.lee.wright <at> gmail.com>:

At what point did elegance+conciseness and readability become orthogonal concepts?


On 14 June 2014 16:43, Rüdiger Möller <moru0011 <at> gmail.com> wrote:
As an experienced industry level developer/architect I am shocked. I am just observing Scala from the sidelines, however
I'd say some of his (in large parts valid) points are signs of death or extreme danger, e.g.

* never thought about it: (too) advanced type-inference is very dangerous as it destroys predictability and creates a strong dependency of the concrete language to the current compiler implementation (which seems quite messy currently).
* inability to tell wether behaviour is a bug or a feature sounds also very dangerous. Very C++'ish
* what he told about behind-the-scenes handling of primitive types and the amount of checks generated also does not sound good ..

If the fundamental parts of his critique are valid (I am not too deep into Scala to judge), than the language in its current state is definitively a failure. Predictability+Readability are so much more important (like 1000 times) than elegance, conciseness in industrial-level large scale projects.

Seriously, you should consider a "reboot" with a tighter, simpler spec and a reduced "Scala-the good parts" reimplementation.

Am Donnerstag, 30. Januar 2014 21:21:24 UTC+1 schrieb Eric Kolotyluk:
Thanks Curtis, I just watched this too because of your post.

To answer your last question: NO, we don't have to throw the baby out with the bath water.

On the surface, Paul's presentation smells like crazy talk, but after watching it sincerely, it does not smell bad. He has some really valid points to make about Scala, and the Scala collections API.

When I look at this from a User Interface perspective (because that is one of my specialties), my most important principle in UI Design is the WTF Principle. If a user looks at your User Interface Design and Implementation and says "What The Fuck?" the design and implementation is a failure, a defect. In Scala the language is the design, and the APIs are the implementation, and Paul as quite dramatically shared many of my personal WTF moments in Scala, he really resonates with what I feel as a user of Scala and the APIs. The Scala APIs are the User Interface to the developers.

The most important thing I have ever learned from Martin Odersky is the importance of being able to "reason about code" and Paul Phillips really reinforces this principle. Scala, and Functional Programming in particular, offers great hope in being able to reason well about code. But, quite frankly, some of of the APIs I have seen completely contradict the principle of being able to reason about code. Whenever I read the ScalaDoc my first reaction is: "this is way fucking worse than reading .NET docs on their APIs." In this sense, ScalaDoc is a complete failure to me in having any hope of reasoning about Scala and its APIs. ScalaDocs are written for a small, elite group of idiot savants, and has little utility for general programmers, or even mere mortals.

In a nutshell, I still believe in Scala, but I would hope that some people, some influential people, will watch Paul's presentation, take it to heart, and make some serious attempts to bring some sanity back to Scala, and especially the APIs.

I personally don't care if the language changes, and I would rather use some new and different APIs than what I currently see. Sure, leave the old shit there for backwards compatibility, but I hope someone can come along and 'save' Scala, and make a version that stays more true to "being able to reason about code" especially for mere mortals.

In a nutshell, Scala is still way more fun to use that Java.

Cheers, Eric

On 1/30/2014 10:13 AM, Curtis Stanford wrote:
I just watched a 30-minute rant from Paul Phillips about how terribly, unredeemably screwed up scala is, especially the collections library. He knows what he's talking about, being a co-founder of Typesafe and working for 5 years on the scala compiler and libraries. But he says he's not anti-scala? 

He has some valid points but the whole thing just seemed like he had some kind of axe to grind and was incredibly frustrated and vindictive. In the end, it just made me question my decision to use scala. No, scala is not perfect but is better than the other JVM alternatives IMHO. Can we do better? Sure. Do we have to throw out scala to do better? I don't know anymore...





--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Gmane