You find C# harder than this?
trait SeqLike[+A, +Repr] extends Any with IterableLike[A, Repr] with GenSeqLike[A, Repr] with Parallelizable[A, ParSeq[A]] { self =>
or
def :+[B >: A, That](elem: B)(implicit bf: CanBuildFrom[Repr, B, That]): That
trait SeqLike[+A, +Repr] extends Any with IterableLike[A, Repr] with GenSeqLike[A, Repr] with Parallelizable[A, ParSeq[A]] { self =>
or
def :+[B >: A, That](elem: B)(implicit bf: CanBuildFrom[Repr, B, That]): That
Outside of some pretty extreme examples (scalaz maybe), I don't think I've actually ever seen someone else's source that implemented a custom collection.
And you're purposefully trying to confuse people by digging into what might as well be "internal" signatures.
What do the actual, official docs say about SeqLike :+ ?
> def :+(elem: A): Seq[A]
> [use case] A copy of this sequence with an element appended.
Can you dig down further and find the CBF signature? Yes. Do you need to for anything outside of spreading FUD? Nope. Is it a bad thing that it shows how the sausage is made underneath the covers? I don't think so.
If the collections API is purposely trying to confuse people, blame the Scala team, not me.
Akka? Spray? ScalaUtils? Do they take effort to learn? Yes. Are they anything like scala.collections? No.
Why didn't you pick scala.concurrent? Or scala.util? Or any number of other packages? Why didn't you use the signatures in the official docs as-presented?
The Scala team goes out of their way to present something simple and easily digestible to most programmers, even the ones unfamiliar with Type Classes.
I mean, you basically just use a Seq like an immutable version of Ruby's Array and it just does what you want 99.999% of the time.
How often do you see people go on to propose that because much of Ruby's Array implementation would be incomprehensible to 90% of Ruby programmers that that makes Ruby a bad language? It's an entirely ridiculous metric.
Both languages can be difficult to decipher. I do find that Scala's syntax is much more flexible, which can lead to more stumbling when trying to read code.
Annoyingly F# brought them along for the ride too, although you rarely have to explicitly write them.
I wrote a library of monads for C# [1], and implementing the SelectMany method is a good example of how messy it can be:
public static RWS<R, W, S, V> SelectMany<R, W, S, T, U, V>( this RWS<R, W, S, T> self, Func<T, RWS<R, W, S, U>> bind, Func<T, U, V> project)
{
}
Option<int>
int option
public static SelectMany R W S T U V ( this self : RWS R W S T, bind : Func T (RWS R W S U), project : Func T U V) : RWS R W S V
{
}
class Thing int
{
}
class Thing T : BaseThing T
{
}
A Scala dev will look at the Scala type signature and shrug.
A C# dev will look at the C# type signature and shrug.
As usual, unfamiliar things are difficult and familiar things are easy.
A talented C# dev will need to know co/contravariance as well as implicits considering they also exist in C#.
In Scala, being familiar with these concepts is practically a necessity, though.
using System;
public class Program
{
public class Person
{
private string _name;
private int _age;
public Person(string name, int age)
{
_name = name;
_age = age;
}
public static implicit operator int(Person p)
{
return 42;
}
}
public static void Main()
{
var person = new Person("Jim", 51);
var number = 100;
AdditionPrinter(person, number); // Prints 142
}
public static void AdditionPrinter(int a, int b)
{
Console.WriteLine(a + b);
}
}True for co/contravariance. For implicits, that depends on which implicits you are talking about.
Scala has:
* implicit conversion operators (these have existed in C# for some time, under the same name)
* implicit parameters (C# doesn't have an analog to these that I can think of)
* implicit classes (C# has an analog in classes providing extension methods, though the classes themselves are distinguished by a keywords as they are in Scala; in Scala, these are essentially syntactic sugar for creating a normal class and an implicit conversion from the extended class.)
C# allows default values for parameters, but it's not quite the same.
Example of C# default value for parameter:
static void Addition(int a, int b = 42)
{
Console.WriteLine(a + b);
}
Addition(4); // Prints 46
Addition(4, 5); // Prints 9
Like C#, implicit parameters must come after non-implicit parameters (if any).
Unlike C#, the implicit value does not need to be defined in the signature. Also unlike C#, if you provide the value for one implicit parameter, you must provide the value for all implicit parameters.
Right. Scala has C#-style default parameters as well, implicit parameters are a different (though very loosely related) thing.
Though implicits I feel are so much simpler than many people fear.
From a Ruby perspective: Just think of them as operating similarly to Refinements, except not completely insane because there is no global scope at compilation. You only have to worry about your own package, imports and inheritance.
Tracking down an implicit generally takes all of 10 seconds, and never more than a few minutes. Even moderately brain-bendy ones like akka.patterns.ask (where does the implicit "?" come from? "ask" is actually an implicit conversion to a class that defines it: https://github.com/akka/akka/blob/master/akka-actor/src/main...).
[SerializableAttribute] [ComVisibleAttribute(false)] public class Dictionary<TKey, TValue> : IDictionary<TKey, TValue>, ICollection<KeyValuePair<TKey, TValue>>, IDictionary, ICollection, IReadOnlyDictionary<TKey, TValue>, IReadOnlyCollection<KeyValuePair<TKey, TValue>>, IEnumerable<KeyValuePair<TKey, TValue>>, IEnumerable, ISerializable, IDeserializationCallback { ... }
And this is of course ignoring the fact you copied that from the documentation witch shows all interfaces the class implements. IDictionary also implements ICollection & IEnumerable so you wouldn't need to include them. So to actually implement this class it would more likely be
[SerializableAttribute] [ComVisibleAttribute(false)] public class Dictionary<TKey, TValue> : IDictionary<TKey, TValue>, IDictionary, IReadOnlyDictionary<TKey, TValue>, ISerializable, IDeserializationCallback { ... }
maybe less
Programming languages you don't know are harder to read than programming languages you do know.
Unlike "bad perl", you have types that tell you exactly what something does.
> ... and simple tutorials which don't go into the depths we need to know (like how do you create a Manifest from Java to call into Scala code that needs it?
Calling Scala from Java is not beginner level material that winds up in a tutorial, and it's a bad idea to begin with; you're stuck speaking a pidgin Scala using Java-only constructs just to maintain Java interop.
I will definitely agree with you there. It would help our team significantly if we had a Scala expert we could consult but there's not enough in the budget (monetary or political) to hire one. We are pretty much left to fend for ourselves with Google, Stack Overflow and a couple reference books. This project also contains a C++ component that would probably have been just as impenetrable to my teammates (who have C but no C++ experience) if I hadn't already been fairly familiar with the language.
> Unlike "bad perl", you have types that tell you exactly what something does.
Static typing doesn't help always when you actively try to subvert it. There are casts to and from Any all over this codebase. Reflection is used everywhere even when it's not necessary. There are even places where they convert between types by serializing an instance of one type and deserializing it as an instance of another (with similar fields but not actually related in the type system). They also loved Option[] types which might not be so bad if they weren't also storing Some(null) into them in just enough places you forget to check for it but it still blows up in your face at least a once a month. Basically, the original authors of this code tried their best to destroy the usefulness of the Scala type system and succeeded fairly well.
> Calling Scala from Java is not beginner level material that winds up in a tutorial, and it's a bad idea to begin with; you're stuck speaking a pidgin Scala using Java-only constructs just to maintain Java interop.
By mandate of our management we are not allowed to write any new Scala code except where absolutely necessary. The contractors went behind our management's back to write it in the first place (we told them they could use Java 8 which they interpreted to mean they could use anything that would run on a Java 8 JVM). After that was found out (about a 1/3 of the way through the contract and too late to rewrite everything without blowing our contractual deadline with our customer) new Scala code was banned and they had to (and we have to) use Java as much as possible after that point. This is also not helped by the fact that at the time they handed the code over it was barely half-baked and performing at less than 25% of the needed throughput and we're left trying to finish and fix it.
Of course, when it can take three or four developers (with a combined background in Java, C#, C, C++, Python, Javascript, and an academic familiarity with OCaml-family functional languages) a half hour or more to figure out what a some of the methods in this codebase even do (at both a syntatic and conceptual level) I am going to put (a small) part of the blame on Scala for allowing such impenetrable code to be written in the first place. I'm certainly not placing all or even a significant amount of the blame for this project's problems on Scala but it is certainly not helping.
Thanks for letting me vent.
The documentation for Scala is actually pretty outstanding IMO. I had a much easier time compared to Ruby. Daniel Westheide's introduction series "The Neophyte's Guide to Scala" is the single best language intro I've ever seen, for any language. It even goes into enough of Akka to get a basic chat application going. And while Akka works nicely with Scala, it's conventions are so different it might as well be a different language. In idiomatic Scala you probably don't run into mapTo or vars too often for example, but that's going to be a pretty common sight working with Akka.
At least the documentation on PlayFramework.com is mostly current, and doesn't gloss over important detail. Unlike rubyonrails.org, where even five years ago the basics were horribly dated, inaccurate, and skip important background.
I've seen C# that is almost as hard to read as bad Perl -- also, not surprisingly, from contractors who weren't going to be maintaining the code.
I don't think this says anything about C# or Scala, I think what it says is something about the natural result of the economic incentives of people being paid to throw code over the wall before they leave for greener pastures.
That being said, when you understand the nuances of type annotations, that code is quite readable in the mathematical notation sense. It is concise and takes more time per byte to understand, but it tells me enough about the code that I rarely have to read the actual implementation to know exactly what it does.
It is in fact representative of the vast majority of code you use.
The fact that it wasn't immediately clear to you that a lot of your code DOES use this code is probably the strongest argument I could make.
Personally, I make it a habit to always read (or try to read, in this case) standard library source code that I'm depending on to be correct.
Scala's STDlib might be more powerful, more honest and more consistent, and also might be striving to be DRY for the implementors.
Personally, I feel that Scala's Collections goes overboard in hitting the above goals, and the resulting signatures are too verbose. And this increases the cognitive load for the subset of people that need to bother about it (performance tuners, architects, etc). But that's not a fault of the language per se.
C++ is the poster child for this. No one argues that C++ is a bad language just because the standard library is full of magic.
To get the "ugly" signature you have to look at the actual source, or example the method definition in the official docs.
They go out of their way to make sure to present an easy-to-understand version for actual users.
Which is why every actual Scala developer rolls their eyes at someone bringing up CBF. You have to go out of your way to try to be confused about it. And if that digging stops at finding the method signature, well, probably serves you right for being confused. ;-)
Is CBF amazing? Probably not. Is it some sort of confusing eternal battle for most Scala developers? Absolutely not.
I mean just look at the official docs, find out where he got these weird examples from, and then tell me this is a well reasoned argument.