From First Principles: Why Scala?

Post by didibus » Fri, Feb 12, 2021, 4:57 AM UTC

lihaoyi wrote: post #106

vemv wrote: post #101

> In contrast, cross-compilers for dynamic languages like Clojure tend to have a long-list of caveats and incompatibilites I don't think the author fully comprehended the linked resource (namely https://clojurescript.org/about/differences ). Perhaps he just noted the its size. A good chunk of the document lists things in common, not differences. The actual differences have nothing to do with dynamic typing and are de…

> - don't pretend the JVM and JS have identical runtimes when it comes to concurrency or numerics. Clojure is a language, not a platform abstraction. > - Emit efficient, optimally minifiable javascript code, at the cost of offering something less traditionally lisp-y when it comes to eval, macros, and other forms of code loading. Those are still possible, but some discipline is imposed. This is exactly the kind of th…

Post by joshlemer » Fri, Feb 12, 2021, 6:05 AM UTC

staticautomatic wrote: post #303

joshlemer wrote: post #142

Earlier quoted context omitted.

This is spot on! Way too often in Scala codebases, which tend to wrap IO calls in Future or similar is that you'll have chains of side effecting futures like readFromDb() .flatMap(x => doSomethingElse(x)) .flatMap(x => doSomethingElseAgain(x)) .flatMap(x => onceAgain(x)) And this all gets passed up the call stack to one generic thing that basically does nothing in the case of error, maybe logging it and that's it. It…

I dunno. You see the same pattern with chained class methods in Python and it suffers from the same exception specificity problems, but doing it is still a fair judgment call. Sometimes all you need to know is that there was an error in the chain. Like if an exception is raised by dataframe.transpose().to_dict().values() I don’t ask myself where in the chain the error occurred, I just think, “oh that’s weird why coul…

Post by brabel » Fri, Feb 12, 2021, 7:41 AM UTC

simias wrote: post #180

brabel wrote: post #140

Earlier quoted context omitted.

I am fairly certain the jury is out on this question: It's always better to write simple, almost dumb code that anyone can understand than to use advanced abstractions from category theory or whatever. Why? Because every single study or anedocte I've ever heard is like yours: adding complex abstractions to code do NOT make it more reliable. But they do make it much harder to modify, understand, and fix. FP tought us…

Finding the right level of abstraction is basically the one and only skill that matters for a software engineer IMO. I've got about 15 years of experience in programming and it's still something I'm actively working on. I disagree with the general take that "adding complex abstractions to code do NOT make it more reliable". Good use of abstraction makes code easier to write, easier to maintain and easier to extend. G…

Post by kjsingh » Fri, Feb 12, 2021, 8:31 AM UTC

mwcampbell wrote: post #20

I dabbled with Scala several years ago, but I've been using Kotlin for a JVM-based project and am happy with it. My main reason for choosing Kotlin is smoother interop with the JVM world. For example: - Scala adds an Option type, whereas Kotlin adds nullability checking for existing object types. - Scala has its own convention for getters and setters, whereas Kotlin automatically turns JVM getters and setters into pr…

Post by ud_visa » Fri, Feb 12, 2021, 9:27 AM UTC

joshlemer wrote: post #142

yw3410 wrote: post #105

Earlier quoted context omitted.

Yes, it is a side-effect - and does make the code impure; but it's an /exceptional/ flow like OOM, infinite looping, stack overflows which also break equational reasoning. My argument is that as a programmer you /choose/ the base lemmas which you're comfortable with - with an exception you're saying for a large swathe of your code, it will assume a lemma. When is /does/ break you get to point the finger at it with a…

This is spot on! Way too often in Scala codebases, which tend to wrap IO calls in Future or similar is that you'll have chains of side effecting futures like readFromDb() .flatMap(x => doSomethingElse(x)) .flatMap(x => doSomethingElseAgain(x)) .flatMap(x => onceAgain(x)) And this all gets passed up the call stack to one generic thing that basically does nothing in the case of error, maybe logging it and that's it. It…

  try {
    doSomethingElse(x)
    doSomethingElseAgain(x)
    onceAgain(x)
  } catch {
    ...
  }