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 [email protected].
@SusanPotter I think I'd reply "I assume this promotion to a hybrid work position comes with a 35% payrise to cover the 12-15 hours travel time per week, and a company car or equivalent allowance? if you can draw the contract up I'll review it later this week"
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)?
"Laziness was the thing that initially brought us together, but I now think think that the important thing about it is not so much the lazy functional programming. (That's quite convenient and nice and modular. I do like it.) The really important thing was that it prevented us from making those deals with the devil, right, and forced us to be embarrassed for long enough to come up with the monad idea, right, so, now we know about that, you know, were we to do it all over again, I could even really imagine starting with a call-by-value language that was relentlessly pure. Does that make sense? But you would have the support for laziness. And indeed you know that we're all moving towards the middle there."
@mangoiv the point is that, being lazy, we could never be tempted to the dark side of impurity. Now there are indeed pure strict languages, but at the time of Haskell's birth every major language, even those that started out as pure, had become impure to add the ability to do input and output.
Hangman.hs:46:32: error:
* Couldn't match type '[Char]' with 'Char'
Expected type: Char
Actual type: String
* In the first argument of 'makeGuess', namely 'letterInput'
In the first argument of 'gameLoop', namely
'(makeGuess letterInput gs)'
In the expression: gameLoop (makeGuess letterInput gs)
|
46 | else gameLoop (makeGuess letterInput gs)
| ^^^^^^^^^^^
Elm-style:
-- Type mismatch ---------------------------------------------------- Hangman.hs
46 | else gameLoop (makeGuess letterInput gs)
^^^^^^^^^^^
Couldn't match type '[Char]' with 'Char'
Actual type:
String
Expected type:
Char
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.
I finally found a decent definition of free alternatives:
newtype Free f a = Free { alts :: [Free' f a] } deriving Functor
instance Applicative (Free f) where
pure = Free . pure . Pure
Free ps <*> q0 = asum $ map (`apL` q0) ps where
apL (Pure f) q = f <$> q
apL (Free' x p) q = Free $ pure $ Free' x $ flip <$> p <*> q
instance Alternative (Free f) where
empty = Free empty
Free ps <|> Free qs = Free (ps <|> qs)
data Free' f a = Pure a | forall x. Free' (f x) (Free f (x -> a))
deriving instance Functor (Free' f)
Exercise: why did I not write an instance Applicative (Free' f) and used deriving (Functor, Applicative, Alternative) via Compose [] (Free' f) to get the instances for Free?
It's amazing how complicated things get with simple-seeming semantics applied to plain text.
I am always curious whether these features could be developed/debugged/maintained faster in other languages... or if it's only because of Haskell that they can be shipped at all. I don't mean theoretically, obviously, but pragmatically, assuming equal personpower/funding.
@freemo I have similar worries about pragmatism if I stray of a well troden path. I find that's balanced by the joy of using / learning different languages.
If you can, just try it. If you hit a wall early on then pivot. Logic can be moved to another language.
Although niche, Haskell is a very solid and mature language, as you probably already know. 😁
@freemo The assessment in a functional programming course I teach is to write a command line interface (CLI) program in Haskell. I won't bore you with the specifics. But if you have a CLI you fancy writing, try using Haskell. (BTW optparse-applicative is your friend for CLIs.)
Every time someone raises a problem in the #Haskell ecosystem someone chimes in and says that #HaskellFoundation should hire someone full time to fix this. I guess over the last two years I have seen job ideas for at least 20 positions.
The Haskell Foundation only has money for (about) two employees right now and needs to refinance itself by sponsorship every year.
Its like everywhere in #OpenSource. Companies make profit, volunteers make things happen.
And a completely crazy talk by Ben Lynn about building a Haskell compiler based on an old concept from logic research. Just incredible fun to watch: https://www.youtube.com/watch?v=3kMvXXGXaws