I love the simplicity behind the language and it makes simple things actually simple - which isn't as trivial as it sounds. But once you start dealing with complex things in Clojure the language doesn't do much for you, if you can't fit your problem in to it's provided toolkit the code written will actually be horrible - for example go look at core.async [1] implementation - just reading that code gives me a headache - I understand it's complicated stuff with buffering and all but having type annotations on protocols and variables used would be extremely helpful when trying to parse that code. Types help me think more abstractly when I'm reading the code as I can take them as compiler enforced contracts and think of them in abstract terms, in dynamically typed languages complexity and the amount of things you need to be aware of is just too overwhelming IMO.

[1] https://github.com/clojure/core.async/blob/master/src/main/c...

You can activate validation for everything in development and then in productive only activate validation on your api endpoints. In a future version, you will probebly be able to generate core.typed stuff directly from schema.

Other then that, I think extreamly high performace code a la core.async is not the norm, there the types are not used for the programmer, but rather for the VM. I have used type hints in the last couple of years maybe, one or twice.

I've tried core.typed, it's amazing in theory but in practice it's unusable (at least for me) and nobody annotates their code anyway. If core.typed becomes more widespread in Clojure community I might actually give it a second chance, in the mean time I'm just going to use Kotlin for JVM, it has transparent Java interop and reduces the Java noise, and the tools (IDEA) is infinitely better than anything I've seen in Clojure land.

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.

[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

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
    {
    }

[1] https://github.com/louthy/csharp-monad

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.

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.

  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);
  }
  
  }

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

I rewrote 100klines at least from C#1 to C#2 when generics came in 2.0. It was compatible in that the non generic code still worked, but I don't really see what difference that made. If we didn't want to upgrade the cod me then we wouldn't have updated the compiler!

Obviously if you don't want the benefits of Py3 then you don't have to pay the upgrade cost either.

How? Scala has been throwing out bad features in pretty much every single release for the last 5 years.

It's nothing breathtaking, it just gets done, people are happier and the language gets better.

Plus, for this question, the size of the user base doesn't matter: If a developer has to adapt his code to a new language version, he/she doesn't care whether ten or ten-thousand other people have to do the same.

Scala's smaller user base means there are a lot of less people to get mad.

> Scala has been throwing out bad features in pretty much every single release for the last 5 years.

You cannot throw out features in a language with the community size C# has, otherwise you just get another Python 3.0.

  a) Microsoft is in an excellent position to make such 
     changes, unlike Python, because Microsoft shops will 
     largely do whatever Microsoft tells them.

     Just have a look at how often they have incompatibly 
     changed the standard library used by C#.

  b) Not every language has to botch the transition as badly
     as Python designers did.