51–60 of 154 posts
If you've had a bad experience with a piece of tech and draw a broad conclusion, I think it's reasonable if unfortunate that it left a bad taste in your mouth. But I also think there's a brighter picture to paint :)
Earlier quoted context omitted.
GHC can produce native libraries just like C or Rust.
But you carry around a runtime with managed objects that can’t be freely traded across the boundary to C libraries.
When it comes to moving things across FFI barrier, that is also very possible as there are all kinds of types (including stable pointers) in the Foreign.* modules that map onto C types.
Earlier quoted context omitted.
30 ish years is young for a programming language now?
Haskell is the youngest language that isn’t derivative.Monads for IO weren’t being seriously used until the late 90s. All the imperative C derivative languages are much older.
It comes with C, JS, and Haskell interoperability, and it's implemented in Haskell, but the heart of the language is its visual representation. I have personally never seen anything like it before.
And, recognizing that worse often wins, maybe we should consider the possibility that what we were categorizing as worse, was actually solving a different, more concrete problem.
Earlier quoted context omitted.
Did you just call JS-lovers and Haskell-lovers cognitively defective?
It's not an uncommon meme that programmers and mathematicians possess a weird twist in the mind that allows them [in the strong form of the meme] to do, and [in the weak form of the meme] to enjoy doing, what they do. If you grant that, then it's a small step to admitting the existence of different sub-twists that incline you towards different parts of the abstract space. If you don't grant that, then consider it a r…
I suspect that part of the success of Go is simply because its libraries are heavily used. You know that the library is serving a zillion requests a second in Google data centers. Major bugs have probably been found by now. Go has one solidly debugged library for each major function. Some other languages have a dozen half-debugged partly finished libraries. I once discovered that the all-Python connector for MySQL failed when you loaded more than a megabyte or so with LOAD DATA LOCAL. It passed the unit test, but clearly nobody was using it in production.
There's an intermediate stop between imperative programming and functional programming - single assignment. Variables are initialized once and are then immutable. This is becoming the default in newer languages such as Rust and Go - if you want mutability, you have to ask for it. This gives you the immutability advantages of functional programming without the run-on sentence syntax. Also, results have names, which improves readability, and give you something to display when debugging.
My two cents: because, more often than not, worse is better. And, recognizing that worse often wins, maybe we should consider the possibility that what we were categorizing as worse, was actually solving a different, more concrete problem.
I think the simple answer is "yes". It doesn't matter how much more "productive" something is if the vast majority of people simply aren't capable of learning it (or learning to use it well enough or doing it in a reasonable amount of time or whatever).
He does go on to point out:
> Though this question is more complicated than you think
And suggests one read his more detailed treatment of the question, including what I found most relevant, which is a more nuanced treatment of the notion of productivity, having to do with labor costs, fungibility of that labor, market competition, and overall limited resources.
https://pchiusano.github.io/2016-02-25/tech-adoption.html
https://news.ycombinator.com/item?id=17114935
I would expect that any technology that can be classified as sufficiently exotic is viewed as a huge risk, one not worth taking, by larger companies, which has traditionally included obsolescent tech and bleeding-edge/unproven tech, but easily includes a language that's too hard for the average programmer learn.