Haskell. Its tool chain and version management pose significant hurdles, admittedly.
While the language itself inspires wonder, I must confess that the tooling falls short when measured against the high standards set by contemporary languages like Go and Rust.
In all fairness, we should recognize its historical context, where Haskell competed with C. From that perspective, its advancements were indeed commendable, and it's miles ahead of the rather "horrible" tooling in C. #Haskell
I think something the scheme community could learn from Haskell is to lean-in on it's prestige. I see so many people post about how they were never able to figure out how to use scheme in any practical way, and most schemers I've spoke to said it took them about a year to get really compfortable. But I think the #scheme community has traditionally advertised it as "so easy, you can learn it in an afternoon!", and so people, often times already coming from some other #lisp like #clojure, expect to be able to just pick it up, and when they fail to they think the language is lacking. But nobody comes to #Haskell with such expectations, and the Haskell community never advertised it as super easy and quick to learn. In my experience, Haskell has always been sold as "takes time to learn, but is worth it".
I may bitch and gripe a bit about the insane learning curve of programming languages like #haskell... but I cut my teeth on #javascript and #php : I've seen worse. Of all the languages I've used, my favorite by far is #python, but only for processing. What's yours, and why?
To be fair, I think Haskell will continue to fill the niche it filled ~10 years ago, around the time it started to get mainstream hype. Small teams of skilled devs delivering robust products that would normally require much larger teams to maintain will continue to prevail. Purely functional lazy programming was never bound for world domination in an economy which is antagnostic to curiosity, creativity and truths.
On the other hand, I have the feeling that we're going to see more and more Haskellers-turned-Rustaceans come to realize that #Rust does little to alleviate the primary barrier to Haskell's wider success -- fast and predictable turnaround time for projects developing cutting-edge technologies -- and will wind up going the same route as some major Haskell projects such as #Unison and #Idris have in recent years, which is to try #Chez Scheme, only to discover that it allows them to release blazing fast functional programs on a generic foundation where major breaking changes are practically non-existent, providing incredible flexibility while significantly reducing dependencies by dint of the ad-hoc tooling that falls out of the bottom of #scheme. Not to mention the joys that come from near-instant startup times, some of the fastest compile time you've ever encountered, fully-customizable interactive development and a surgical #debugger that rivals Haskell in scheer fun. Yesterdays naysayers will become tomorrow's enthusiastic bootstrappers. Or a at least a boy can dream.
That said, in all seriousness I don't think Scheme will ever reach the heights of Haskell's moderate commercial success. But I do think that projects built on Scheme, like Unison, will get a leg up and eventually surpass it, and interest in #lisp will only grow.
Rant: I personally find #OCaml to be in a weird space where you don't have as great a type system as Haskell's, and don't even get safety from arbitrary mutation. Atleast #Rust gives me things that #Haskell doesn't.
A strict Haskell, with some warts removed would go a long way towards fixing Haskell's image problems. #PureScriptis that Haskell, but it gets dismissed as something solely for the web. A mature native backend for PureScript would be amazing as well.
Over a few days I wrote a bunch of #C++, #Rust, #Haskell, and #Python. Something I don’t get is that while I might say that Python has the most extensive ecosystem, it seems to have the worst tooling in terms of package management and LSP features (clangd, rust-analyzer, hls, and pylsp). How does that happen? Why don’t the economics that plow programmer hours into Python libraries raise the level of its tooling?
Coding in #JS again (need to, SDK to $service only available in JS) and I'm frequently using #hoogle to look up what kind of function I'd use in #Haskell (foldMap, unzipWith, ...) and then looking for JS packages that implement them.
You know that #BigTech looses millions of $ through their deployed #AI systems, right? You can expect a much higher price for using their #LLMs in the future - be it your privacy or your money.
So instead of learning proompt engineering, why not do something more useful and invest your time into learning a new #ProgrammingLanguage:
#Rust - a language empowering everyone to build reliable and efficient software
#Haskell - a purely functional language that changes the way you think
I have just been requested to commute three days a week 135 miles away each way from my home (I have not moved) to an office I was never required to attend before the pandemic starting end of September.
If anyone needs remote product/infrastructure/platform engineering or backend developer who has 15 years cloud deployment experience and data center to cloud migration experience, email me on spotter@referentiallabs.com.
You don't need side effects for I/O. Purely functional languages like #Miranda and #Haskell 1.0 got along just fine with dialogues for I/O, although whether they could be feased is another matter. But 'side effect' is short for 'side effect of evaluation'; i.e., the computer calculates the value of this expression and oh by the way it does this I/O while it's doing that (as a side effect). The side effects of a drug are everything the drug does that's not its intended purpose; the side effects of an expression are everything the code for that expression does that's not 'calculate the value'. So you don't need side effects to do I/O. Just make the I/O part of the value and have the computer calculate the value, then do the I/O it calculated.
possibly unpopular opinion: it is easier to learn software architecture in #PHP than in #Haskell, since the former requires much more discipline and attention than the latter.
Someone once said that laziness is what kept #Haskell pure, and that's the actually relevant feature. This makes we wonder: will theorem proving languages like #lean, where logical consistency is what keeps them pure, deliver the same elegant experience, while avoiding some downsides of laziness (complex runtime, complicated performance characteristics)?
Sounds like #Typescript people are asking for TypeRep support?
A lot of people in this thread seem to think that requires some sort of a runtime reflection, but it's all compile time. #Haskell as well as #PureScript erase types at compile time and TypeReps work well there.
> Banana-RDF contains a more general library to work with RDF from Scala. It allows different underlying implementations like Jena and Sesame. A long term project will be to unify our work with that library.
ok. sparks is indeed a nice way to get work stealing nested parallelism for free in #haskell, as long as you work with spark# directly and don't use par, pseq or anything built upon these combinators
#RuinAFilm but programming language names:
Ghost in the #Haskell #Perl Is For Heros
In The Name Of The #Java
Schindler's #Lisp
Star Wars: The #FORTH Awakens
Manchester By the #C
The Truman #Go
Bringing Up #Ruby
Anyone get any other good ideas? #Puns#Joke