131–140 of 342 posts
Great Analysis! I agree that languages are becoming more like Scala. I'm not sure about the JIT part though. Aren't many of the recent language success stories now about AOT compiled languages like Go, Rust and Swift?
Scala also has Scala Native which, well, compiles to native. It's not yet as polished as Scala JVM and Scala.js, but the plan is to make it so.
I definitely agree that many newer languages are strongly inspired by Scala, but I don't see a strong argument for why to choose Scala over one of a newer hybrid language. My own intuition is that these newer languages have had the benefit of being able to learn from Scala's mistakes. A lot of them have intentionally sacrificed some of the Scala's flexibility to be easier to learn and use. I found Scala to be an extr…
Scala has been in production use and getting bugfixes for longer than some of the newer languages have existed. I feel like a re-read of https://www.joelonsoftware.com/2000/04/06/things-you-should-... is warranted.
Earlier quoted context omitted.
I'm on exactly that kind of team now. They've been working on a very simple problem for several years now and have an enormous, sophisticated, but still buggy and unstable solution. They're really smart people, and they had to be extremely capable programmers to get this far, but the embarrassing question is, how would a team of mediocre developers have tackled this problem? They would have picked a mediocre language…
I am continually perplexed at the swallowing of exceptions in certain FP communities. Result types, Either et cetera make it extremely easy to swallow errors by flatMapping thoughtlessly losing the context of where they were - you typically /want/ the call stack when you hit into an exceptional flow.
For example, I find myself hating the Either type, because I feel like there is a socially established convention that one half of the Either is the type that matters, the value that you want, the value that is the point of the computation you're doing, and the other half is a garbage value that should never be directly handled. So I really feel like I should conform to the convention and reserve Either for cases where one of the possible types doesn't matter. But how often is it true that one side of the Either doesn't matter? People want me to encode success/failure in an Either type, but if I do that, are they going to treat failure with the care it deserves?
I often handle Either (and Option) using pattern matching when I feel it's important to give both code paths equal importance and equal visibility in the code, but people change it because flatMap is supposedly more idiomatic, and they believe that eliminating pattern matching from their code is a sign of sophistication.
I feel like this stems from a strong desire among FP folks for the happy path to be the only one visible in the code, and the non-happy path to work by invisible magic. Maybe there are some brilliant programmers who achieve this by careful programming, but there are people mimicking them who seem to rely more on faith than logical analysis. They just flatMap their way through everything and trust that this results in correct behavior for the "less important" cases.
I'm sorry that this turned into a bit of a rant, but I'm entirely fed up with it, and it accounts for a lot of what I dislike about the code I work with on a daily basis.
Earlier quoted context omitted.
I am working on an AI book using Swift. Yesterday in a meeting, my manager was asking why Swift. I compared it to Scala, but built on LLVM, and a rich CoreML and other library infrastructure. REPL + closures, very fast build times. I haven’t had much opportunity to use Scala, but I did take Martin’s Functional Programming with Scala course years ago, and that was great.
I wish swift were like Scala. It attempts to look and feel like it, but there’s one huge aspect of Scala that is missing in swift that basically makes swift a world apart, which is expressions vs statements. In Scala everything is an expression, meaning everything evaluates to some result even if that result is void. In swift everything is a statement. There’s a big difference because statements don’t return things,…
That sounds absolutely awful.
Earlier quoted context omitted.
>I was on a team building good old crud apps using monads, monoids, categories Here's the thing, if you look at a basic Spring crud app, you are also using Monads, Monoids, Categories, Traverse, etc. but you aren't expressing it in the type system. Seriously go look at modern Spring's flux stuff, it's all there minus the type classes. I've seen teams that tried to over engineer Spring, teams that tried to over engine…
> Seriously go look at modern Spring's flux stuff, it's all there minus the type classes. I don't use spring or plan to use it. Not quite sure why it needs to be looked up. What are you trying to say?
> 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…
I am a Scala programmer & think it's a great language. Here are some arguments for why not Scala: * Li's libs (os-lib, upickle, utest) have clean public interfaces, but most Scala ecosystem libs are hard to use, see the JSON alternatives for examples: https://www.lihaoyi.com/post/uJsonfastflexibleandintuitiveJS... * The Mill build tool looks a lot better than SBT, but seems like everyone is still using SBT * Scala mi…
I also like(d) a lot about Scala, but this is what ultimately led me to other languages. There's too many language features cranked together. This makes a) for a steep learning curve and b) exposes you to expert's code that is so dense and 'smart' that its a PITA to decipher what it does.
b) you'll encounter especially when incorporating libraries that are not fully stable, and you have to track down bugs in them (if only to know if your code is at fault, or the library's code).
I had this with Akka when it was just released. One line of code and 2hrs of debugging to determine what it did, and if it was faulty or not.
Damn, you submitted the link 5 times in 5 days, at what number did you plan to stop? https://news.ycombinator.com/submitted?id=lihaoyi
If I've said it once I've said it a thousand times: the day Scala kills sbt officially will be the day thousands of devs consider a return to it. Until then, I couldn't dare.
Perhaps the better way to phrase this is "the day Lightbend deprecates SBT and tells the community to use Mill", but I agree with the sentiment. Scala needs a new "official stack", hopefully Mill + utest/Munit + scalafmt (with opinionated settings). Scala 3 + SBT + Scalatest + whatever formatting isn't going to grab folk's attention.
Maybe so... but so do Python or Javascript. It seems to me some other languages have only one stack (rust: cargo, rustfmt...; the .net world as well). Does it make them better? (honest question). Then again, what's Java official stack?
Earlier quoted context omitted.
> Hard to win technical arguments with Scala geniuses that like using complicated language features. I was on a team building good old crud apps using monads, monoids, categories, combinators, effects cats, seamless and bunch of other nonsense that i've now purged from my brain. You could've easily mistaken our team for a programming language research group at a university. This is literally the number one reason i w…
I'm on exactly that kind of team now. They've been working on a very simple problem for several years now and have an enormous, sophisticated, but still buggy and unstable solution. They're really smart people, and they had to be extremely capable programmers to get this far, but the embarrassing question is, how would a team of mediocre developers have tackled this problem? They would have picked a mediocre language…
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 that unconstrained mutable state is very bad, and that has helped us immensely in the mundane languages of the world (Java, C#, C++, Go). But I think it's time to learn the other lesson from FP: overly complex abstractions are also very bad and should NOT be used willy nilly as they simply have a very low or negative cost-benefit.