161–170 of 178 posts
Earlier quoted context omitted.
It's not just the libraries, it's the tools, and those are a much bigger lift. I noticed it with Scala dropping Eclipse support and some users shifting to Kotlin; you couldn't have a clearer example of a strictly worse language, but JetBrains and Google are supporting it, and the difference between a good IDE and not is huge. And when I tried to step up and fix the Scala Eclipse plugin myself and saw what kind of byz…
Why can’t you just use IntelliJ CE? You won’t get some of the web programming features, but otherwise it’s perfectly capable.
It's never had working error highlighting for Scala. I filed a bug where using a parameterized member type was incorrectly highlighted as an error, the next version using a parameterized member types was never highlighted as an error. I filed a bug with a case that should have been an error wasn't, the next version my original bug was back. I gave up at that point.
Earlier quoted context omitted.
It's not just the libraries, it's the tools, and those are a much bigger lift. I noticed it with Scala dropping Eclipse support and some users shifting to Kotlin; you couldn't have a clearer example of a strictly worse language, but JetBrains and Google are supporting it, and the difference between a good IDE and not is huge. And when I tried to step up and fix the Scala Eclipse plugin myself and saw what kind of byz…
Kotlin is strictly worse if you value language features above all else. In that, there are several (several!) features it doesn't have.
Earlier quoted context omitted.
I think Jane Street is a big exception. It's like when PG espouses lisp. Back in the 90's[1] language ecosystems were very sparse. An ecosystem was a few big libraries and a syntax highlighter. Now stuff like IDEs, linting, packages, etc. have made people's standards quite high for ecosystems. On the flip side, back in the day languages like OCaml and Lisp had stuff other languages could only dream about. Functions a…
PG seems to be the only person who has built a successful business using Lisp. While thousands of successful companies are using C++/Java/.. etc. why do you think so few companies have succeeded with Lisp?
Earlier quoted context omitted.
It's not just the libraries, it's the tools, and those are a much bigger lift. I noticed it with Scala dropping Eclipse support and some users shifting to Kotlin; you couldn't have a clearer example of a strictly worse language, but JetBrains and Google are supporting it, and the difference between a good IDE and not is huge. And when I tried to step up and fix the Scala Eclipse plugin myself and saw what kind of byz…
> you couldn't have a clearer example of a strictly worse language... A language that does NOT have as many features and limits more what you can do is NOT a strictly worse language. You can never say a language is worse than another, anyway, in general: it's always relative to what usage you have in mind. Your apparent disdain for a language just on the basis of the language features shows that you have a lot to lea…
Earlier quoted context omitted.
> Also, as an aside that’s not really germane to the argument, it’s possible (and IMO preferable) to write code without using an IDE. It forces you to write code that’s broken up into contexts small enough to fit in human working memory No, complex programs by definition don’t fit into human working memory. Even with best practices, FP, whatever, function composition alone can’t always elevate the complexity to the r…
> No, complex programs by definition don’t fit into human working memory. If you write your code in the right way they don’t have to. That’s the point. You shouldn’t need to comprehend your entire program at once to work with it. > Even with best practices, FP, whatever, function composition alone can’t always elevate the complexity to the requirement’s level Function composition isn’t the pinnacle of abstraction. We…
Can you look at them in small chunks to understand what they are contributing to the result?
It looks like there is such a thing as complexity that is not functionally decomposable.
Earlier quoted context omitted.
> Also, as an aside that’s not really germane to the argument, it’s possible (and IMO preferable) to write code without using an IDE. It forces you to write code that’s broken up into contexts small enough to fit in human working memory No, complex programs by definition don’t fit into human working memory. Even with best practices, FP, whatever, function composition alone can’t always elevate the complexity to the r…
> No, complex programs by definition don’t fit into human working memory. If you write your code in the right way they don’t have to. That’s the point. You shouldn’t need to comprehend your entire program at once to work with it. > Even with best practices, FP, whatever, function composition alone can’t always elevate the complexity to the requirement’s level Function composition isn’t the pinnacle of abstraction. We…
I recommend you try working through some equality proofs in Coq, first with and then without coqtop / Proof General. I think you may change your mind about this rather rapidly. And many proofs get much more complex than that.
Earlier quoted context omitted.
I used to work at an OCaml company and it wasn't nearly as much of an issue as one might predict. You can (it turns out) build a very successful business even if there aren't a lot of existing libraries, or if the language lacks certain basic features like native multithreading (same with Python of course). I don't have a great model for why this isn't devastatingly expensive, but it's probably some combination of *…
Multi-threading can often be handed off to the OS in the form of just run more processes. So in most cases there is really no need for the language to handle it.
* extremely costly
* hard to make portable cross-platform
* hard to make secure (since data external to the process can't be trusted like shared-memory data can).
* requires constantly validating, serializing, and deserializing data, wasting developer time on something irrelevant to their problem domain
* adds a bunch of new failure modes due to the aforementioned plus having to worry about independent processes crashing
* fails to integrate into the type system of your language (relevant for something like Rust that can track things like uniqueness / immutability for you)
* cannot handle proper sharing of non-memory resources, except on a finicky case-by-case basis that is even more limited and hard to make cross-platform than the original communication (so now you need to stream events to specific "main" processes etc., which is a giant headache).
* Can cause significant additional performance problems due to things like extra context switching, scheduler stupidity, etc.
* Can result in huge memory bloat due to needing redundant copies of data structures and resources, even if they're not actually supposed to be different per thread.
Make no mistake here, when you're not just running multiple copies of something that don't communicate with each other, "just use processes" is a massive pain in the ass and performance and productivity loss for the developers using it, as well as hurting user experience with things like memory bloat. The only reason to go multiprocess when you have threads is in order to create a security boundary for defense in depth, like the Chromium does--and even they are starting to reach the limits of how far you can push the multiprocess model before things become unusably slow / unworkable for the developers.
I evaluated Pony 4 years ago, and walked away due to 2 technical issues: - garbage collection - no mechanism for synchronous access to actors We ended up building a C++ actor model, with it's associated headaches. Yes, we still have race conditions and some developers invoke the function directly instead of using messages, and yes, sometimes we will grab a locking mechanism to do synchronous access, but at the end of…
Earlier quoted context omitted.
> No, complex programs by definition don’t fit into human working memory. If you write your code in the right way they don’t have to. That’s the point. You shouldn’t need to comprehend your entire program at once to work with it. > Even with best practices, FP, whatever, function composition alone can’t always elevate the complexity to the requirement’s level Function composition isn’t the pinnacle of abstraction. We…
> If you write your code in the right way they don’t have to. That’s the point. I recommend you try working through some equality proofs in Coq, first with and then without coqtop / Proof General. I think you may change your mind about this rather rapidly. And many proofs get much more complex than that.