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
@Amirography oh well I have to say that to me C doesn't simply have tooling. There are some things, but I've never seen a C project actually effectively managing dependencies and doing linting the proper way, for example.
Taking this absence into account of course makes Haskell look like the cool kid on the block.
Actually the thing that irked me a lot at the time wasn't Cabal itself or Stack for example, but the fact that you had to know by heart which extensions for GHC you were using.
@Amirography@cjk I think SPJ's perspective on this will probably have changed a bit. In this talk, he's basically reflecting on the early history of Haskell, and it's certainly been one of the principles of Haskell evolution not to get dragged into maintaining compatibility too early.
I think there's much more emphasis on stability now. The Haskell Foundation has a Stability Working Group. For user-facing changes to GHC, there is a clear GHC proposals process that has to be adhered to. Nevertheless, there are still ongoing problems: one of the main problems is that the base package, which provides many of the most fundamental functions, is locked to GHC, so if you upgrade GHC, you have to upgrade base. Other libraries then depend on certain versions of base and are incompatible with others. This can lead to scenarios where a security fix in one package you need goes along with a dependency on a later base, which then means you have to upgrade GHC, which then means you have to make other changes. This sort of stuff isn't great. It's also not trivial to fix, although it's clearly identified as a problem, and people are working on improving this over time.
Another potentially annoying problem is that lots of things are sensitive to compiler versions (also tooling such as HLS). This is unlikely to be solved ever, but can be worked around by other tooling such as Nix relatively effectively. But the underlying point is that GHC has an aggressive optimiser including all sorts of cross-module optimisations, and that means that internal formats change essentially all the time.
@tshirtman You haven't spoiled anything - I'd seen this in others' solutions already, but couldn't quite believe it so was choosing to believe I'd missed their offset calculating bits
Cheating is that this information on the cycle periods being what they are is vital to a simple solution but not easily obtainable...
@penwing yeah, i've seen (and you probably as well) people use dot to produce graphs of the paths, making it slightly clearer what's happening, but getting the idea to do that? I fear there might be more data exploration in the future, rather than relying entirely on problem description.
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?
@aeveltstra For personal use I jump between Python and JavaScript. (Sorry not sorry).
Design wise, Ruby is beautiful.
I've learned a little bit of Go, Lua, uxn/Forth (?) and others but I come back to interpreted language with a dynamic type system because I love Rapid Prototyping too much.
I feel like it encourages me to write better documentation and tests to compensate for the compile step.
With my background in math I should have looked into Haskell and Lisp but haven't done so.
@aeveltstra For me the biggest issue is finding bugs at compile time: I despise Python, it's even worse to debug than "proper" C. I simply cannot accept syntax or other weird type errors at runtime.
So it's mostly Rust (for serious stuff), Go (basically just a better Python), Kotlin (for JVM), C (for exploits/PoC) and Haskell/PureScript/Clojure (when the libraries around it allow it). I dislike about Clojure and anything Scheme/Lisp that typing isn't as native as it could be, as strict, explicit types usually help me catch errors early. I spend a lot of time fighting the type checker, but if I reflect: All those errors would have been undebuggable without.
I find Haskell/PureScript pretty easy to learn, it's simply taught pretty badly IMHO. Most of the time I don't really think about the monadic aspect of Monads.
Outside of the language aspects, I love the tooling around Rust and Clojure. Also, Haskell's Hoogle is awesome.
Since this is a very new community, let's take a moment to introduce ourselves in this thread. Please share your interests and what you are working on!
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.
In this episode, Matti and Wouter are joined by John Hughes. John is one of the authors of the original Haskell Report and talks about why functional programming matters, the origins of QuickCheck testing, and how higher order functions and lazy evaluation is the key that makes functional programming so productive, and so much...
The GitHub repo of the #haskellbasement and foundation packages was just archived, while it currently has 3764 indirect reverse dependencies including cryptonite, pandoc, and accelerate. I don't know why and I don't know what will happen now, but I am concerned.
Also, I'm concerned that this goes unnoticed. Hackage does not currently show maintenance status very well, so people might think these packages are still suitable to use in new projects.
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.
@rml yes basically Development of a Haskell-EDSL Optimized for Open-Source Hardware (read risc V, and networked) , but I am realizing , my hsl may lie anywhere in the spectrum of nix and scheme ( given delay and force , vs let-rec of nix)
basically here's the updated view , after feedback of some learned haskell, nix folks
@mangoiv@maralorn Yes, I agree with this view. I don't think Maybe is the right analogy. The MVar being empty is not a case you have to explicitly deal with, it already has a behaviour attached to it (blocking). Regarding the missing entry in the square, isn't that just an IORef?
Yeah, It's kinda IORef but I thought that doesn't count because it has less concurrency guarantees.
But I think I get now why MVars are much more useful. I have even used TMVars myself as locks when the action I wanted to do with it contained effects.
This was already featured in the Weekly News a couple of weeks back, but I think maybe it deserves it’s own thread. I’ve tried to explain this approach to some people before, but I think this article does a much better job than I have....
@clementd@amyfou
A pair of stout field dogs! A church friend and her daughter are Willow Run Vizslas and have shown at Westminster show in NYC. Ania was best junior handler with a English cocker veteran. Rachael’s hounds are dual track conformation and trials dogs.
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)?
Non-deterministic behaviour in a specification can be a headache for testing. This updated post explores the non-determinism in the JSONPath RFC 9535, describes how the Compliance Test Suite is being upgraded to deal with non-determinism, and shows how non-deterministic tests can be generated automatically. There's also an "explosive" challenge for Haskell programmers.
Found a couple of trivial optimisations of my Haskell code which sped it up by a factor of over 20,000 (for the "explosive" example mentioned in the above post). That's sufficient for now. 😉
"Sadly, the hardware of the time often wasn’t powerful enough to make use of the solution. But today’s processors can easily manage the demands of Haskell and other purely functional languages."
Even today, software that requires performance is not written in purely functional languages like Haskell.
Maybe because purely functional languages are not designed with hardware in mind?
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
@leftpaddotpy spark# is state# passing so you can explicitly spawn a spark as a monadic operation in io or st which feels natural. on the other hand, par's purity is an undesired burden because you now have evaluation order to worry about and litter your code with pseq. the entire "Strategy" thing and "Eval" monad in the parallel package is a huge distraction in the same sense
#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
#AdventOfCode Day 22 done in #Haskell. After the rather weird previous two days where the exact nature of the input played a large role, this was finally a rather straight-forward and enjoyable programming task again.
@aoanla@kosmikus yes this is my first year too, and funny you should mention that - some of the people on the work leader board have GitHub repos and I can see those extra years. And their solutions often start by importing helpers as you describe. I had actually initially planned to use this as a chance to learn a new language (lisp) but that’s just a step too far for me now!
@mindshoot@aoanla It's the first year I'm really doing it as well, in all the previous years I've usually given up after just a day or two. Overall, yes, it's been costing time, but I'd say I've also been enjoying it and I've been learning quite a few things (using new libraries, writing algorithms I usually rarely end up writing), and the more annoying parts have been comparatively rare.
I would say that there's a danger though to let it become a massive time sink and not enjoying it at all anymore. It somewhat sounds like you may be in that situation. Don't let peer pressure get to you. I totally understand lack of time. If it becomes a chore, it's probably better to just let it be ...
There are plenty of descriptions of Haskell's do notation as syntactic sugar for stringing together sequences of operators such as >>=.
There are also "laws" that define the semantics of the do notation.
But I haven't found any decent description of how to use do notation as if it was a first class language construct. That would be especially useful for beginners.
@underlap I am not sure you can get very far with that approach? The semantics of do notation is defined in terms of return / pure and (>>=). So in order to understand what a do block means for a concrete monad, you have to look up the definition of the Monad and superclass instances, and be able to relate that to what the do-block says. So you basically have to be able to do the desugaring in your head.
Treating do-notation as first-class could still be useful if you limit yourself to one fixed type, say IO where the definitions are built-in anyway. But while I agree in principle that introducing IO before talking about monads (at all or in general) is the correct order, even for IO I am not sure that introducing do without talking about its desugaring helps much.
"""
Let m be a monad, and a be a type. The do keyword allows you to define a value of type m a in an imperative style: it starts a context where you can write code as a sequence of statements.
In this imperative mini-language, you can bind names to constants (no variables allowed!) in two ways:
If the value you are binding can be deduced from constants already in scope, just use the let keyword.
If the value you are binding is the result of a monadic action, use <- to perform the action and get the resulting value. If the statement is of type m b, the type associated with the name is now b.
Any name bound in this way can be used in the statements that follow it.
You can also perform a monadic action without assigning its result to anything (just write the monadic action as a separate statement).
Finally, the last statement must be the result of your monadic action, i.e. a value of type m a. Just write the action as your last statement.
"""
I feel like it's a pretty simple thing to write, and that most Haskell texts/courses feature that explanation, so I probably misunderstood your request 😅
@someodd, here's a few thoughts on #haskell packaging/distribution:
Support the widest range of GHC versions, deps, and all related tools you can reasonably manage, reducing unnecessary friction.
Get your packages and their dependencies into Stackage nightly and keep them there. From there they will trickle into Stackage LTS, which is a starting point for many packaging systems.
AFAIK, there's not an easy way in Haskell to inspect at the type level what type a field has in a record.
What I mean is that that there doesn't seem to be a type family like
type FieldType :: Type -> Symbol -> Type
that we could invoke in ghci like
:kind! FieldType Person "age"
Why would I want this? For libraries like servant and rel8 that use parameterized records where the types of the fields vary heavily with the type parameter.
