10 ms·

In Scala, there are just too many ways to do things. It's optimized for flexibility and easy writability. C# on the other hand may be a little more verbose, bu

• saosebastiao 12y ago
  Funny, I find c# much harder to read. Its almost as if it is easy to understand code for languages you know well, and harder to understand code for languages you don't.
  • jbooth 12y ago
    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
    • 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.
      • 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.
• Vektorweg 12y ago
  Actually, the vast amount of features in C# isn't improving readability. But MS can't just throw out the bad half of features, which makes C# practically unimprovable. Scala has a similar problem.
  • alkonaut 12y ago
    Why not? I just can't see why every language needs to gather cruft rather than evolve elegantly. Imho major versions of compilers should aim to NOT remain backwards compatible, so they can remove or change things in the syntax while they add things.
    • marvy 12y ago
      Imagine this. I'm using Cool-Lang version 2. Now Cool-Lang 3 comes out. It has lots of features that I want to use. If the new version is compatible with the old one, I download it and start using it. If not, I have to convert my whole codebase first. In practice, that means it may be many years before I can use version 3. Look at Python. In 3.0, they decided to clean up some stuff from 2.x. They even wrote a tool 2to3 which will automatically fix most of the incompatible stuff for you, so converting the whole codebase is almost automatic. The problem is "almost" automatic is not enough. Many people and groups have yet to convert their old code.
      • alkonaut 12y ago
        Py2 to py3 is too far a jump which is made obvious from the fork-like nature of the project. Minor changes like API deprecation is of course already taking place in most projects. Just need to strike a balance. 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.
  • frowaway001 12y ago
    > But MS can't just throw out the bad half of features, which makes C# practically unimprovable. Scala has a similar problem. 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.
• ffreire 12y ago
  IMHO this works to Scala's detriment. I very much enjoy Python and Clojure precisely because they have one, generally accepted way of doing things. Is it a silver bullet? Of course not, but this works for me 9 times out 10 and I find that coming back to my code later (or sharing with colleagues) is far easier because most code will be structured in a familiar way and therefore take less time to understand the unique bits that solve the problem at hand.
  • taylorlapeyre 12y ago
    Clojure is my favorite language by far, but there's hardly "have one, generally accepted way" of doing everything.
  • moonchrome 12y ago
    Actually that's the one thing that's driven me away from Clojure. 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/clojure/clojure/core/async/impl/channels.clj#L67 https://github.com/clojure/core.async/blob/master/src/main/c...
    • nickik 12y ago
      I think the nice thing is that you can start without types and add them later, staticlly or with dynamic checks. First I play around with data, once I know what I want I can write some schema annotation. 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.