11 ms·

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

• deleted 12y ago
  [deleted]
• saosebastiao 12y ago
  You intentionally chose code that is hard to read...I could easily do the same with C#. It isn't representative of the vast majority of the code that I use nor write. 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.
  • jbooth 12y ago
    It's from the standard collections library, the most-used code in any language. 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.
    • saosebastiao 12y ago
      You have inferred more about me than you are entitled, and even if you were right, your argument is still poor. Have you read the c# stdlib? It is in no way any better. Stdlibs are always more complex than the code that builds on them, and that is by design. The same code that I use for a oneliner has to be robust enough to apply to play, akka, spark, finagle, etc. That is the primary reason why StdLib documentation is made more accessible. I have never had to read the Scala StdLib source code, and likely a tiny minority of Scala devs have done so.
      • jbooth 12y ago
        I inferred that you probably use standard library collections. Not really an insulting inference, it'd be insulting to assume you didn't. 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.
        • ezy 12y ago
          Have you read the implementation of the python collection types (list, map, etc.)?
      • Alphasite_ 12y ago
        The internals of STDlibs tend to be nasty, but externally they're designed to be clear. The problem here is externally these interfaces are extremely messy and hard to follow, i.e. the abstraction doesn't seem to work.
        • hrjet 12y ago
          That is a good distinction to make. But then, you need to consider other factors as well. How powerful is the API, how honest is the API (doesn't hide internal gimmicks), how consistent is the API across the lib, and how DRY it is (to the STDlib implementors). 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.
    • com2kid 12y ago
      Now I love C#, but in defense of the above poster, standard library code is often pretty gnarly stuff. 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.
      • jbooth 12y ago
        Actually, I hold exactly that opinion about C++ :)
      • 72deluxe 12y ago
        I find the STL great! Sure, some compiler template messages can be tricky to understand but STL doesn't detract from C++ - you don't have to use the STL (but you're probably losing out if you don't use it and roll all those containers and algorithms yourself)
        • com2kid 12y ago
          Oh using the STL itself is fine, but some of the code behind it looks like a completely different language!
  • hokkos 12y ago
    It is not representative probably because the IDE hide the ugliness.
    • ssmoot 12y ago
      The official docs do to. 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.
• jakevn 12y ago
  [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 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.
  • louthy 12y ago
    I'm a fan of C#, although I prefer F#; however I have to agree, I think the choice of < > for generic definitions was a real mistake, it can be so hard to parse. The side effect of this is that first-class functions (Func<>) are chronically underused by C# programmers. Annoyingly F# brought them along for the ride too, although you rarely have to explicitly write them.
    • rjbwork 12y ago
      What would you have used for generic arguments? I think they work fine, and make use of Func<T> often.
      • louthy 12y ago
        I haven't tried out many alternatives, but there's something about nested <> that seems to throw me off each time. 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) { } I quite like F#'s alternative syntax for single type generics: Option<int> Can be written: int option Obviously it's a personal thing, so I doubt I would be able to suggest anything that would change your mind; I just had a quick go at an alternative, and I quite like this: 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 { } It's moot anyway really, it is what it is. I've just found it cognitively challenging over the years. [1] https://github.com/louthy/csharp-monad https://github.com/louthy/csharp-monad
• MrRadar 12y ago
  Thank you! I'm working on a team that inherited some Scala code from contractors that no longer work for us and we've found that (at least their) Scala is almost as hard to read as bad Perl. Compounding this is a severe lack of good online documentation outside of the standard library reference 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? Or what even is a Manifest?). At least with Perl you have decades worth of online discussions and pretty good documentation of the core language.
  • teacup50 12y ago
    > we've found that (at least their) Scala is almost as hard to read as bad Perl. At least with Perl you have decades worth of online discussions and pretty good documentation of the core language. 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.
    • MrRadar 12y ago
      > Programming languages you don't know are harder to read than programming languages you do know. 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.
• ssmoot 12y ago
  If you want to make a compelling argument to anyone that actually knows Scala, you need to drop the idea you can make it with scala.collections. Find another altar. This is a complete non-issue for the day-to-day Scala developer. 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. Oh wow. Why does that look so much simpler than what you posted? Could it be you're exaggerating for effect and disingenuously implying that Scala developers will be routinely faced with the challenge of trying to parse such signatures? Of course you are. 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.
  • jbooth 12y ago
    Personally, I view the collections library as a showcase for how that language works when you're designing an API to be used for 3rd parties. If it's incomprehensible, that worries me. If the collections API is purposely trying to confuse people, blame the Scala team, not me.
    • ssmoot 12y ago
      That's just BS and given the size of your axe to grind, you have to know it. 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.
• vithlani 12y ago
  LOL! amen brother, tell it like it is.... people seem to have NO appreciation for the idea of simplicity.