I learned Haskell in just 15 years(duckrabbit.tech)
duckrabbit.tech
I learned Haskell in just 15 years
https://duckrabbit.tech/articles/learning-haskell.html
236 comments
Yes - the value of functional programming isn't that working in OCAML, or F#, or Haskell is 10x as productive as other languages. But that it can teach you worthwhile lessens about designing software that apply equally to imperative languages.
Modelling the business domain, reasoning and managing side effects, avoiding common imperative bugs, these are all valuable skills to develop.
F# is a great language to learn, and very approachable. Worst part about it is interacting with antiquated .NET API's. (I can't believe the state that .NET support for common serialization formats is still in...)
Modelling the business domain, reasoning and managing side effects, avoiding common imperative bugs, these are all valuable skills to develop.
F# is a great language to learn, and very approachable. Worst part about it is interacting with antiquated .NET API's. (I can't believe the state that .NET support for common serialization formats is still in...)
> Yes - the value of functional programming isn't that working in OCAML, or F#, or Haskell is 10x as productive as other languages.
This is not true in my personal experience.
As has been famously said (paraphrased): Functional programming makes tough problems easy and easy problems tough.
In other words the value of functional programming depends on your domain.
This is not true in my personal experience.
As has been famously said (paraphrased): Functional programming makes tough problems easy and easy problems tough.
In other words the value of functional programming depends on your domain.
It’s only tough to change your way of thinking. Most people making the switch find it tough because they are trying to find imperative techniques to do something in a functional way and struggling because they can’t find an if else statement or a for loop. But if you were never taught to think in terms of conditional branching or looping indexes you’ll save a lot of time.
Exactly. I've long held the sentiment, that pure functional programming is easier than imperative programming. The only hard part, is switching from an imperative mindset.
Maybe my phrasing is not clear - I meant that these languages are indeed not significantly more productive.
By what measure? Haskell can be a huge productivity multiplier. The standard library is built upon many powerful, unifying and consistent mathematical abstractions. For example, there is almost no boilerplate to write for any traversal, mapping, error handling etc. The average Pythonista simply has no idea what they are missing. But Haskell doesn't have anywhere near the third party ecosystem of Python, so is less productive by some measures.
But (and I agree with the GP) they are. They are overwhelmingly more productive, in a way that you often can't even compare quantitatively.
They are also a lot less productive. It depends entirely on what you are doing.
They are also a lot less productive. It depends entirely on what you are doing.
> easy problems tough.
That needs a qualifier: it can make easy problems tough if you're not familiar with how to solve them in a functional context.
A big part of that is because smart people have already solved the tough problems and made them available as language features or libraries.
That needs a qualifier: it can make easy problems tough if you're not familiar with how to solve them in a functional context.
A big part of that is because smart people have already solved the tough problems and made them available as language features or libraries.
> That needs a qualifier: it can make easy problems tough if you're not familiar with how to solve them in a functional context.
All problems are easy if you are familiar with how to solve them. Unfortunately it's part of the problem to find out how to solve them, and that can be unusually hard in case of functional programming. Like solving something with recursion instead of loops + states. There is a reason cookbooks use loops not recursion.
All problems are easy if you are familiar with how to solve them. Unfortunately it's part of the problem to find out how to solve them, and that can be unusually hard in case of functional programming. Like solving something with recursion instead of loops + states. There is a reason cookbooks use loops not recursion.
Not really, certain problems are just inherently harder to express in a purely functional way than they are in an imperative way (and the reverse is just as true). For example, computing a histogram is much simpler in imperative terms (keep an array of histogram values, go through the original list, add 1 to the array element corresponding to the current element in this list) than in a purely functional style, especially if you need a somewhat efficient implementation.
My favorite example of this is implementing quicksort. It's significantly easier in C than it is in Haskell.
My favorite example of this is implementing quicksort. It's significantly easier in C than it is in Haskell.
> My favorite example of this is implementing quicksort. It's significantly easier in C than it is in Haskell.
Oh please, what's so hard about
folks, take that with a big ol /s, you would never want to actually use that algorithm. But the real deal isn't all that awful: https://mmhaskell.com/blog/2019/5/13/quicksort-with-haskell
Oh please, what's so hard about
qsort :: Ord a => [a] -> [a]
qsort [] = []
qsort (p:xs) = qsort lesser ++ [p] ++ qsort greater
where
lesser = filter (< p) xs
greater = filter (>= p) xs
folks, take that with a big ol /s, you would never want to actually use that algorithm. But the real deal isn't all that awful: https://mmhaskell.com/blog/2019/5/13/quicksort-with-haskell
I know you're being sarcastic, but even in this linked-list quicksort, it could be made more efficient. By defining lesser and greater separately, you're traversing the list twice. You could compute them at the same time by changing those last two lines to this:
https://hackage.haskell.org/package/base-4.20.0.1/docs/Data-...
where
(lesser, greater) = partition (< p) xs
https://hackage.haskell.org/package/base-4.20.0.1/docs/Data-...
Heh, I've used some version of partition in my TS/JS code ever since underscore.js. But "Haskell Quicksort" is basically a code meme now, and I didn't think to optimize it (though I think the original was a one-liner using list comprehensions)
Arguably the issue with "quicksort in Haskell" is not that it's "hard" to implement, but rather it defeats the whole purpose of using a "purely functional" language.
The pragmatic way to look at Haskell is not that it's purely functional, but rather, you could write <del>imperative code</del> Monads if you wanted, and that gives a "functional by default" environment, whereas most imperative languages default to mutable objects etc that are not friendly to functional-style programming.
But then the more modern languages are catching on with immutable by default variables etc. so in the end the differences between newer languages may not be that great after all...
The pragmatic way to look at Haskell is not that it's purely functional, but rather, you could write <del>imperative code</del> Monads if you wanted, and that gives a "functional by default" environment, whereas most imperative languages default to mutable objects etc that are not friendly to functional-style programming.
But then the more modern languages are catching on with immutable by default variables etc. so in the end the differences between newer languages may not be that great after all...
Well, I'd say using an entirely different collection type than the rest of language (STArray instead of [a]) is already a big complication. It also ends up being more than double the size of the Java code. And, as the author admits, it's actually even slower than the original not-quicksort implementation above, because it actually has to make a copy of the original list, and then return a copy of the mutated array.
So, one of the best sorting algorithms ever devised is not actually usable to sort a [a] in Haskell... I maintain this is a good example of making an easy problem tough.
So, one of the best sorting algorithms ever devised is not actually usable to sort a [a] in Haskell... I maintain this is a good example of making an easy problem tough.
> I'd say using an entirely different collection type than the rest of language (STArray instead of [a]) is already a big complication
Haskell uses many different collection types, just like any other language. Why not?
> it's actually even slower than the original not-quicksort implementation above, because it actually has to make a copy of the original list, and then return a copy of the mutated array.
Sure, but it could also not do that, if callers are happy to provide a mutable array, just like any other language ...
> one of the best sorting algorithms ever devised is not actually usable to sort a [a] in Haskell
Indeed! One of the best algorithms for sorting a mutable array can't be used on an immutable data type, just like any other language ...
None of this invalidates your original claim that "It's significantly easier in C than it is in Haskell" of course.
Haskell uses many different collection types, just like any other language. Why not?
> it's actually even slower than the original not-quicksort implementation above, because it actually has to make a copy of the original list, and then return a copy of the mutated array.
Sure, but it could also not do that, if callers are happy to provide a mutable array, just like any other language ...
> one of the best sorting algorithms ever devised is not actually usable to sort a [a] in Haskell
Indeed! One of the best algorithms for sorting a mutable array can't be used on an immutable data type, just like any other language ...
None of this invalidates your original claim that "It's significantly easier in C than it is in Haskell" of course.
quicksort2 has a very reasonable constraint of Array, it's the helpers that use the STArray implementation. I suspect it wouldn't be hard to port to MArray, though I don't know that it would perform any better (maybe avoiding some copies since MArray is actually usable outside of runST). I also suspect the overhead of the copies pays off with larger lists given the lack of space leaks compared to the naive algorithm. Some benchmarks of different-sized lists would have been nice.
I'm not a cheerleader for Haskell, it's not the most appropriate language for every job (certainly not for quicksort). But some folks suddenly become hyper-optimizing assembly programmers whenever anyone has the thought of porting a sql crud app to another language... Horses for courses and all that.
I'm not a cheerleader for Haskell, it's not the most appropriate language for every job (certainly not for quicksort). But some folks suddenly become hyper-optimizing assembly programmers whenever anyone has the thought of porting a sql crud app to another language... Horses for courses and all that.
Absolutely! Any beginner can readily combine the catamorphisms and anamorphisms in `recursion-schemes`, or use the ready-made hylomorphisms for common tasks such as setting a value in a data structure. What could be simpler? /s
https://wiki.haskell.org/Zygohistomorphic_prepromorphisms
https://wiki.haskell.org/Zygohistomorphic_prepromorphisms
They have played us for absolute fools.
> makes tough problems easy and easy problems tough
And because of mutual recursion, that means that tough is easy (and easy tough). In other words, if we call the class of tough problems T and easy problems NT, we have T==NT, given FP.
And because of mutual recursion, that means that tough is easy (and easy tough). In other words, if we call the class of tough problems T and easy problems NT, we have T==NT, given FP.
So you’re saying that it does make you 10x as productive?
[deleted]
What easy problems are tough in F#? I’ve been using it for writing random scripts and as a Python replacement.
It's an overgeneralisation.
If you try and turn F# into Haskell at home you may run into that problem.
F# is functional first language so if an object oriented or procedural solution is the right call the options right there when you need it.
If you try and turn F# into Haskell at home you may run into that problem.
F# is functional first language so if an object oriented or procedural solution is the right call the options right there when you need it.
Writing recursive descent parsers in F# is a lot of fun with ADTs and pattern matching.
How do you “Hello World” in a functional language? Doesn’t it have side effects?
Yes, and AFAIK, you're pretty much free to cause side-effects in functional languages; it's just a bit awkward and somewhat discouraged. It's kind of like how C still has goto, yet it's still a structured programming language.
Even in Haskell, which tries to control side-effects more, it's not hard; it's just that it's stuck with an "IO" annotation. Any function that calls an IO function also becomes an IO function; it's infectious.
Even in Haskell, which tries to control side-effects more, it's not hard; it's just that it's stuck with an "IO" annotation. Any function that calls an IO function also becomes an IO function; it's infectious.
main :: IO ()
main = putStrLn "hello, world"There's some real confusion about what "functional" means, because it depends on who's speaking. Writing _exclusively_ pure functions is a Haskell thing. A much looser definition of the functional style would be to say that you mostly write pure functions over immutable data, but when you have to actually do a side effect you write a procedure that talks to the outside world and go on with your day. If you go digging in this site's archives from about ten years ago, I recall numerous debates about what constituted functional programming, and whether the latter counts at all. But if we _are_ talking about Haskell, the answer to your question is obviously "Monads."
It has an effect. Whether it's a "side effect" depends on how we've defined that.
One way of viewing Haskell is that you are lazily constructing the single composite "effect on the world" called main.
Threads complicate this but don't completely destroy the model.
One way of viewing Haskell is that you are lazily constructing the single composite "effect on the world" called main.
helloWorld :: IO ()
Threads complicate this but don't completely destroy the model.
Hot take of the day: you learn that with imperative programming just as well.
I familiarized myself with fp to the point of writing scheme and haskell around 15 years ago. Read the classics, understood advanced typing, lambda calculus and so on. The best “fp” I’m using nowadays is closures, currying in the form of func.bind(this[, first]) and map/filter. Which all are absolutely learnable by the means of closures, which are useful but I can live without. Sometimes not having these makes you write effing code instead of fiddling with its forms for hours.
Still waiting for the returns from arcane fp-like code I produced earlier. Cannot recognize nor understand none of my projects in this style that I bothered to save in vcs. Imperative code reads like prose, I have some of it still in production since 2010.
These FP talks are disguised elitism imo (not necessarily bad faith). Beta reduction and monadic transformers sound so cool, but that’s it job-wise.
I familiarized myself with fp to the point of writing scheme and haskell around 15 years ago. Read the classics, understood advanced typing, lambda calculus and so on. The best “fp” I’m using nowadays is closures, currying in the form of func.bind(this[, first]) and map/filter. Which all are absolutely learnable by the means of closures, which are useful but I can live without. Sometimes not having these makes you write effing code instead of fiddling with its forms for hours.
Still waiting for the returns from arcane fp-like code I produced earlier. Cannot recognize nor understand none of my projects in this style that I bothered to save in vcs. Imperative code reads like prose, I have some of it still in production since 2010.
These FP talks are disguised elitism imo (not necessarily bad faith). Beta reduction and monadic transformers sound so cool, but that’s it job-wise.
> These FP talks are disguised elitism imo (not necessarily bad faith). Beta reduction and monadic transformers sound so cool, but that’s it job-wise.
They may be disguised mathematics. People are into math because it is neat / elegant / cool. So they study it regardless of whether it has a practical use or not.
They may be disguised mathematics. People are into math because it is neat / elegant / cool. So they study it regardless of whether it has a practical use or not.
Some programmers have serious math envy. This can be good if they are self aware about it and keep it in check, because it makes them better programmers. Otherwise they can a pain to work with. Seniors should be people that have dealt with this aspect of their own talent, not juniors who are promoted in spite of or because of it
I commonly implement things in an imperative style as a quick hack, then if it gets use I translate it into a more functional style. It kind of just happens as I clean it up and refactor during revisits.
It might be a matter of taste, but I enjoy code built with functional abstractions that allow neat composable data flows and some caches loitering around. I find it also helps when adding UI. Sometimes performance could be better with mutation, but when I'm at that point I've already spent much more time tuning the thing with caches.
It might be a matter of taste, but I enjoy code built with functional abstractions that allow neat composable data flows and some caches loitering around. I find it also helps when adding UI. Sometimes performance could be better with mutation, but when I'm at that point I've already spent much more time tuning the thing with caches.
In theory, you could pick up your one language, say, Java, and through the course of a normal career learn everything necessary to program in that language in the best possible way.
In practice, it's a pretty well-known phenomenon experienced by many skilled programmers that being forced into different styles by different languages results in learning things that you would only have learned very slowly if you had stuck only to your original language. To be concrete about the "very slowly", I'm talking time frames of your entire career, if not your entire life and beyond. It would be a long time programming in Java before you discover the concept of something like "pure functions" as a distinct sort of function, a desirable sort of function, and one that you might want organize your programming style around.
Of course, having heard of the concept already, we'd all like to fancy ourselves smart enough to figure it out in less than, say, three decades. But we're just lying to ourselves when we do that. Even the smartest of us is not as smart as all of us. You are not independently capable of rediscovering everything all the various programming communities have discovered over decades. If you want to know what even the smartest of us can do on their own without reference to decades of experience of others, you can look into the state of computer programming in more-or-less the 1980s, 90s if you're feeling generous. I think we've learned a lot since then, and the delta between the modern programmer and a 1980s programmer certainly isn't in their IQ or anything similar, it is in their increased collective community experience.
By getting out into systems that force us to learn different paradigms, and into communities that have learned how to use them, we draw on the experience of others and cover far more ground than we could ever have covered on our own, or in the context of a single language where we can settle into a local optima comfort zone. Jumping out of your original community is kind of an annealing process for our programming skills.
"The best “fp” I’m using nowadays is closures, currying in the form of func.bind(this[, first]) and map/filter."
That is really not the lesson about software design that FP teaches, and blindly carrying those principles into imperative programming is at times a quite negative value, as your experience bears out. FP has more to say about purity of functions, the utility of composition of small parts, the flexibility of composition with small parts, ways to wrap parts of the program that can't be handled that way, and providing an existence proof that despite what an imperative programmer might think it is in fact possible to program this way at a system architecture level. I actually agree 100% that anyone whose takeaway from FP is "we should use map everywhere because they're better than for loops and anyone who uses for loops is a Bad Programmer" missed the forest for the leaves, and I choose that modification of the standard metaphor carefully. I consider my programming style highly influenced by my time in functional programming land and you'd need to do a very careful search to find a "map" in my code. That's not what it's about. I'm not surprised when imperative code is messed up by translating that into it.
In practice, it's a pretty well-known phenomenon experienced by many skilled programmers that being forced into different styles by different languages results in learning things that you would only have learned very slowly if you had stuck only to your original language. To be concrete about the "very slowly", I'm talking time frames of your entire career, if not your entire life and beyond. It would be a long time programming in Java before you discover the concept of something like "pure functions" as a distinct sort of function, a desirable sort of function, and one that you might want organize your programming style around.
Of course, having heard of the concept already, we'd all like to fancy ourselves smart enough to figure it out in less than, say, three decades. But we're just lying to ourselves when we do that. Even the smartest of us is not as smart as all of us. You are not independently capable of rediscovering everything all the various programming communities have discovered over decades. If you want to know what even the smartest of us can do on their own without reference to decades of experience of others, you can look into the state of computer programming in more-or-less the 1980s, 90s if you're feeling generous. I think we've learned a lot since then, and the delta between the modern programmer and a 1980s programmer certainly isn't in their IQ or anything similar, it is in their increased collective community experience.
By getting out into systems that force us to learn different paradigms, and into communities that have learned how to use them, we draw on the experience of others and cover far more ground than we could ever have covered on our own, or in the context of a single language where we can settle into a local optima comfort zone. Jumping out of your original community is kind of an annealing process for our programming skills.
"The best “fp” I’m using nowadays is closures, currying in the form of func.bind(this[, first]) and map/filter."
That is really not the lesson about software design that FP teaches, and blindly carrying those principles into imperative programming is at times a quite negative value, as your experience bears out. FP has more to say about purity of functions, the utility of composition of small parts, the flexibility of composition with small parts, ways to wrap parts of the program that can't be handled that way, and providing an existence proof that despite what an imperative programmer might think it is in fact possible to program this way at a system architecture level. I actually agree 100% that anyone whose takeaway from FP is "we should use map everywhere because they're better than for loops and anyone who uses for loops is a Bad Programmer" missed the forest for the leaves, and I choose that modification of the standard metaphor carefully. I consider my programming style highly influenced by my time in functional programming land and you'd need to do a very careful search to find a "map" in my code. That's not what it's about. I'm not surprised when imperative code is messed up by translating that into it.
> FP has more to say about purity of functions, the utility of composition of small parts, the flexibility of composition with small parts, ways to wrap parts of the program that can't be handled that way, and providing an existence proof that despite what an imperative programmer might think it is in fact possible to program this way at a system architecture level.
Adding to that, in my case it also made realize that deterministic elimination of entire classes of errors in large, complex code bases, in a systematic rather than ad-hoc way, is actually possible. Prior to discovering fp, and particularly Haskell's type system, I spent much effort trying to do that with a combination of TDD and increasingly elaborate try/catch/throw error handling. Discovering Haskell's compiler, type system, and monadic quarantining of effects obsoleted all that effort and was a huge eye opener for me. And a nice side-effect is easy, reliable refactor-ability. Being able to apply those concepts to imperative and other programming paradigms is where the real value in fp is, imho. Programmers still wrangling with the Tarpit [1] need to take a look if they haven't already.
[1]:https://news.ycombinator.com/item?id=34954126
Adding to that, in my case it also made realize that deterministic elimination of entire classes of errors in large, complex code bases, in a systematic rather than ad-hoc way, is actually possible. Prior to discovering fp, and particularly Haskell's type system, I spent much effort trying to do that with a combination of TDD and increasingly elaborate try/catch/throw error handling. Discovering Haskell's compiler, type system, and monadic quarantining of effects obsoleted all that effort and was a huge eye opener for me. And a nice side-effect is easy, reliable refactor-ability. Being able to apply those concepts to imperative and other programming paradigms is where the real value in fp is, imho. Programmers still wrangling with the Tarpit [1] need to take a look if they haven't already.
[1]:https://news.ycombinator.com/item?id=34954126
That might be, probably is. But the representation of FP gets mostly done by those who are only halfway there, creating an impression that it is a better way of programming overall, when it’s just a mixed bag of approaches dictated by a set of esoteric languages (from business pov). The worst part is that it doesn’t translate verbatim to any non-fringe language and creates a mess in it, due to adopted inertia. At least that is my experience with FP “recruitment”.
I wish I skipped this FP tour completely and instead learned how to structure my programs directly. Could save me a year or five. Maybe there’s no better way, but in practice clear explanations are always better than these arcane teachings where you repeat something until you get it by yourself.
I wish I skipped this FP tour completely and instead learned how to structure my programs directly. Could save me a year or five. Maybe there’s no better way, but in practice clear explanations are always better than these arcane teachings where you repeat something until you get it by yourself.
"In theory, you could pick up your one language, say, Java, and through the course of a normal career learn everything necessary to program in that language in the best possible way."
OK, then you know about currying, immutable data structures, map/reduce/filter, &c.
Because Java has that since way back when. No real closures, I think, but that doesn't matter much because the anonymous functions do what you want pretty much all the time and you could probably invent your own closures if you really want something else.
OK, then you know about currying, immutable data structures, map/reduce/filter, &c.
Because Java has that since way back when. No real closures, I think, but that doesn't matter much because the anonymous functions do what you want pretty much all the time and you could probably invent your own closures if you really want something else.
> OK, then you know about currying, immutable data structures, map/reduce/filter, &c.
It's not a certainty you learn about those things from Java, depends on your team/manager/codebase. None of that is enforced in Java the way it is in fp. Plus, none of it is really core or native to Java, it was added on later.
That's how we got essays back in the 2000s like "The Perils of Java Schools", "Can Your Language Do This", and "Beating the Averages".
https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...
https://www.joelonsoftware.com/2006/08/01/can-your-programmi...
https://paulgraham.com/avg.html
It's not a certainty you learn about those things from Java, depends on your team/manager/codebase. None of that is enforced in Java the way it is in fp. Plus, none of it is really core or native to Java, it was added on later.
That's how we got essays back in the 2000s like "The Perils of Java Schools", "Can Your Language Do This", and "Beating the Averages".
https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...
https://www.joelonsoftware.com/2006/08/01/can-your-programmi...
https://paulgraham.com/avg.html
The constraint here is "the best possible way".
I wouldn't even say antiquated, modern .Net APIs can suck to work with too, the entire ecosystem is written for C# ASP.Net core and everything else feels second class.
I love F#, the working with C# elements of the language drove me away.
I love F#, the working with C# elements of the language drove me away.
Which elements were the source of pain?
Writing web applications and back-ends in F#, as far as I'm aware, is straightforward and a joy because of integration with the rest of ecosystem.
Writing web applications and back-ends in F#, as far as I'm aware, is straightforward and a joy because of integration with the rest of ecosystem.
I was a college dropout and self taught bash and python programmer and quite some time ago, I read about Haskell, decided to teach myself to use it, and then realized I had absolutely no idea what programming actually was, and basically spent the next 15 years teaching myself computer science, category theory, abstract algebra and so on, so that I could finally understand Haskell code.
I still don't understand Haskell, but it did help me learn Rust when I decided to learn that. And I think I could explain what a monad is.
edit: It's a data structure that implements flat map. Hope this saves someone else a few years of their life.
I still don't understand Haskell, but it did help me learn Rust when I decided to learn that. And I think I could explain what a monad is.
edit: It's a data structure that implements flat map. Hope this saves someone else a few years of their life.
> I still don't understand Haskell
It's not you. Haskell has very bad syntax. It's not hard to understand it, it you rewrite the same things in something saner. Haskell was developed by people who enjoy one-liners and don't really need to write practical programs.
Another aspect of Haskell is that it was written by people who were so misguided as to think that mathematical formulas are somehow superior to typical imperative languages, with meaningful variable names, predictable interpretations of sequences of instructions etc. They, instead, made it all bespoke. Every operation has its own syntax, variables are typically named as they would in math formulas (eg. X and X'). This makes no sense, and is, in fact, very harmful when writing real-world programs, but because, by and large, Haskell never raises to the task of writing real-world programs, it doesn't deter the adepts from using it.
It's not you. Haskell has very bad syntax. It's not hard to understand it, it you rewrite the same things in something saner. Haskell was developed by people who enjoy one-liners and don't really need to write practical programs.
Another aspect of Haskell is that it was written by people who were so misguided as to think that mathematical formulas are somehow superior to typical imperative languages, with meaningful variable names, predictable interpretations of sequences of instructions etc. They, instead, made it all bespoke. Every operation has its own syntax, variables are typically named as they would in math formulas (eg. X and X'). This makes no sense, and is, in fact, very harmful when writing real-world programs, but because, by and large, Haskell never raises to the task of writing real-world programs, it doesn't deter the adepts from using it.
Just to give a different pov I find Haskell very intuitive, and particularly I find that code written by other people is very easy to understand (compared to Java or TypeScript at least).
And by the way x and x' are totally fine names for a value of a very generic type (or even a very specific type depending on the circumstances), as long as the types and the functions are decently named. I mean, how else would you call the arguments of
splitAt :: Eq a => a -> [a] -> [[a]]
?
There is no need for anything more complex than
splitAt x xs = ...
And by the way x and x' are totally fine names for a value of a very generic type (or even a very specific type depending on the circumstances), as long as the types and the functions are decently named. I mean, how else would you call the arguments of
splitAt :: Eq a => a -> [a] -> [[a]]
?
There is no need for anything more complex than
splitAt x xs = ...
> I mean, how else would you call the arguments of
> splitAt :: Eq a => a -> [a] -> [[a]]
Those don't seem to be names of parameters, but rather of types. It's missing parameter names entirely.
I spent a good 2 minutes looking at that signature trying to figure it out (and I've read some Haskell tutorials so I'm at least familiar with the syntax). This would've helped:
Those don't seem to be names of parameters, but rather of types. It's missing parameter names entirely.
I spent a good 2 minutes looking at that signature trying to figure it out (and I've read some Haskell tutorials so I'm at least familiar with the syntax). This would've helped:
def split_by<T>(separator: T, list: List[T]) -> List[List[T]]
> Those don't seem to be names of parameters, but rather of types. It's missing parameter names entirely.
The rest of the definition is at the end, to see it as a whole:
The rest of the definition is at the end, to see it as a whole:
splitAt :: Eq a => a -> [a] -> [[a]]
splitAt x xs = ...
I think some of the confusion is because you're referring to the type variables as parameters. Parameters and type variables are not the same thing. A is a type variable, X is a parameter in your example.
No, you're right. It is perfectly clear from the type signature
That's what (some) other people do. None of that stops you writing Haskell in whatever style you want, with meaningful variable names, curly braces and semicolons!
Unfortunately, writing isn't even half the battle. Before you start writing, you need to read a lot. And Haskell code is, in general, atrocious. It always feels like there was a normal way to do something, but the author decided to chose the most convoluted way they can imagine to accomplish the same thing for the sake of a bizarre fashion sense.
You knew Paul Hudak, Simon Peyton Jones, Phil Wadler, etc? Were they thinking about the benefits of mathematical formulas over program counters and procedural keywords when designing Haskell?
I was under the impression from the History of Haskell [0] that they were interested in unifying research into lazy evaluation of functional programming languages.
> This makes no sense, and is, in fact, very harmful when writing real-world programs,
Gosh, what am I doing with my life? I must have made up all those programs I wrote on my stream, the ones I use to maintain my website, and all the boring line-of-business code I write at work. /s
In all seriousness, Haskell has its warts, but being impractical isn't one of them. To some purists the committee has been overly pragmatic with the design of the language. As far as functional programming languages go it's pretty hairy. You have "pure" functions in the base libraries that can throw runtime exceptions when given the wrong values for their arguments (ie: the infamous head function). Bottom, a special kind of null value, is a member of every type. There exist functions to escape the type system entirely that are used with some frequency to make things work. The committee has gone back more than once to reshape the type-class hierarchy much to the chagrin of the community of maintainers who had to manually patch old code or risk having it not longer compile on new versions of the base libraries. These are all hairy, pragmatic trade-offs the language and ecosystem designers and maintainers have had to make... because people write software using this language to solve problems they have and they have to maintain these systems.
[0] https://www.microsoft.com/en-us/research/wp-content/uploads/...
I was under the impression from the History of Haskell [0] that they were interested in unifying research into lazy evaluation of functional programming languages.
> This makes no sense, and is, in fact, very harmful when writing real-world programs,
Gosh, what am I doing with my life? I must have made up all those programs I wrote on my stream, the ones I use to maintain my website, and all the boring line-of-business code I write at work. /s
In all seriousness, Haskell has its warts, but being impractical isn't one of them. To some purists the committee has been overly pragmatic with the design of the language. As far as functional programming languages go it's pretty hairy. You have "pure" functions in the base libraries that can throw runtime exceptions when given the wrong values for their arguments (ie: the infamous head function). Bottom, a special kind of null value, is a member of every type. There exist functions to escape the type system entirely that are used with some frequency to make things work. The committee has gone back more than once to reshape the type-class hierarchy much to the chagrin of the community of maintainers who had to manually patch old code or risk having it not longer compile on new versions of the base libraries. These are all hairy, pragmatic trade-offs the language and ecosystem designers and maintainers have had to make... because people write software using this language to solve problems they have and they have to maintain these systems.
[0] https://www.microsoft.com/en-us/research/wp-content/uploads/...
You don't need to know the author personally to appreciate the result of their work...
> Gosh, what am I doing with my life?
I would ask the same question, but unironically. No, you didn't make up those programs of course. I didn't claim that real-world programs are impossible to write in Haskell. I claimed that Haskell is a bad tool for writing real-world programs. People make sub-optimal decisions all the time. That's just human nature... choosing Haskell for any program that would require debugging, long-term maintenance, cross-platform UI, or plenty of other desirable properties is just a very bad choice. But people like you do it anyways!
Why? -- there are plenty of possible answers. If I wanted to look for the flattering answers, I'd say that a lot of experienced and talented programmers like Haskell. So, choosing to write in Haskell for that reason isn't such a bad idea. But, if I wanted to judge Haskell on its engineering rather than social merits: it has very little to bring to the table.
> Gosh, what am I doing with my life?
I would ask the same question, but unironically. No, you didn't make up those programs of course. I didn't claim that real-world programs are impossible to write in Haskell. I claimed that Haskell is a bad tool for writing real-world programs. People make sub-optimal decisions all the time. That's just human nature... choosing Haskell for any program that would require debugging, long-term maintenance, cross-platform UI, or plenty of other desirable properties is just a very bad choice. But people like you do it anyways!
Why? -- there are plenty of possible answers. If I wanted to look for the flattering answers, I'd say that a lot of experienced and talented programmers like Haskell. So, choosing to write in Haskell for that reason isn't such a bad idea. But, if I wanted to judge Haskell on its engineering rather than social merits: it has very little to bring to the table.
Strange. In my experience Haskell is the best language for long-term maintainability! I can actually come back to code I've written years ago and understand what it does. I've never experience that with another language.
This is not really what maintainability means to me. To me, it just means you have a good memory.
To be able to maintain something you need to be able to transfer the ownership of the piece of code to someone else. You need to be able to amend the code easily to extend or to remove functionality. It means that the code can be easily split into pieces that can be given to multiple developers to work simultaneously towards a common goal.
Haskell scores poorly on any of those points.
It's very hard to transfer ownership because Haskell programs have too much bespoke syntax that anyone but the original author will not be familiar with. Haskell programs are very hard to understand by executing them because there's no chance of a good step debugger due to the language being "lazy". Haskell programs are always "full of surprises" because they allow a lot of flexibility in the interpretation of the same symbols. The problems C++ programmers complain about when faced with operators overloading are the kind of things Haskell programmers call "Tuesday".
"Pure" functions are a lot harder to modify to add functionality. Typically, such modifications would require swiping changes across the entire codebase. One may argue that this preserves "single responsibility" constraint, but in practice it means a lot more work.
Objects and modules were advertised as a solution to code modularity -- another necessary quality for maintainability. While Haskell has modules, it doesn't really have smaller units of encapsulation other than functions. If two programmers are tasked to work on the same module, they aren't going to have a good time.
To be able to maintain something you need to be able to transfer the ownership of the piece of code to someone else. You need to be able to amend the code easily to extend or to remove functionality. It means that the code can be easily split into pieces that can be given to multiple developers to work simultaneously towards a common goal.
Haskell scores poorly on any of those points.
It's very hard to transfer ownership because Haskell programs have too much bespoke syntax that anyone but the original author will not be familiar with. Haskell programs are very hard to understand by executing them because there's no chance of a good step debugger due to the language being "lazy". Haskell programs are always "full of surprises" because they allow a lot of flexibility in the interpretation of the same symbols. The problems C++ programmers complain about when faced with operators overloading are the kind of things Haskell programmers call "Tuesday".
"Pure" functions are a lot harder to modify to add functionality. Typically, such modifications would require swiping changes across the entire codebase. One may argue that this preserves "single responsibility" constraint, but in practice it means a lot more work.
Objects and modules were advertised as a solution to code modularity -- another necessary quality for maintainability. While Haskell has modules, it doesn't really have smaller units of encapsulation other than functions. If two programmers are tasked to work on the same module, they aren't going to have a good time.
> To be able to maintain something you need to be able to transfer the ownership of the piece of code to someone else. You need to be able to amend the code easily to extend or to remove functionality. It means that the code can be easily split into pieces that can be given to multiple developers to work simultaneously towards a common goal.
> Haskell scores poorly on any of those points
Interesting. I work at a company with over a hundred people committing to a Haskell code-base that runs our entire back-end. As far as I can tell we're continuously shipping code several times a day, every day, with very low impact on our service level indicators.
When we do have production issues they're rarely attributed to Haskell. I can think of one incident in 3 years where a space leak was caught in production. It was straight forward to address and fix before it impacted customers.
In practice, Haskell has been amazing to work with. I just rewrote over a thousand lines of code and shipped that to production without incident. I've never had that go off easily in any other language I've worked with (and I've been around for over twenty years and worked in everything from C, C++, Python, and JS).
> Haskell scores poorly on any of those points
Interesting. I work at a company with over a hundred people committing to a Haskell code-base that runs our entire back-end. As far as I can tell we're continuously shipping code several times a day, every day, with very low impact on our service level indicators.
When we do have production issues they're rarely attributed to Haskell. I can think of one incident in 3 years where a space leak was caught in production. It was straight forward to address and fix before it impacted customers.
In practice, Haskell has been amazing to work with. I just rewrote over a thousand lines of code and shipped that to production without incident. I've never had that go off easily in any other language I've worked with (and I've been around for over twenty years and worked in everything from C, C++, Python, and JS).
I worked for a company that had a product with several million lines of C, couple hundreds of lines of Java, same for Go, Ruby and Python.
And it worked great! And you know why? -- The programmers were skilled at what they were doing. There were about 60 employees in total, and they managed a relatively big codebase for a complicated product (distributed filesystem). Btw, our build system was written in Haskell.
And why do I mention this? -- because I also worked in many other companies, who used all the same languages, typically for much smaller codebases compared to the number of people working on them. And the effects were usually awful.
In conclusion: the choice of language doesn't define the outcome. You may be successful choosing a bad language if you hire good programmers and other stars align to make it happen. You can also easily fail if you use a good language, but other, more important conditions don't hold.
Your individual success is at best an indication that it's possible to use Haskell to achieve your goals. It doesn't mean it's a good tool. You didn't even try to have a test that'd compare Haskell to other languages, you don't have any explanation for why Haskell is good for your case. It just worked "somehow".
What I say, I saw from a more general perspective, and with some justification. But if you need examples rather than justification: at one point in the past, Japanese high-schools used Haskell to teach computer science. I was able to compare the experience to Basic and Pascal which I experienced personally. In the hands of a mediocre-bad programmer Haskell is an awful tool and produces far worse results than Basic or Pascal. And, surprise, most programmers in the world are mediocre-bad. You cannot take your example and extrapolate from it that if everyone used Haskell software would've been better. In fact, there's every indication it wouldn't. In most likelyhood it'd be a lot worse.
And it worked great! And you know why? -- The programmers were skilled at what they were doing. There were about 60 employees in total, and they managed a relatively big codebase for a complicated product (distributed filesystem). Btw, our build system was written in Haskell.
And why do I mention this? -- because I also worked in many other companies, who used all the same languages, typically for much smaller codebases compared to the number of people working on them. And the effects were usually awful.
In conclusion: the choice of language doesn't define the outcome. You may be successful choosing a bad language if you hire good programmers and other stars align to make it happen. You can also easily fail if you use a good language, but other, more important conditions don't hold.
Your individual success is at best an indication that it's possible to use Haskell to achieve your goals. It doesn't mean it's a good tool. You didn't even try to have a test that'd compare Haskell to other languages, you don't have any explanation for why Haskell is good for your case. It just worked "somehow".
What I say, I saw from a more general perspective, and with some justification. But if you need examples rather than justification: at one point in the past, Japanese high-schools used Haskell to teach computer science. I was able to compare the experience to Basic and Pascal which I experienced personally. In the hands of a mediocre-bad programmer Haskell is an awful tool and produces far worse results than Basic or Pascal. And, surprise, most programmers in the world are mediocre-bad. You cannot take your example and extrapolate from it that if everyone used Haskell software would've been better. In fact, there's every indication it wouldn't. In most likelyhood it'd be a lot worse.
I’ve been in this industry for over twenty years. I’ve written a fair share of code in other languages. There’s not enough empirical evidence to suggest that one language is better than any other.
My example is only a counter argument that Haskell isn’t suitable because of the reasons you stated. Clearly it can be maintained, work can be split among groups, and delivered with reasonable efficiency… like a lot of software can be in other languages.
My example is only a counter argument that Haskell isn’t suitable because of the reasons you stated. Clearly it can be maintained, work can be split among groups, and delivered with reasonable efficiency… like a lot of software can be in other languages.
I don't know what to tell you. I've been successfully using Haskell in production for over ten years, and it's the most maintainable language I've used for a variety of reasons, including the one given in my message above.
I think we can drop the "real-world," qualifier as it is unlikely there is an "imaginary-world" that we write programs for.
What engineering merits did you have in mind?
What engineering merits did you have in mind?
Real world in this contexts contrasts the world of programs that nobody needs or uses. Programs that are written for amusement or with no stringent requirements.
> it is unlikely there is an "imaginary-world" that we write programs for
I think academia is typically what's meant as an imaginary world, along with play that may be in reference to no world at all.
I think academia is typically what's meant as an imaginary world, along with play that may be in reference to no world at all.
I think that's a good starting definition for programmers, but still could cause confusion when you run into something like IO in Haskell. IO isn't really a data structure, and it's hard to fit the "flat map" concept to it.
If you want you can still keep this point of view, by saying that IO is conceptually a data structure that builds a description of what the program does. In this point of view it follows that there is another, impure program that interprets the IO data structure and actually performs the computations
(Of course in practice IO isn't implemented like this, because it would be too slow)
(But in every other language, like Javascript or Python, you can define IO as a data structure. Or even in Haskell itself, you can define for eg. a free monad that gets interpreted later, and it can be made to be just as good as IO itself, though typically people make it less powerful than IO)
However note that every other "computational" monad (like the list monad or the Cont monad) actually is a data structure, even though they describe effects just like IO does. This is because IO is the only possible exception to the "monads are data structures" thing in Haskell (if you don't subscribe to the above view), because Haskell doesn't let you define types that aren't data structures
The only issue with this point of view is that you now need to say what flatMap means for things that are not shaped like arrays. Eg. does it make intuitive sense to flatMap a tree? (A retort is that it must make sense, whatever you call this operation; and flattening a tree means to turn a tree of trees into an one-level tree)
(Of course in practice IO isn't implemented like this, because it would be too slow)
(But in every other language, like Javascript or Python, you can define IO as a data structure. Or even in Haskell itself, you can define for eg. a free monad that gets interpreted later, and it can be made to be just as good as IO itself, though typically people make it less powerful than IO)
However note that every other "computational" monad (like the list monad or the Cont monad) actually is a data structure, even though they describe effects just like IO does. This is because IO is the only possible exception to the "monads are data structures" thing in Haskell (if you don't subscribe to the above view), because Haskell doesn't let you define types that aren't data structures
The only issue with this point of view is that you now need to say what flatMap means for things that are not shaped like arrays. Eg. does it make intuitive sense to flatMap a tree? (A retort is that it must make sense, whatever you call this operation; and flattening a tree means to turn a tree of trees into an one-level tree)
I feel the same pay-off - but arrived at that point via Clojure.
Immutable-first, aim for purity, ability to drop out of it when necessary.
As stringent as you need it to be (static vs. dynamic types vs. specs), as flexible as you want it to be.
As stringent as you need it to be (static vs. dynamic types vs. specs), as flexible as you want it to be.
I really wanted to like F#, and I kinda do, but it has a number of quirks, compiler issues and cracks in the design that are getting worse:
First off, the compiler is single-pass. All your definitions have to be in order. This even extends to type hints - it can't use clues to the right to deduce the type of an expression on the left. This is supposedly for perf reasons, but the compiler can become extremely slow because the inference engine has to work so hard - slower than GHC for sure.
Speaking of slowness, Haskell is surprisingly fast. Idiomatic Haskell can be within 50% the perf of C, since its laziness and purity unlock powerful optimizations. F# is eager and the compiler doesn't do anything fancy. Perf often makes you reach for mutable state and imperative structure, which is disappointing.
The OOP paradigm feels bolted on. Should you use classes or modules? Pure functions or members? It depends, what mood are you in? Unfortunately only member functions support overloads, and overloads are useful for some SFINAE-type patterns with `inline` functions, so they get a bit overused.
`ref` struct support, which is vital for zero-copy and efficient immutable data, have very primitive support. even C# is ahead on this.
Very limited support for implicit conversions, no support for type classes and no function overloading leaves F# with nothing like a numeric tower you'd have in Lisp, and makes building something like Numpy clunky.
I use C# at work, and I love Haskell, so I really wanted to love F#. But it just doesn't get the love it needs from MS, and some design decisions aren't aging well - particularly as C# itself evolves in directions that are tricky for F#'s aging compiler to support.
First off, the compiler is single-pass. All your definitions have to be in order. This even extends to type hints - it can't use clues to the right to deduce the type of an expression on the left. This is supposedly for perf reasons, but the compiler can become extremely slow because the inference engine has to work so hard - slower than GHC for sure.
Speaking of slowness, Haskell is surprisingly fast. Idiomatic Haskell can be within 50% the perf of C, since its laziness and purity unlock powerful optimizations. F# is eager and the compiler doesn't do anything fancy. Perf often makes you reach for mutable state and imperative structure, which is disappointing.
The OOP paradigm feels bolted on. Should you use classes or modules? Pure functions or members? It depends, what mood are you in? Unfortunately only member functions support overloads, and overloads are useful for some SFINAE-type patterns with `inline` functions, so they get a bit overused.
`ref` struct support, which is vital for zero-copy and efficient immutable data, have very primitive support. even C# is ahead on this.
Very limited support for implicit conversions, no support for type classes and no function overloading leaves F# with nothing like a numeric tower you'd have in Lisp, and makes building something like Numpy clunky.
I use C# at work, and I love Haskell, so I really wanted to love F#. But it just doesn't get the love it needs from MS, and some design decisions aren't aging well - particularly as C# itself evolves in directions that are tricky for F#'s aging compiler to support.
I feel like functional programming is pretty trivial. It's pure programming that is very difficult.
They're often conflated because Haskell is pure and functional and probably the most talked about heavily functional language.
I certainly didn't know that impure functional languages like OCaml existed for ages.
They're often conflated because Haskell is pure and functional and probably the most talked about heavily functional language.
I certainly didn't know that impure functional languages like OCaml existed for ages.
Is Haskell pure?
It has exceptions
You can divide by zero
It has unsafe IO primitives
It has exceptions
You can divide by zero
It has unsafe IO primitives
You're right: "pure" is not a well-defined concept. The well-defined concept that describes Haskell's benefits in this regard is "referential transparency". That means that this code
let x = <definition of x>
in ... x ... x ...
... <definition of x> ... <definition of x> ...
Well, technically that isn't true if you use, for example, unsafePerfomIO in the defintion of x. Referential transparency is still a spectrum, just like purity. Haskell is much closer to purity than the vast majority of languages out there.
Also, even if Haskell were perfectly pure, the fact that it uses lazy evaluation is far more important to actually being able to make use of referential transparency. In a strict language you will still see a massive performance differences if replacing the first version with the second, in the most common cases.
Also, even if Haskell were perfectly pure, the fact that it uses lazy evaluation is far more important to actually being able to make use of referential transparency. In a strict language you will still see a massive performance differences if replacing the first version with the second, in the most common cases.
> technically that isn't true if you use, for example, unsafePerfomIO in the defintion of x
Ah, well, regardless of whether it holds in Haskell, referential transparency is a well-defined concept. Purity is not a well-defined concept (at least as far as I know. Please share a formal definition if you have one!). That's primarily what I'm trying to say.
But I also disagree with your point about unsafePerformIO. In practice, nothing in Haskell violates referential transparency in a significant way. Who knows why? It's an emergent phenomenon that in principle need not have occurred, but in practice it did. Debug.Trace and similar are about the only things that technically violate referential transparency (and they are extremely tame).
> the fact that it uses lazy evaluation is far more important to actually being able to make use of referential transparency
Yes, I agree with that.
Ah, well, regardless of whether it holds in Haskell, referential transparency is a well-defined concept. Purity is not a well-defined concept (at least as far as I know. Please share a formal definition if you have one!). That's primarily what I'm trying to say.
But I also disagree with your point about unsafePerformIO. In practice, nothing in Haskell violates referential transparency in a significant way. Who knows why? It's an emergent phenomenon that in principle need not have occurred, but in practice it did. Debug.Trace and similar are about the only things that technically violate referential transparency (and they are extremely tame).
> the fact that it uses lazy evaluation is far more important to actually being able to make use of referential transparency
Yes, I agree with that.
It seems that someone did come up with a formal definition to try to capture the concept [0], though I haven't looked into the details to see whether it really matches the colloquial use of the terms "pure" and "impure" functional programming. In short, the formal definition they came up with is that a language is pure if the result of a valid program is the same under any parameter passing strategy.
I should note that I agree that, in practice, Haskell is almost always pure and/or referentially transparent. I was just pointing out that technically the GP was correct that it's not perfectly 100% so.
[0] https://www.cambridge.org/core/journals/journal-of-functiona...
I should note that I agree that, in practice, Haskell is almost always pure and/or referentially transparent. I was just pointing out that technically the GP was correct that it's not perfectly 100% so.
[0] https://www.cambridge.org/core/journals/journal-of-functiona...
Sabry's definition of "pure" fails to satisfy me for two reasons:
1. It assumes that the language is "a conservative extension of the simply typed λ-calculus". That's rather high-powered yet also really restrictive! Haskell doesn't satisfy that requirement. It also assumes the language has functions. Expression languages (i.e. ones without functions) are perfectly reasonable languages and it makes sense to ask whether they are pure.
2. It assumes that a language putatively has multiple evaluation orders (which I suppose is a consequence of the assumption "It is a conservative extension of the simply typed λ-calculus"). Haskell doesn't have multiple evaluation orders. It has one! (notwithstanding you can influence it with seq/!)
If you unpick the essence of what Sabry's really saying you find you can translate it into the Haskell world through imposing two conditions:
C1. soundness of the β-axiom (a.k.a. referential transparency) (this plays the role of Sabry's condition that call by need and call by value have the same result).
C2. That
So Sabry's definition of "pure" is a long-winded and restricted way saying something that can be much more conveniently expressed by C1 and C2. If you disagree with me, please demonstrate a property of purity that can't be deduced from C1 and C2!
> I should note that I agree that, in practice, Haskell is almost always pure and/or referentially transparent. I was just pointing out that technically the GP was correct that it's not perfectly 100% so.
OK, fine, but I also said the GP was correct! I am keen to point out, however, that exceptions (including division by zero) do not violate referential transparency (and if someone thinks they violate "purity" that may be a sign that "purity" is ill-defined).
1. It assumes that the language is "a conservative extension of the simply typed λ-calculus". That's rather high-powered yet also really restrictive! Haskell doesn't satisfy that requirement. It also assumes the language has functions. Expression languages (i.e. ones without functions) are perfectly reasonable languages and it makes sense to ask whether they are pure.
2. It assumes that a language putatively has multiple evaluation orders (which I suppose is a consequence of the assumption "It is a conservative extension of the simply typed λ-calculus"). Haskell doesn't have multiple evaluation orders. It has one! (notwithstanding you can influence it with seq/!)
If you unpick the essence of what Sabry's really saying you find you can translate it into the Haskell world through imposing two conditions:
C1. soundness of the β-axiom (a.k.a. referential transparency) (this plays the role of Sabry's condition that call by need and call by value have the same result).
C2. That
let x = <definition of x> in ...
let !x = <definition of x> in ...
So Sabry's definition of "pure" is a long-winded and restricted way saying something that can be much more conveniently expressed by C1 and C2. If you disagree with me, please demonstrate a property of purity that can't be deduced from C1 and C2!
> I should note that I agree that, in practice, Haskell is almost always pure and/or referentially transparent. I was just pointing out that technically the GP was correct that it's not perfectly 100% so.
OK, fine, but I also said the GP was correct! I am keen to point out, however, that exceptions (including division by zero) do not violate referential transparency (and if someone thinks they violate "purity" that may be a sign that "purity" is ill-defined).
It is pure in the same way that Rust is memory safe. That is too say there are a tiny number of exceptions/escape hatches, but they are not meant to be the norm. Every day programming doesn't involve them.
Exceptions aren't impure anyway.
Exceptions aren't impure anyway.
Exceptions define an effect. Code with exceptions aren't actually pure in the sense that their return type doesn't fully describe what the code does, so it doesn't just map an input into an output: there is something else going on
In some pure functional languages, the pure fragment doesn't have exceptions, and you add exceptions as an effect (or as a monad)
(If you reify the effect with a type like Either or Result, then the code becomes pure: but that's just a monad like said above)
In some pure functional languages, the pure fragment doesn't have exceptions, and you add exceptions as an effect (or as a monad)
(If you reify the effect with a type like Either or Result, then the code becomes pure: but that's just a monad like said above)
> in the sense that their return type doesn't fully describe what the code does
Sure they do, at least in Haskell. Bottom inhabits all types.
Sure they do, at least in Haskell. Bottom inhabits all types.
There's a difference between "doesn't return because it has an infinite loop" and "doesn't return because it threw an exception"
Haskell can't express the difference, but languages with effects, like Koka and F*, can!
The first effect is called div in Koka and the second is called exn, section 2.2 here
https://www.microsoft.com/en-us/research/wp-content/uploads/...
Haskell can't express the difference, but languages with effects, like Koka and F*, can!
The first effect is called div in Koka and the second is called exn, section 2.2 here
https://www.microsoft.com/en-us/research/wp-content/uploads/...
It's fine if the poster above me wishes to change languages. Anyone who chooses to stick with Haskell should get comfortable with the notion that functions can diverge, and accept that this is fully consistent with the Haskell type system. The return types may seem unhelpful, but they are accurate.
Anyway I really like the take that Haskell is pure in the same sense that Rust is safe
Haskell has impure constructs but sets you up to define referentially transparent abstractions with them, and this is actually valued by the Haskell community
Haskell has impure constructs but sets you up to define referentially transparent abstractions with them, and this is actually valued by the Haskell community
I feel like exceptions where added as a mix of "look we can do that too" and "maybe if so many functions return optional values then it is going to be too much of a pain to use"
In hindsight I think few would now regret not having added them in the first place.
In hindsight I think few would now regret not having added them in the first place.
> maybe if so many functions return optional values then it is going to be too much of a pain to use
I strongly believe that there is a point in the PL design space that makes optionals everywhere usable. Maybe Haskell can still be the language that delivers this.
I strongly believe that there is a point in the PL design space that makes optionals everywhere usable. Maybe Haskell can still be the language that delivers this.
To plug my own solution, my effect system Bluefin makes exceptions visible in the type, well-scoped, and also freely composable with all other effects:
https://hackage.haskell.org/package/bluefin-0.0.3.0/docs/Blu...
https://hackage.haskell.org/package/bluefin-0.0.3.0/docs/Blu...
>It has unsafe IO primitives
To be tongue in cheek then it also has the side effect of heating the CPU.
To be tongue in cheek then it also has the side effect of heating the CPU.
Sir have you heard of GADTs
Or Elixir! Quite easy to grasp as well.
That’s interesting because F#’s OOP, as someone who knows neither C# nor Java, makes it more intimidating to me than OCaml.
Also interesting that when FP is mentioned, Hindley-Milner is implicitly understood to be part of FP too even though it doesn’t have to be. Clojure emphasizes immutability and FP but with dynamic typing and everything that comes with that.
Also interesting that when FP is mentioned, Hindley-Milner is implicitly understood to be part of FP too even though it doesn’t have to be. Clojure emphasizes immutability and FP but with dynamic typing and everything that comes with that.
Doesn't the "O" in OCaml stand for "Object", though? I think you could pick up either F# or OCaml just as easily.
The nuances of OOP in F# can be ignored by beginners, so I really wouldn’t let yourself be intimidated coming from Clojure.
[0] https://ocaml.org/docs/objects
The nuances of OOP in F# can be ignored by beginners, so I really wouldn’t let yourself be intimidated coming from Clojure.
[0] https://ocaml.org/docs/objects
OCaml classes and objects are (ironically) rarely used and generally discouraged. There are some cases where they’re practically required, such as GUI and FFI (js_of_ocaml). But otherwise, most code does encapsulation and abstraction using modules and functor modules (which are more like Haskell and Rust typeclasses than traditional OOP classes).
I don’t know much about F#, but last time I used it most of its standard library was in C# and .NET, so F# code would interact with objects and classes a lot. AFAIK F# also doesn’t have functor modules, so even without the dependence on C# code, you still can’t avoid classes and objects like you can with OCaml (e.g. you can’t write a generic collection module like `List` or `Set` without functors, it would have to be a collection of a specific type or a class).
I don’t know much about F#, but last time I used it most of its standard library was in C# and .NET, so F# code would interact with objects and classes a lot. AFAIK F# also doesn’t have functor modules, so even without the dependence on C# code, you still can’t avoid classes and objects like you can with OCaml (e.g. you can’t write a generic collection module like `List` or `Set` without functors, it would have to be a collection of a specific type or a class).
F# uses .NET's generics, so the statement regarding List/Set is completely incorrect (all base collections are generic).
I think you misread their claim - they said that generic list/set would have to be classes, not modules (generic modules are a specific thing in OCaml and aren't the same as a module of generic classes).
F# has "generics" just like Python and PHP now "have types".
It's not a yes/no feature.
It's not a yes/no feature.
Give F# a try. It has, and always had, true generics.
https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
> It's not a yes/no feature.
FTFM: It's not a true/false feature.
FTFM: It's not a true/false feature.
Alright. Humor me, what is the issue with F# generics as compared to other languages with generics? Which implementation (that is productively useful) is a "true" one?
> Clojure emphasizes immutability
Is "emphasizes" just another word for second-class support?
C++ emphasizes the importance of memory safety.
Is "emphasizes" just another word for second-class support?
C++ emphasizes the importance of memory safety.
Immutability is definitely first class in clojure, but you can work with mutable structures when you need to.
This is sounds like memory safety in C++.
https://www.infoworld.com/article/3714401/c-plus-plus-creato...
https://www.infoworld.com/article/3714401/c-plus-plus-creato...
This seems like a meaningless criticism when it comes to immutability in Clojure. You can have mutability in Haskell too. That doesn’t make it as unsafe as memory management in C++.
> You can have mutability in Haskell too.
Haskell enforces this via a type system.
What safeguards around mutability does Clojure have?
If I import a method 'foo()', is there any kind of contract, notation ... anything which could suggest whether it mutates or not?
Haskell enforces this via a type system.
What safeguards around mutability does Clojure have?
If I import a method 'foo()', is there any kind of contract, notation ... anything which could suggest whether it mutates or not?
> What safeguards around mutability does Clojure have?
Very nearly the entire language and standard library operate on immutable values only. Immutable values are the default, and you will use them for the vast majority of logic. You must do so, unless you very specifically opt to use dedicated reference types, at which point you’ll still need to produce intermediate immutable values to interact with that vast majority of the standard library.
And…
> is there any kind of contract, notation ... anything which could suggest whether it mutates or not?
Functions which mutate state are almost always suffixed !. They will typically fail if you pass them immutable values; they only operate on reference types, which have to be dereferenced (typically with the prefix @) to access their state.
Very nearly the entire language and standard library operate on immutable values only. Immutable values are the default, and you will use them for the vast majority of logic. You must do so, unless you very specifically opt to use dedicated reference types, at which point you’ll still need to produce intermediate immutable values to interact with that vast majority of the standard library.
And…
> is there any kind of contract, notation ... anything which could suggest whether it mutates or not?
Functions which mutate state are almost always suffixed !. They will typically fail if you pass them immutable values; they only operate on reference types, which have to be dereferenced (typically with the prefix @) to access their state.
> Is "emphasizes" just another word for second-class support?
I don't know what's your personal definition of "second-class support" but what it means is that it's explicitly supported by the language.
I don't know what's your personal definition of "second-class support" but what it means is that it's explicitly supported by the language.
C++ explicitly supports memory-safe programming. You can choose whether you want to mess around with raw pointer arithmetic.
What safeguards does the language actually put in-place?
What safeguards does the language actually put in-place?
> C++ explicitly supports memory-safe programming. You can choose whether you want to mess around with raw pointer arithmetic.
I don't think you know what you're talking about. Managing object ownership through systems like smart pointers is not memory safety. Applications that use smart pointers still suffer from memory issues, and it's possible to adopt object ownership systems that still use raw pointers, such as It's object ownership system.
I don't think you know what you're talking about. Managing object ownership through systems like smart pointers is not memory safety. Applications that use smart pointers still suffer from memory issues, and it's possible to adopt object ownership systems that still use raw pointers, such as It's object ownership system.
> I don't think you know what you're talking about.
Right. I sound just like someone talking about how "a language which emphasizes immutability" is an OK replacement for a language with pure functions.
Right. I sound just like someone talking about how "a language which emphasizes immutability" is an OK replacement for a language with pure functions.
The world is much less black and white than you’d like to see it.
Functions in Haskell including Prelude can throw exceptions which is not reflected in the type signature of the function. That is an effect that makes seemingly pure functions impure.
You can’t judge a language from a list of buzzwords. You need to look at how it is used in practice.
Functions in Haskell including Prelude can throw exceptions which is not reflected in the type signature of the function. That is an effect that makes seemingly pure functions impure.
You can’t judge a language from a list of buzzwords. You need to look at how it is used in practice.
> Functions in Haskell including Prelude can throw exceptions which is not reflected in the type signature of the function. That is an effect that makes seemingly pure functions impure.
No, bottom, or _|_, is an inhabitant of every lifted type. An exception is bottom. So the / function is still pure even though it can throw a divide-by-zero exception.
No, bottom, or _|_, is an inhabitant of every lifted type. An exception is bottom. So the / function is still pure even though it can throw a divide-by-zero exception.
Does it make it type-safe though? In dynamic languages type errors also result in exceptions.
> doesn't require every single function to be pure
having never done F# or haskell, doesn't that start getting into the territory of languages that encourage functional programming like ruby or javascript (modern javascript)?
having never done F# or haskell, doesn't that start getting into the territory of languages that encourage functional programming like ruby or javascript (modern javascript)?
I would suggest Scala as FP for beginners. It doesnt forces you to do pure functions. And its really beginners friendly to start with.
In modern Fortran, functions should be pure (although the language does not require this), and procedures that mutate arguments are made subroutines (which do not have return values).
Note that Fortran's interpretation of the term "pure" bizarrely allows a "pure" subprogram to depend on mutable state elsewhere (in a host, a module, or a COMMON block). So Fortran's "pure" functions aren't referentially transparent.
(F'2023 added a stronger form of "pure" and calls it "simple", but it didn't strengthen the places where a "pure" procedure should be required to be "simple", such as DO CONCURRENT, so being "simple" will be its own reward, if any compiler actually implements it. And a "simple" function's result value can still depend on a mutable pointer target.)
(F'2023 added a stronger form of "pure" and calls it "simple", but it didn't strengthen the places where a "pure" procedure should be required to be "simple", such as DO CONCURRENT, so being "simple" will be its own reward, if any compiler actually implements it. And a "simple" function's result value can still depend on a mutable pointer target.)
For the benefit(s) that you list, which are the best learning resources for F#?
But why do we need Haskell for this?
Realistically we don't but it's very rare to meet a programmer who understands these distinctions thats not also a great functional programmer.
This is my experience after spending five years as a Haskell programmer and managing a Haskell team for several years and now moving back to the c++ world to play with AI.
I know lots of good c++ programmers working on cutting edge stuff, real experts in their field, but they sometimes still don't have a clear way to understand how to model data
That is my opinion. It's probably highly contentious.
This is my experience after spending five years as a Haskell programmer and managing a Haskell team for several years and now moving back to the c++ world to play with AI.
I know lots of good c++ programmers working on cutting edge stuff, real experts in their field, but they sometimes still don't have a clear way to understand how to model data
That is my opinion. It's probably highly contentious.
I've actually had to fire a technically exceptional Haskell programmer because of the damage they did to our C# codebase (and arguably moreso, the team). Sometimes it's not a matter of talent or skill, but culture fit.
In my experience FP-aligned people on non-FP projects tend to be more likely to overengineer, more prone to argue in favor of the Great Rewrite For No Reason Except Aesthetics, and more likely to abuse "lesser" programmers when they put up PRs. They suck as team players on teams that are not made of language nerds. I am not just talking about the one person here who I fired, this is a legit pattern I've noticed over at least a half dozen people.
Conversely, they are exactly the right people to deploy when you have really tough, self-contained problems to solve that you wouldn't trust the normal Java 9-5ers to tackle.
No matter how they do it, you can always rewrite their working code in a more maintainable language later once it's working, and make it integrate well with the rest of your stack. :D
In my experience FP-aligned people on non-FP projects tend to be more likely to overengineer, more prone to argue in favor of the Great Rewrite For No Reason Except Aesthetics, and more likely to abuse "lesser" programmers when they put up PRs. They suck as team players on teams that are not made of language nerds. I am not just talking about the one person here who I fired, this is a legit pattern I've noticed over at least a half dozen people.
Conversely, they are exactly the right people to deploy when you have really tough, self-contained problems to solve that you wouldn't trust the normal Java 9-5ers to tackle.
No matter how they do it, you can always rewrite their working code in a more maintainable language later once it's working, and make it integrate well with the rest of your stack. :D
Your story matches my experience, but it always makes me think, why did this person want to work with you in the first place?
A great Haskell programmer (generally speaking) is going to be a culture misfit in any Java, C#, golang, etc shop. I know because I've been that miserable bastard who loves functional programming working with Java devs who don't know anything about FP and couldn't care less. To be clear I'm not saying you can't find a compatible Java shop (I actually did find a startup with a lot of Java devs who appreciated FP and used much of it in Java, and that was pretty great honestly), just that the odds are highly against you.
My biggest advice to people who like FP is: Find a job in a language like Clojure, Elixir, Scala, etc. There are a lot more jobs than you'd think. But if you can't, Ruby and Javascript/Typescript can be pretty close depending on where you go. Talk to existing devs and see how feel about FP in general before you join though!
A great Haskell programmer (generally speaking) is going to be a culture misfit in any Java, C#, golang, etc shop. I know because I've been that miserable bastard who loves functional programming working with Java devs who don't know anything about FP and couldn't care less. To be clear I'm not saying you can't find a compatible Java shop (I actually did find a startup with a lot of Java devs who appreciated FP and used much of it in Java, and that was pretty great honestly), just that the odds are highly against you.
My biggest advice to people who like FP is: Find a job in a language like Clojure, Elixir, Scala, etc. There are a lot more jobs than you'd think. But if you can't, Ruby and Javascript/Typescript can be pretty close depending on where you go. Talk to existing devs and see how feel about FP in general before you join though!
This is my experience, too. Some of the worst code I‘ve seen was a Haskell guy who first built his own (reactive?) concurrency framework and then implemented the actual functionality in completely unidiomatic and undocumented Java.
Some people don’t understand that the „best solution“ is not necessarily equal to the most beautiful abstraction they can think of.
Some people don’t understand that the „best solution“ is not necessarily equal to the most beautiful abstraction they can think of.
> Some of the best code I‘ve seen
There, fixed it for you.
But I have to be fair, whenever I see a demand for "idio(ma)tic code" I know that this is a place to avoid, no matter if they are imperatively or functionally inclined.
There, fixed it for you.
But I have to be fair, whenever I see a demand for "idio(ma)tic code" I know that this is a place to avoid, no matter if they are imperatively or functionally inclined.
I mean sure. Realistically, I'm certain I would do that if I were working on a typical code base, which is why I'm in an extremely niche field where that sort of thing is valued. From my extremely biased perspective, these are the 'hard' problems that need solving, versus the general run of the mill operational things. That probably sounds pretentious, but it takes skills for both.
Because for some reason there are no pure strict-by-default languages around.
All of them (especially newer ones) are, except Haskell (und some other, nowadays either obsolete or really obscure languages).
Idris (2), PureScript, Elm, Unison, Roc, Lean (4), Koka, Flix (and some other I've forgotten about).
Idris (2), PureScript, Elm, Unison, Roc, Lean (4), Koka, Flix (and some other I've forgotten about).
Elm is one example of such. However, it's also an illustration of why these languages are rare. With a strict semantics there's an almost unbearable temptation to add library functions with side effects. Elm only avoided this fate by giving its BDFL strict control over which packages could access the JS FFI. But that upset a lot of people.
I think Idris is the best example of a pure strict-by-default language (that also supports totality checking, I believe).
> that also supports totality checking, I believe
Yes, it does. It's also dependently typed.
Yes, it does. It's also dependently typed.
PureScript is an example.
I would recommend neither of those.
Haskell has very bad syntax (with extensive backing from Microsoft, iirc the guy who writes the compiler is a Microsoft's Research employee).
F# is a straight-up Microsoft's language.
It doesn't matter what other benefits it has. Just don't touch anything created by that company, and you will have one fewer regrets in your life.
But, if you still want a language from that category: SML or Erlang would be my pick.
Haskell has very bad syntax (with extensive backing from Microsoft, iirc the guy who writes the compiler is a Microsoft's Research employee).
F# is a straight-up Microsoft's language.
It doesn't matter what other benefits it has. Just don't touch anything created by that company, and you will have one fewer regrets in your life.
But, if you still want a language from that category: SML or Erlang would be my pick.
SPJ has left MSR and is now at Epic games, working on a new PL. However, even while he was at MSR, MS didn't really have a say in how Haskell was developed.
Well, MS didn't have to do anything. It's enough that they have (or had) the opportunity to do something.
There isn't an Overmind in MS that in a creepy voice tells you to spawn more overlords. Less than that, there doesn't need to be a written document that tells you to give money to MS or your data etc. There's just a general accepted understanding among the people who run that company that ends justify the means. And by "ends" they mean them and their investors getting rich.
If Haskell compiler could've been turned into a money-making machine, and it only required killing off half of Haskell programmer, MS would be working overtime on the plan to hide the bodies, but they'd never even consider the possibility of killing being bad... (metaphorically speaking, hopefully)
There isn't an Overmind in MS that in a creepy voice tells you to spawn more overlords. Less than that, there doesn't need to be a written document that tells you to give money to MS or your data etc. There's just a general accepted understanding among the people who run that company that ends justify the means. And by "ends" they mean them and their investors getting rich.
If Haskell compiler could've been turned into a money-making machine, and it only required killing off half of Haskell programmer, MS would be working overtime on the plan to hide the bodies, but they'd never even consider the possibility of killing being bad... (metaphorically speaking, hopefully)
Do you also suspect homicidal money making motives behind Z3, Lean, and F*? It seems more likely to me that they just want some useful knowledge out of these projects that they can integrate into a product that actually sells.
I have a misfortune to know personally some of the mid-to-high level execs from MS. What I write is based on the experience of working with these people. And I don't even know what Z3, Lean or F* are, so, pardon my ignorance, but I cannot answer your question.
What's wrong with Haskell's syntax? I think it's generally pretty nice though can be excessively terse at times.
* Significant white space, and the rules around whitespace are very convoluted.
* There's no pattern or regularity to how infix / prefix / suffix operators are used which makes splitting program text into self-contained sub-programs virtually impossible if you don't know the exact behavior, including priority of each operator.
* There's a tradition of exceptionally bad names for variables, inherited from the realm of mathematical formulas. In mathematics, it's desirable to give variables names devoid of everyday meaning to emphasize the generic nature of the idea being expressed. This works in the context of very short formulas, but breaks entirely in the context of programs which are usually many orders of magnitude bigger than even the largest formula you've ever seen. There, having meaningful names is a life west.
* It's impossible to make a good debugger for Haskell because of the language being "lazy". Debuggers are essential tools that help programmers in understanding the behavior of their programs. Haskell programmers are forced to rely on their imagination when explaining to themselves how their program works.
* Excessive flexibility. For example, a Haskell programmer may decide to overload string literals (or any literals for that matter). This is orders of magnitude worse than eg. overloading operators in C++, which is criticizes for defying expectations of the reader.
One of these points would've been enough for me to make the experience of working with a language unpleasant. All of them combined is a lot more than unpleasant.
* There's no pattern or regularity to how infix / prefix / suffix operators are used which makes splitting program text into self-contained sub-programs virtually impossible if you don't know the exact behavior, including priority of each operator.
* There's a tradition of exceptionally bad names for variables, inherited from the realm of mathematical formulas. In mathematics, it's desirable to give variables names devoid of everyday meaning to emphasize the generic nature of the idea being expressed. This works in the context of very short formulas, but breaks entirely in the context of programs which are usually many orders of magnitude bigger than even the largest formula you've ever seen. There, having meaningful names is a life west.
* It's impossible to make a good debugger for Haskell because of the language being "lazy". Debuggers are essential tools that help programmers in understanding the behavior of their programs. Haskell programmers are forced to rely on their imagination when explaining to themselves how their program works.
* Excessive flexibility. For example, a Haskell programmer may decide to overload string literals (or any literals for that matter). This is orders of magnitude worse than eg. overloading operators in C++, which is criticizes for defying expectations of the reader.
One of these points would've been enough for me to make the experience of working with a language unpleasant. All of them combined is a lot more than unpleasant.
From the point of view of writing a parser, Haskell's whitespace syntax seems like a hack. So, the grammar is defined with braces and semicolons, and to implement significant whitespace, the lexer inserts opening braces and semicolons at the start of each line according to some layout rules. That's not the hacky part; what makes it a hack is that to insert closing braces, the lexer inserts a closing brace when the parser signals an error. You can read about it here [0].
Also, on an aesthetic level, I think a lot of infix operators are kind of ugly. Examples include (<$>), ($), and (<*>). I think Haskell has too many infix operators. This is probably a result of allowing user-definable operators. I do like how you can turn functions into infix operators using backticks, though (e.g. "f x y" can be written as "x `f` y").
[0]: https://amelia.how/posts/parsing-layout.html
Also, on an aesthetic level, I think a lot of infix operators are kind of ugly. Examples include (<$>), ($), and (<*>). I think Haskell has too many infix operators. This is probably a result of allowing user-definable operators. I do like how you can turn functions into infix operators using backticks, though (e.g. "f x y" can be written as "x `f` y").
[0]: https://amelia.how/posts/parsing-layout.html
> Just don't touch anything created by that company, and you will have one fewer regrets in your life.
:-)
:-)
In my opinion, if you are after the mystical experience of understanding functional programming, you're better off learning Prolog. I think it has more to offer in terms of insight, because wrapping your head around the language only takes a couple days, but wrapping your head around its consequences is a gift which keeps on giving for quite some time.
Immutable functional programming is basically what 80% of your Prolog code will look like. The benefit is that you'll be able to understand how everything works from end-to-end.
Immutable functional programming is basically what 80% of your Prolog code will look like. The benefit is that you'll be able to understand how everything works from end-to-end.
Prolog is a logic programming language though, I wouldn't expect it to have a lot of overlap with functional programming?
Prolog variables are immutable by default. Data structures are the same as the immutable functional programming counterparts (no arrays, and tree based everything). Recursion is the only way to loop. Map, filter, fold(l/r), reduce, accumulate, etc, are staple predicates.
As I said, 80% of your code, or more, will look just like a functional programme.
As I said, 80% of your code, or more, will look just like a functional programme.
An execution pipeline in a functional language is just half a relation in Prolog. Prolog allows you to also run it 'backwards', you can provide the output and have it figure out what the inputs would need to be.
Run in backwards, so they say, but not really. Most things you'll write can't run backwards. You have to write them in a special way for that to be possible, and even then what it means is that you can do a depth first search to find the value.
There are some useful extensions like clpfd and asp but really if what you're doing is solving a constraint programming problem, you're much better of with OR-tools or MiniZinc.
Prolog is beautiful. I have practically no use for it. I've struggled to find something I can do better with Prolog than other tools, but I just love it aesthetically and that's enough for me sometimes.
There are some useful extensions like clpfd and asp but really if what you're doing is solving a constraint programming problem, you're much better of with OR-tools or MiniZinc.
Prolog is beautiful. I have practically no use for it. I've struggled to find something I can do better with Prolog than other tools, but I just love it aesthetically and that's enough for me sometimes.
I don't know, most things I've written in Prolog 'runs backwards'. Doesn't seem special to me, things like cut and whatnot that might interfere do.
I kind of feel that clpfd, clpz and so on are just libraries, in what way do you consider them extensions to the language?
For me it's a neat way to model problems, and when I have I've commonly learned something new about the problem domain. Performance might not be great, interoperability and FFI might not be great, but as a tool for thought I really think it is.
https://www.metalevel.at/prolog
I kind of feel that clpfd, clpz and so on are just libraries, in what way do you consider them extensions to the language?
For me it's a neat way to model problems, and when I have I've commonly learned something new about the problem domain. Performance might not be great, interoperability and FFI might not be great, but as a tool for thought I really think it is.
https://www.metalevel.at/prolog
In SWI for example, clpfd and friends rely on attribute values and hook predicates to interject the backtracking process with their own thing. SWI provides those things so that it can be extended.
Non trivial Prolog programs which only use pure predicates and do not use cut are sparse. Yet those are also the only circumstances in which things like clpfd will work without special consideration.
Non trivial Prolog programs which only use pure predicates and do not use cut are sparse. Yet those are also the only circumstances in which things like clpfd will work without special consideration.
Besides pengines and web development I have very little experience with SWI specifically.
And, well, yeah, it's common (e.g. look for cuts in https://github.com/mthom/scryer-prolog/blob/master/src/lib/c... ), but I don't think I've ever written a cut and I use Prolog rather effectively as a tool for problem solving. It's an interesting and quite powerful way to model and examine problems even if I don't produce programs with 'imperative' interfaces. Some scripting tasks are also quite easy in Prolog, e.g. certain log parsing, stuff like that.
And, well, yeah, it's common (e.g. look for cuts in https://github.com/mthom/scryer-prolog/blob/master/src/lib/c... ), but I don't think I've ever written a cut and I use Prolog rather effectively as a tool for problem solving. It's an interesting and quite powerful way to model and examine problems even if I don't produce programs with 'imperative' interfaces. Some scripting tasks are also quite easy in Prolog, e.g. certain log parsing, stuff like that.
How would this work with the XOR operator? Would it give all possible inputs?
Would depend on the implementation, I think. You could probably write one like that, but as usual there will be trade-offs. I suspect it would also matter if you're targeting booleans or numbers.
The typical, obvious case how these things work in Prolog is in list concatenation. If you only supply variables it'll start outputting lists of increasing length with placeholder variables. It's a somewhat simple engine for traversing a problem space and testing constraints that uses backtracking to step through it. Some implementations allow you to explicitly change the search strategy.
The typical, obvious case how these things work in Prolog is in list concatenation. If you only supply variables it'll start outputting lists of increasing length with placeholder variables. It's a somewhat simple engine for traversing a problem space and testing constraints that uses backtracking to step through it. Some implementations allow you to explicitly change the search strategy.
It's also biased into informal definitions, mixing side effects with logic, and encapsulating complex behavior together. It's way more biased into being a scripting language, while Haskell has all those biases pointed at being an application language.
So, I'd say that both languages lead people into very different programing styles.
So, I'd say that both languages lead people into very different programing styles.
Great read! Can anyone here recommend a good resource for learning Haskell that's in the style of "Text-Mode Games as First Haskell Projects"? Haskell has been on my radar since forever, and I've got some FP concepts internalized by making a side project in F#, but I have no idea what a monad really is and a fun prohect to code along might be perfect.
I've been learning Unison [1] and I highly recommend. It's a Haskell-like language, but with some really interesting ideas around how code should be managed and distributed. They also use use algebraic effects (represented with "abilities" in Unison) instead of Monads, which gives some interesting advantages [2].
[1] https://www.unison-lang.org/
[2] https://www.unison-lang.org/docs/fundamentals/abilities/for-...
[1] https://www.unison-lang.org/
[2] https://www.unison-lang.org/docs/fundamentals/abilities/for-...
Have you written anything in Unison yet? To me Unison feels extremely ahead of its time. They clearly thought things through and aren't afraid to challenge the status quo. Maybe a bit too much ahead of its time even...
I fear `ucm` a little. You mean I can't version my things with git? How do I... ehh, do anything? And how is the deployment story if one chooses not to use the Unison cloud?
I fear `ucm` a little. You mean I can't version my things with git? How do I... ehh, do anything? And how is the deployment story if one chooses not to use the Unison cloud?
To be honest, all I've done was try the weekly challenges that the Unison team publishes on Twitter :D
I just like the very light syntax that it got from Haskell, but without the need for Monads and the "ugly" monad operators you need to juggle, replaced by abilities which IMHO are much more elegant.
They are focusing on writing cloud-services and apparently their offering is already pretty good, so if I ever need a clouse service I am tempted to use Unison (for anything not very critical, at least until I gain confidence in it): https://www.unison.cloud/our-approach/
And I love ucm and think it may be very close to what the future will look like (which is why I do agree it's ahead of our time). It's already possible to work with Unison but still have proper code review: https://www.unison-lang.org/docs/tooling/project-workflows/#...
Here's an example change: https://share.unison-lang.org/@unison/base/contributions/42/...
But currently, I believe you do need to pull the branch locally and then load diffs with ucm into your favourite diff tool to properly see what's been changed (which is not ideal , and I believe they are working on making this easier, we'll see).
I just like the very light syntax that it got from Haskell, but without the need for Monads and the "ugly" monad operators you need to juggle, replaced by abilities which IMHO are much more elegant.
They are focusing on writing cloud-services and apparently their offering is already pretty good, so if I ever need a clouse service I am tempted to use Unison (for anything not very critical, at least until I gain confidence in it): https://www.unison.cloud/our-approach/
And I love ucm and think it may be very close to what the future will look like (which is why I do agree it's ahead of our time). It's already possible to work with Unison but still have proper code review: https://www.unison-lang.org/docs/tooling/project-workflows/#...
Here's an example change: https://share.unison-lang.org/@unison/base/contributions/42/...
But currently, I believe you do need to pull the branch locally and then load diffs with ucm into your favourite diff tool to properly see what's been changed (which is not ideal , and I believe they are working on making this easier, we'll see).
Can you or someone else familiar with Unison tell us what specific things about Unison feel ahead of its time? I don't know Unison so these things will be a good motivation for me to learn Unison.
Unison tries to swallow the whole elephant all at once, which is probably what the author is getting at.
* `ucm` is like a coding assistant that sits with you the whole time. You don't grep through code to find snippets or anything, you use `ucm`. It does a whole lot more, but that's just the trivial example.
* You need `ucm` because Unison stores code as a syntax tree, not text. This is awesome because versioning/dependency conflicts/rename issues just go away. This is not awesome because nothing else knows how to understand this: other source control systems will just not work.
* It's really trying to drag functional coding into this decade and what we use code for in production. It's not trying to be Haskell which is a great language, but doesn't (to me) feel like it was designed to do something like a simple web app.
* It is supposed to do distributed cloud computing without modification (this smells like where the VC money came from), but again, you have to use their platform because other clouds don't understand Unison.
The list goes on.
Each individual piece of Unison I think is really great. I love the `ucm` model of having an assistant sit next to you the whole time. What I don't love is that there is just _so much_ learning placed on the developer. To understand Unison, you need to understand a lot of what they're doing, a lot of what they are doing is novel, and so you have to eat the whole elephant that they are. I don't know if there was a path where they could have eaten the elephant one bite at a time, but it really makes the onboarding onerous.
* `ucm` is like a coding assistant that sits with you the whole time. You don't grep through code to find snippets or anything, you use `ucm`. It does a whole lot more, but that's just the trivial example.
* You need `ucm` because Unison stores code as a syntax tree, not text. This is awesome because versioning/dependency conflicts/rename issues just go away. This is not awesome because nothing else knows how to understand this: other source control systems will just not work.
* It's really trying to drag functional coding into this decade and what we use code for in production. It's not trying to be Haskell which is a great language, but doesn't (to me) feel like it was designed to do something like a simple web app.
* It is supposed to do distributed cloud computing without modification (this smells like where the VC money came from), but again, you have to use their platform because other clouds don't understand Unison.
The list goes on.
Each individual piece of Unison I think is really great. I love the `ucm` model of having an assistant sit next to you the whole time. What I don't love is that there is just _so much_ learning placed on the developer. To understand Unison, you need to understand a lot of what they're doing, a lot of what they are doing is novel, and so you have to eat the whole elephant that they are. I don't know if there was a path where they could have eaten the elephant one bite at a time, but it really makes the onboarding onerous.
https://learn-haskell.blog/
> In this book, we will implement a simple static blog generator in Haskell, converting documents written in our own custom markup language to HTML.
> We will:
> In this book, we will implement a simple static blog generator in Haskell, converting documents written in our own custom markup language to HTML.
> We will:
Implement a tiny HTML printer library
Define and parse our own custom markup language
Read files and glue things together
Add command line arguments parsing
Write tests and documentation
"Programming in Haskell" by Graham Hutton has a few small text mode games in the second half of the book: Nim, Hangman, the game of life, and Tic-Tac-Toe; and it walks you through the minimax algorithm. The author also implements a solution to the countdown problem, which is hard to explain, so as an example, you're given a sequence of numbers [1, 3, 7, 10, 25, 50] and the target 765; a correct solution is (1+50)*(25-10).
The first half of the book is more geared towards a newbie to functional programming in general.
The first half of the book is more geared towards a newbie to functional programming in general.
Kind of ironically I've enjoyed the 'Write Yourself a Scheme in 48 Hours'[1] which goes over how to write your own Scheme in Haskell. It introduces some of the more interesting monads although I'm not sure how idiomatic it is.
[1] https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_...
[1] https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_...
Haven’t you heard? Monads are burritos!
In all seriousness, it’s not “text mode”, but one of the things that I felt really showed how cool Haskell and a friend could pure model could be a was Netwire and Functional Reactive Programming. It allowed me to design graphical applications the way I always wanted to instead of how they’re typically structured in imperative languages. There are lots of tutorials out there for making little games with it.
In all seriousness, it’s not “text mode”, but one of the things that I felt really showed how cool Haskell and a friend could pure model could be a was Netwire and Functional Reactive Programming. It allowed me to design graphical applications the way I always wanted to instead of how they’re typically structured in imperative languages. There are lots of tutorials out there for making little games with it.
Ugh, autocorrect and it's too late to edit.
I was suggesting the Netwire library, an FRP library for Haskell.
I was suggesting the Netwire library, an FRP library for Haskell.
This may help? (Just an example of a monad pattern in use to build a burrito!)
https://www.williamcotton.com/articles/a-burrito-is-a-monad
https://www.williamcotton.com/articles/a-burrito-is-a-monad
Write a few computation Expression builders in F# and monads will quickly make sense.
Had a lot of fun reading this. I’d love to see some of the author’s code to get a sense what the journey produced, if that’s even possible
What's the benefit of learning a PURE functional programming language, opposed to just using a language which has adapted the best bits and pieces from the functional programming paradigm?
Given that you want write code that sees "real world" use, and is used to handle data and events from the real world. To me, sometimes the line between optimized code and intellectual curiosity blurs.
Given that you want write code that sees "real world" use, and is used to handle data and events from the real world. To me, sometimes the line between optimized code and intellectual curiosity blurs.
> What's the benefit of learning a PURE functional programming language
1. It makes it easy to learn how to structure a program in a pure way, which is hard to do in languages that offers you a easy way out.
2. Since "everything" is pure, writing tests is easier.
3. You know for certain that if you discard the result of a function call, all the side-effects that it would normally trigger would be stopped as well.
4. A program where all side-effects are guaranteed to be pushed to the boundaries, is a program that's easy to reason about.
> a language which has adapted the best bits and pieces [...]
Languages that has adapted to best bits and pieces from X, Y, Z tend to be worse than a language specifically for X, Y and Z.
For instance, Java supports functional programming but functional programming languages are much better at it because they were designed for that specific paradigm. In the same vein, sure you can write pure programs in F#, but not as easily as in Haskell that was designed for doing just that.
> and is used to handle data and events from the real world
Pure code really only means (in practice) that side-effects are controlled, which is generally very helpful. It forces you to structure programs in a way which makes it easy to pinpoint where data is coming in, and where data is going out. It also makes for easier testing.
Being able to know, definetly, the answer to "will calling foo perform a network request" without having to read the source for foo is quite nice, especially when dealing with third-party code.
All this said, I probably wouldn't begin with Haskell. A language like Elm is much better suited for learning writing pure programs.
1. It makes it easy to learn how to structure a program in a pure way, which is hard to do in languages that offers you a easy way out.
2. Since "everything" is pure, writing tests is easier.
3. You know for certain that if you discard the result of a function call, all the side-effects that it would normally trigger would be stopped as well.
4. A program where all side-effects are guaranteed to be pushed to the boundaries, is a program that's easy to reason about.
> a language which has adapted the best bits and pieces [...]
Languages that has adapted to best bits and pieces from X, Y, Z tend to be worse than a language specifically for X, Y and Z.
For instance, Java supports functional programming but functional programming languages are much better at it because they were designed for that specific paradigm. In the same vein, sure you can write pure programs in F#, but not as easily as in Haskell that was designed for doing just that.
> and is used to handle data and events from the real world
Pure code really only means (in practice) that side-effects are controlled, which is generally very helpful. It forces you to structure programs in a way which makes it easy to pinpoint where data is coming in, and where data is going out. It also makes for easier testing.
Being able to know, definetly, the answer to "will calling foo perform a network request" without having to read the source for foo is quite nice, especially when dealing with third-party code.
All this said, I probably wouldn't begin with Haskell. A language like Elm is much better suited for learning writing pure programs.
Agree with all the reasons, but number 1 is really the most important:
> 1. It makes it easy to learn how to structure a program in a pure way, which is hard to do in languages that offers you a easy way out.
When there's an escape hatch, you will reach for it at some point. It helps with getting things done, but you never end up really confronting the hard things when you have that, and the hard things are an important part of the learning/benefit.
> 1. It makes it easy to learn how to structure a program in a pure way, which is hard to do in languages that offers you a easy way out.
When there's an escape hatch, you will reach for it at some point. It helps with getting things done, but you never end up really confronting the hard things when you have that, and the hard things are an important part of the learning/benefit.
The problem with Haskell is that it's slow and memory-heavy (and OCaml is the same, but worse). F# and Scala (and Clojure?) are pretty much the only reasonably usable FP languages.
Where are you getting your info from?
Typical OCaml programs, when compared to similar C++ would be slower but use less memory.
F# and Scala are both OCaml in disuse. I don't know what you mean by "reasonable"... but, if the idea is "easy to reason about", then these two don't particularly stand out much.
Languages that are easy to reason about would be generally in the category where you need to do fewer translations before you get to the way the program is executed (i.e. bytecode adds an extra step, thus making a language harder to reason about). Also, languages with fewer primitives are easier to reason about, because the program text becomes more predictable.
In general, "functional" languages are harder to reason about when compared to imperative, because computers inherently don't work in the way the programs are modeled in "functional" languages, so there will be some necessary translation layer that transforms an FP program into a real computer program. There are people who believe that FP programs are easier to reason about due to the lack of side effects. In my experience, the lack of side effects doesn't come close to compensating the advantages of being able to map the program to what computer actually does.
All kinds of behind-the-scenes mechanisms in the language, s.a. garbage collector, make the reasoning harder too, in a sense. We pretend that GC makes reasoning easier by making a mental shortcut: we pretend that it doesn't matter when memory is freed. But, if you really want a full picture, GC adds a whole new layer of complexity when it comes to understanding a program.
Yet another aspect of reasoning is the ability of reasoner to act on their reasoning. I.e. the reasoning might be imperfect, but still allow to act (which is kind of the human condition, the way we are prepared to deal with the world). So, often, while imperative programs cannot be formally easily reasoned about, it's easy to informally reason about them to be efficient enough to act on that reasoning. "Functional" programs are usually the reverse: they are easier to reason about formally, but they are very unnatural to the way humans reason about everyday stuff, so, acting on them is harder for humans.
"Functional" languages tend to be more in the bytecode + GC + multiple translations camp. And, if forced to choose with these constrains, I'd say Erlang would be the easiest and the best designed language of all the "popular" ones. SML would be my pick if you need to get into the world of Haskell, but deciphering Haskell syntax brings you to the boil.
Typical OCaml programs, when compared to similar C++ would be slower but use less memory.
F# and Scala are both OCaml in disuse. I don't know what you mean by "reasonable"... but, if the idea is "easy to reason about", then these two don't particularly stand out much.
Languages that are easy to reason about would be generally in the category where you need to do fewer translations before you get to the way the program is executed (i.e. bytecode adds an extra step, thus making a language harder to reason about). Also, languages with fewer primitives are easier to reason about, because the program text becomes more predictable.
In general, "functional" languages are harder to reason about when compared to imperative, because computers inherently don't work in the way the programs are modeled in "functional" languages, so there will be some necessary translation layer that transforms an FP program into a real computer program. There are people who believe that FP programs are easier to reason about due to the lack of side effects. In my experience, the lack of side effects doesn't come close to compensating the advantages of being able to map the program to what computer actually does.
All kinds of behind-the-scenes mechanisms in the language, s.a. garbage collector, make the reasoning harder too, in a sense. We pretend that GC makes reasoning easier by making a mental shortcut: we pretend that it doesn't matter when memory is freed. But, if you really want a full picture, GC adds a whole new layer of complexity when it comes to understanding a program.
Yet another aspect of reasoning is the ability of reasoner to act on their reasoning. I.e. the reasoning might be imperfect, but still allow to act (which is kind of the human condition, the way we are prepared to deal with the world). So, often, while imperative programs cannot be formally easily reasoned about, it's easy to informally reason about them to be efficient enough to act on that reasoning. "Functional" programs are usually the reverse: they are easier to reason about formally, but they are very unnatural to the way humans reason about everyday stuff, so, acting on them is harder for humans.
"Functional" languages tend to be more in the bytecode + GC + multiple translations camp. And, if forced to choose with these constrains, I'd say Erlang would be the easiest and the best designed language of all the "popular" ones. SML would be my pick if you need to get into the world of Haskell, but deciphering Haskell syntax brings you to the boil.
> Languages that are easy to reason about would be generally in the category where you need to do fewer translations before you get to the way the program is executed
This is a very interesting definition of "easy to reason about".
To me, "easy to reason about" means that it's easy for me to figure out what the intent of the code is, and how likely it is that the code does what it was intended to do.
How it translates to the machine is irrelevant.
Now, if you work in an environment where getting the most out of the machine is crucial, then I understand. In my domain, though, dealing with things like allocating and freeing memory makes it harder to see what the code is supposed to do. As a human, I don't think about which memory to store where and when that memory should be forgotten, I just act on memories.
Functional languages, then, tend to be high level enough to not expose you to the workings of the machine, which let's me focus on what I actually want to do.
This is a very interesting definition of "easy to reason about".
To me, "easy to reason about" means that it's easy for me to figure out what the intent of the code is, and how likely it is that the code does what it was intended to do.
How it translates to the machine is irrelevant.
Now, if you work in an environment where getting the most out of the machine is crucial, then I understand. In my domain, though, dealing with things like allocating and freeing memory makes it harder to see what the code is supposed to do. As a human, I don't think about which memory to store where and when that memory should be forgotten, I just act on memories.
Functional languages, then, tend to be high level enough to not expose you to the workings of the machine, which let's me focus on what I actually want to do.
Heh, no.
You are suggesting to replace FP languages with powerful type systems that perform marginally slower than C# and Java (and can access their ecosystems) with a language that is dynamically typed and performs, in most situations, marginally slower than PHP and marginally faster than Ruby.
You are suggesting to replace FP languages with powerful type systems that perform marginally slower than C# and Java (and can access their ecosystems) with a language that is dynamically typed and performs, in most situations, marginally slower than PHP and marginally faster than Ruby.
Every language is both statically and dynamically typed. But the more correct way of saying this is "dynamically or statically checked". Types don't appear or disappear when a program runs. The difference is in what can be known about types and at what stage.
What programmers actually care about is this:
How can we check more and sooner in a way that requires less mental energy on the side of the programmer to write?
In other words, we have three variables we want to optimize for: how much is checked, how much is checked before execution, how much effort does it take to write the check. When people argue for "statically or dynamically typed languages", they generally don't understand what they argue for (or against), as they don't have this kind of mental model in mind (they just learned the terms w/o clear understanding of what they mean).
And so do you.
So, I don't really know what do you mean when you say "dynamically typed". Which language is that? Are you talking about Erlang? SML? What aspect of the language are you trying to describe?
NB. I don't think either C# or Java have good type systems. My particular problem with these is subtyping, which is also a problem in OCaml and derivatives s.a. Scala or F#. It's not a solution anyone wanted, it's a kludge that was added into these systems to deal with classes and objects. So, if we are going after good type systems... well, it wouldn't be in any language with objects, that's for sure.
NB2. Unix Shell has a great type system. Everything is a string. It's a pleasure to work with, and you don't even need a type checker! For its domain, it seems like a perfect compromise between the three optimization objectives.
What programmers actually care about is this:
How can we check more and sooner in a way that requires less mental energy on the side of the programmer to write?
In other words, we have three variables we want to optimize for: how much is checked, how much is checked before execution, how much effort does it take to write the check. When people argue for "statically or dynamically typed languages", they generally don't understand what they argue for (or against), as they don't have this kind of mental model in mind (they just learned the terms w/o clear understanding of what they mean).
And so do you.
So, I don't really know what do you mean when you say "dynamically typed". Which language is that? Are you talking about Erlang? SML? What aspect of the language are you trying to describe?
NB. I don't think either C# or Java have good type systems. My particular problem with these is subtyping, which is also a problem in OCaml and derivatives s.a. Scala or F#. It's not a solution anyone wanted, it's a kludge that was added into these systems to deal with classes and objects. So, if we are going after good type systems... well, it wouldn't be in any language with objects, that's for sure.
NB2. Unix Shell has a great type system. Everything is a string. It's a pleasure to work with, and you don't even need a type checker! For its domain, it seems like a perfect compromise between the three optimization objectives.
What's the benefit?
You start to see functions as self-contained things, as lego blocks. All the logic of the function is there in the function. It only works on values it receives as inputs (it can't read global variables). It only outputs its results (it doesn't assign them to some other global variable that you have to track down).
This makes your code modular. You can add a function in a chain of functions, if you want to perform an extra transformation. Or, you can replace a function with a different one, if you want to change something about the logic.
You start to see functions as self-contained things, as lego blocks. All the logic of the function is there in the function. It only works on values it receives as inputs (it can't read global variables). It only outputs its results (it doesn't assign them to some other global variable that you have to track down).
This makes your code modular. You can add a function in a chain of functions, if you want to perform an extra transformation. Or, you can replace a function with a different one, if you want to change something about the logic.
Is there a benefit if you're already familiar with writing functions like that? Is it wrong for me to expect that most programmers are already familiar with functions that only use their inputs, but treat that style as significantly more optional?
I wrote pure functions for a minute there but that's not the same, a function that only uses its inputs can modify an object while a pure function would have to return a new object. But, similarly, I bet that a lot more people know about pure functions than have any working knowledge of Haskell.
I wrote pure functions for a minute there but that's not the same, a function that only uses its inputs can modify an object while a pure function would have to return a new object. But, similarly, I bet that a lot more people know about pure functions than have any working knowledge of Haskell.
It seems you only focused on one of the conditions I mentioned.
You have to follow both rules: the one about inputs and the one about outputs.
This is like a contract. If you enforce it throughout your program, you gain some guarantees about your program as a whole.
You have to follow both rules: the one about inputs and the one about outputs.
This is like a contract. If you enforce it throughout your program, you gain some guarantees about your program as a whole.
I was looking at both rules, and specifically I was using the long version where you said "it doesn't assign them to some other global variable that you have to track down". If you pass in a mutable object then that's not "some other global variable".
If I interpret "It only outputs its results" in a very strict way, that still allows having output and in/out parameters. The latter of which can break purity.
Though you can break purity with just inputs:
If I interpret "It only outputs its results" in a very strict way, that still allows having output and in/out parameters. The latter of which can break purity.
Though you can break purity with just inputs:
define f(o): return o.x
let a = {x=1}
f(a)
a.x = 2
f(a)
So, another definition of a pure function is that, for a particular input it will always return the same output.
Your example respects the rule:
Starting from the question that gave birth to this whole thread: "What's the benefit of learning a PURE functional programming language..."
The other benefit is that such a language forces you to be explicit about I/O. It does it in such a way that even functions that do I/O are pure. The good part is that, if you use it long enough, it can teach you the discipline to be explicit about I/O and you can use this discipline in other languages.
For example, this is how I see this principles being used in Python:
https://elbear.com/functional-programming-principles-you-can...
Your example respects the rule:
f({x=1}) == 1
f({x=2}) == 2
Starting from the question that gave birth to this whole thread: "What's the benefit of learning a PURE functional programming language..."
The other benefit is that such a language forces you to be explicit about I/O. It does it in such a way that even functions that do I/O are pure. The good part is that, if you use it long enough, it can teach you the discipline to be explicit about I/O and you can use this discipline in other languages.
For example, this is how I see this principles being used in Python:
https://elbear.com/functional-programming-principles-you-can...
> Your example respects the rule:
Every definition of purity I can find that talks about objects/references says that if you pass in the same object/reference with different contents then that's not pure.
Your version differs from mine on that aspect. It passes two unrelated objects.
> Starting from the question that gave birth to this whole thread: "What's the benefit of learning a PURE functional programming language..."
I interpret saying a language is "purely functional" as being more about whether you're allowed to write anything that isn't functional. I can talk about BASIC being a "purely iterative" language or about "pure assembly" programs, without any implication of chunks of code being pure.
Every definition of purity I can find that talks about objects/references says that if you pass in the same object/reference with different contents then that's not pure.
Your version differs from mine on that aspect. It passes two unrelated objects.
> Starting from the question that gave birth to this whole thread: "What's the benefit of learning a PURE functional programming language..."
I interpret saying a language is "purely functional" as being more about whether you're allowed to write anything that isn't functional. I can talk about BASIC being a "purely iterative" language or about "pure assembly" programs, without any implication of chunks of code being pure.
I gave it some more thought.
I now believe that learning a language like Haskell (or Elm or PureScript) forces you to see your program as pipes that you fuse together.
It's not just functions. Haskell has only expressions and declarations. That means, for example, that you are forced to provide an `else`, when you use `if`. The idea is that you have to keep the data flowing. If a function doesn't provide a meaningful value (so it returns nil, None), you have to handle that explicitly.
And, btw
> Your version differs from mine on that aspect. It passes two unrelated objects.
Those two objects are not unrelated. They have the exact same structure (an attribute named "x"). So they could be considered two values of the same type.
I now believe that learning a language like Haskell (or Elm or PureScript) forces you to see your program as pipes that you fuse together.
It's not just functions. Haskell has only expressions and declarations. That means, for example, that you are forced to provide an `else`, when you use `if`. The idea is that you have to keep the data flowing. If a function doesn't provide a meaningful value (so it returns nil, None), you have to handle that explicitly.
And, btw
> Your version differs from mine on that aspect. It passes two unrelated objects.
Those two objects are not unrelated. They have the exact same structure (an attribute named "x"). So they could be considered two values of the same type.
I mean that the identity is unrelated. Yes, you can say they're the same type. But I'm actually passing the same object in. If f evaluated lazily, it could return 2 from both calls. Something like:
define f(o): return o.x
let a = {x=1}
n = f(a) // n is not evaluated yet
a.x = 2
m = f(a)
return n + m // returns 4Ok, you're probably proving the point that purity also requires immutability. I'm not sure, as I haven't considered all the implications of Haskell's design.
My two rules about inputs and outputs are more like heuristics. They can improve code organisation and probably also decrease the likelihood of some errors, but they don't guarantee correctness, as you're pointing out. They're shortcuts, so they're not perfect.
Edit: If I remember right, it's laziness that requires immutability. I think I read something about this in the Haskell subreddit as an explanation for Haskell's design.
My two rules about inputs and outputs are more like heuristics. They can improve code organisation and probably also decrease the likelihood of some errors, but they don't guarantee correctness, as you're pointing out. They're shortcuts, so they're not perfect.
Edit: If I remember right, it's laziness that requires immutability. I think I read something about this in the Haskell subreddit as an explanation for Haskell's design.
Even without laziness, you can get similar problems if f creates a closure or returns something that includes the parameter object.
Ok, the Wikipedia definition of pure function is more strict and than what I was saying and I think it covers the issues you mentioned:
https://en.wikipedia.org/wiki/Pure_function
https://en.wikipedia.org/wiki/Pure_function
Yeah, this is a common source of confusion with closures in Python. Example on Stack Overflow:
https://stackoverflow.com/questions/233673/how-do-lexical-cl...
https://stackoverflow.com/questions/233673/how-do-lexical-cl...
Purely functional language is pretty universally taken to mean that the language enforces function purity for all functions [perhaps with some minor escape hatches like Haskell's unsafePerformIO].
> Is it wrong for me to expect that most programmers are already familiar with functions that only use their inputs
They'll experience no friction when using Haskell then. Haskell only refuses to compile when you declare "Oh yeah I know functions from other languages this is easy" but then do some mutation in your implementation.
They'll experience no friction when using Haskell then. Haskell only refuses to compile when you declare "Oh yeah I know functions from other languages this is easy" but then do some mutation in your implementation.
> They'll experience no friction when using Haskell then.
The question was what benefit you'd get from learning a functional language, though. Existing knowledge making it easier to switch to a functional language is the inverse of that.
And there's no assumption they'll actually be making things in Haskell, so easy switching isn't by itself a benefit.
The question was what benefit you'd get from learning a functional language, though. Existing knowledge making it easier to switch to a functional language is the inverse of that.
And there's no assumption they'll actually be making things in Haskell, so easy switching isn't by itself a benefit.
Yeah I can't really follow these threads.
I saw:
> What's the benefit of learning a PURE functional programming language, opposed to just using a language which has adapted the best bits and pieces from the functional programming paradigm?
I also saw:
I guess if you learn a functional language "which has adapted the best bits and pieces from the functional programming paradigm" then you might think that the above is broken purity, but if you learn a "PURE functional programming language" then you wouldn't.
I saw:
> What's the benefit of learning a PURE functional programming language, opposed to just using a language which has adapted the best bits and pieces from the functional programming paradigm?
I also saw:
Though you can break purity with just inputs:
define f(o): return o.x
let a = {x=1}
f(a)
a.x = 2
f(a)
I guess if you learn a functional language "which has adapted the best bits and pieces from the functional programming paradigm" then you might think that the above is broken purity, but if you learn a "PURE functional programming language" then you wouldn't.
The topic is what you would learn from a pure functional language.
A) You can learn and enforce full purity in other languages. B) You could also learn and adapt just the idea of clean inputs and outputs to those other languages.
Both of those are valid answers! It's very hard to be completely pure if you're not currently using Haskell.
The way they worded things, I wasn't sure which one they meant. They were describing option B, but I didn't know if that was on purpose or not.
So I responded talking about both. Complete purity and just the idea of clean inputs and outputs.
That code snippet is not some kind of absurd argument or strawman, it's there to demonstrate how the description they gave was not a description of purity. It's not aimed at the original question.
A) You can learn and enforce full purity in other languages. B) You could also learn and adapt just the idea of clean inputs and outputs to those other languages.
Both of those are valid answers! It's very hard to be completely pure if you're not currently using Haskell.
The way they worded things, I wasn't sure which one they meant. They were describing option B, but I didn't know if that was on purpose or not.
So I responded talking about both. Complete purity and just the idea of clean inputs and outputs.
That code snippet is not some kind of absurd argument or strawman, it's there to demonstrate how the description they gave was not a description of purity. It's not aimed at the original question.
This is all myth. People don't write Haskell, because they read why other non-Haskellers also don't write Haskell, based on what other non-Haskellers wrote.
> a language which has adapted the best bits and pieces from the functional programming paradigm?
Why write in a statically-typed language when dynamically-typed languages have adapted the best bits and pieces from statically-typed languages?
> a language which has adapted the best bits and pieces from the functional programming paradigm?
Why write in a statically-typed language when dynamically-typed languages have adapted the best bits and pieces from statically-typed languages?
> Why write in a statically-typed language when dynamically-typed languages have adapted the best bits and pieces from statically-typed languages?
Unfortunately, dynamically-typed languages haven't adapted the best bit from statically-typed languages: that all types are enforced at compile-time!
Unfortunately, dynamically-typed languages haven't adapted the best bit from statically-typed languages: that all types are enforced at compile-time!
Yep, that's the parallel I was going for.
Functional languages give you the same output for the same input, and almost-functional languages ... probably give you the same output for the same input?
Functional languages give you the same output for the same input, and almost-functional languages ... probably give you the same output for the same input?
Don't think of it as being all pure code, think of it as tracking in the type system which parts of your code may launch the missiles and which parts can't. Given the following program,
This also nudges you in the direction of an Functional Core, Imperative Shell architecture https://www.destroyallsoftware.com/screencasts/catalog/funct...
main :: IO ()
main = do
coordinates <- getCoords
launch trajectory
where
trajectory = calcTrajectory coordinates
getCoords :: IO Coordinates
getCoords = -- TODO
launch :: Trajectory -> IO ()
launch = -- TODO
calcTrajectory :: Coordinates -> Trajectory
calcTrajectory = -- TODO
This also nudges you in the direction of an Functional Core, Imperative Shell architecture https://www.destroyallsoftware.com/screencasts/catalog/funct...
>as tracking in the type system which parts of your code may launch the missiles
given that Haskell is lazy by default there's a million ways to shoot yourself in the foot through memory leaks and performance issues (which is not unlike the problems the IO type attempts to make explicit in that domain), so I never really understand this kind of thing. Purity doesn't say much about safety or semantics of your code. By that logic you might as well introduce a recursion type and now you're tagging everything that is recursive because you can easily kill your program with an unexpected input in a recursive function. To me this is just semantics you have to think through anyway, putting this into the type system just ends up creating more convoluted programs.
given that Haskell is lazy by default there's a million ways to shoot yourself in the foot through memory leaks and performance issues (which is not unlike the problems the IO type attempts to make explicit in that domain), so I never really understand this kind of thing. Purity doesn't say much about safety or semantics of your code. By that logic you might as well introduce a recursion type and now you're tagging everything that is recursive because you can easily kill your program with an unexpected input in a recursive function. To me this is just semantics you have to think through anyway, putting this into the type system just ends up creating more convoluted programs.
Haskell interfaces with the real world. ST allows for mutability in pure context
https://github.com/serprex/Fractaler/blob/master/Fractaler.h... fractal renderer I wrote in highschool, has mouse controls for zoom / selecting a variety of fractals
https://github.com/serprex/bfhs/blob/master/bf.hs brainfuck interpreter which mostly executes in pure context, returning stdout with whether program is done or should be reinvoked with character input. Brainfuck tape implemented as zipper
your program may exist in real world, but most of it doesn't care about much of the real world
https://github.com/serprex/Fractaler/blob/master/Fractaler.h... fractal renderer I wrote in highschool, has mouse controls for zoom / selecting a variety of fractals
https://github.com/serprex/bfhs/blob/master/bf.hs brainfuck interpreter which mostly executes in pure context, returning stdout with whether program is done or should be reinvoked with character input. Brainfuck tape implemented as zipper
your program may exist in real world, but most of it doesn't care about much of the real world
There's a video game on steam you can buy with real dollars built in Haskell.
I work full-time writing Haskell. Fintech stuff. No shiny research going on here.
I've written some libraries and programs on my stream in Haskell. One is a client library for Postgres' streaming logical replication protocol. I've written a couple of games. Working on learning how to do wave function collapse.
Believe it or not, functional programmers -- even ones writing Haskell -- often think about and deliver software for "real world," use.
I work full-time writing Haskell. Fintech stuff. No shiny research going on here.
I've written some libraries and programs on my stream in Haskell. One is a client library for Postgres' streaming logical replication protocol. I've written a couple of games. Working on learning how to do wave function collapse.
Believe it or not, functional programmers -- even ones writing Haskell -- often think about and deliver software for "real world," use.
> There's a video game on steam you can buy with real dollars built in Haskell.
Link? Story?
Link? Story?
> Given that you want write code that sees "real world" use, and is used to handle data and events from the real world.
Real world? As opposed to what?
Is there any benefit to answering such polemical questions as if they are not rhetorical?
Real world? As opposed to what?
Is there any benefit to answering such polemical questions as if they are not rhetorical?
As opposed to the abstract academic world?
The only time I had contact with Haskell was in university and I did not see it appealing back then, nor now, nor have I ever seen a program that I use, written in it.
So learning a bit of pure Haskell might have been beneficial for me to become a better programmer, but I still fail to see it being more than that - a academic language. Useful for didactic purposes. Less to actually ship software.
The only time I had contact with Haskell was in university and I did not see it appealing back then, nor now, nor have I ever seen a program that I use, written in it.
So learning a bit of pure Haskell might have been beneficial for me to become a better programmer, but I still fail to see it being more than that - a academic language. Useful for didactic purposes. Less to actually ship software.
> nor have I ever seen a program that I use, written in it
The only mass market Haskell software that I know of is Pandoc. Others like Shellcheck and Postgrest are popular in their niche.
I am not sure that Haskell is faring worse that other programming languages in its level of popularity, like Julia, Clojure or Erlang.
The only mass market Haskell software that I know of is Pandoc. Others like Shellcheck and Postgrest are popular in their niche.
I am not sure that Haskell is faring worse that other programming languages in its level of popularity, like Julia, Clojure or Erlang.
Pandoc seems useful, but maybe "mass market" is a bit of an overstatement?
And since many programmers like myself had to learn Haskell, I think Haskell should have a better head start and be in a better position, if it would be so useful for "real world" use cases.
But please don't take this as an attack on haskell. I have nothing against the language, or its users and I did not suffered because of it in university, I am just curious on the appeal. Because I love clean solutions, but I also want to ship things. So part of me are wondering if I am missing out, but I so far I see not much convincing data. (But I am also mainly interested in high performance and real time graphics and haskell is really not the best here)
And since many programmers like myself had to learn Haskell, I think Haskell should have a better head start and be in a better position, if it would be so useful for "real world" use cases.
But please don't take this as an attack on haskell. I have nothing against the language, or its users and I did not suffered because of it in university, I am just curious on the appeal. Because I love clean solutions, but I also want to ship things. So part of me are wondering if I am missing out, but I so far I see not much convincing data. (But I am also mainly interested in high performance and real time graphics and haskell is really not the best here)
Pandoc is the standard for markdown conversion. Check out the comments in this recent thread (or pretty much any thread where markdown is mentioned):
https://news.ycombinator.com/item?id=40695628
https://hn.algolia.com/?q=markdown
https://news.ycombinator.com/item?id=40695628
https://hn.algolia.com/?q=markdown
I don't think markdown conversion is a mass market application, but maybe personally I will indeed use it soon, so that would be something I guess ..
You originally asked about a program that you use (or would use?) written in Haskell. Someone brought up Pandoc, the swiss army knife of Markdown and similar formats, and every programmer uses Markdown in some capacity. Then you chose to fixate on the phrase “mass market” software, as if that was relevant to your original claim: a program that a programmer would use.
Which demonstrates my point. Someone with this attitude has already dug their heels in and made up their mind.
Which demonstrates my point. Someone with this attitude has already dug their heels in and made up their mind.
I am not a user of the language (although I learned it like you). I just came to chime in that (a) there is at least one very popular software written in Haskell and (b) Haskell seems to ship a good amount of software for its popularity.
Haskell never got the “killer framework” like Rails or Spark that allowed to become more mainstream, even if it was teached in Universities all over the world.
Haskell never got the “killer framework” like Rails or Spark that allowed to become more mainstream, even if it was teached in Universities all over the world.
"Haskell never got the “killer framework” like Rails or Spark that allowed to become more mainstream"
But why is that the case?
Thinking about writing a "killer framework" with huskell gives me a headache. Doing UI in huskell? Eventloop? Callbacks? Is that even possible, without doing awkward workarounds?
But why is that the case?
Thinking about writing a "killer framework" with huskell gives me a headache. Doing UI in huskell? Eventloop? Callbacks? Is that even possible, without doing awkward workarounds?
Haskell has yesod, which is Haskell’s Rails. It’s a batteries included web app scaffold. You still need to understand monads, though. But any Haskell shop with web apps is using that.
There’s also scotty and servant for web server stuff.
There’s Esqueleto and Persistent for doing postgreSQL database queries.
And so on.
There’s also scotty and servant for web server stuff.
There’s Esqueleto and Persistent for doing postgreSQL database queries.
And so on.
Yesod seems interesting indeed.
Even though they are biased:
"From a purely technical point of view, Haskell seems to be the perfect web development tool."
But I skimmed the tutorials and can say, I am really not surprised, why it did not take off.
The perfect web developement tool is simple in my opinion. Yesod isn't.
Even though they are biased:
"From a purely technical point of view, Haskell seems to be the perfect web development tool."
But I skimmed the tutorials and can say, I am really not surprised, why it did not take off.
The perfect web developement tool is simple in my opinion. Yesod isn't.
I took a look at Yesod and looks more like Haskell’s Sinatra and comes 6 years later than Rails, in 2010. By 2010 a simple web frameworm is table stakes, no huge differentiator.
I can't speak for others, but I never really understood the benefits of functional programming when my language pretty much allowed unbounded mutation anywhere. I would say there's a chance for impure languages to impede you in learning what functional programming is about (or at least my experience with F# and OCaml did not really help as much as it otherwise could have I think).
Your mileage might vary, but I've heard advice from others to learn Haskell and "go off the deep-end" because of people citing similar reasons.
Your mileage might vary, but I've heard advice from others to learn Haskell and "go off the deep-end" because of people citing similar reasons.
In a way, one benefit is the whole ecosystem / culture / idioms built on top. Haskellers went further in that direction than most languages (except maybe scalaz and some hardcore typescript devs).
Pure functional programming doesn't preclude side-effects like IO; it makes side-effects explicit rather than implicit!
At my previous job, we used pure functional programming to ensure that custom programs only had access to certain side-effects (most importantly, not IO). This meant that it was trivial to run these custom programs in multiple environments, including various testing environments, and production.
At my previous job, we used pure functional programming to ensure that custom programs only had access to certain side-effects (most importantly, not IO). This meant that it was trivial to run these custom programs in multiple environments, including various testing environments, and production.
In my experience, I only really learned how to write small functions after Haskell. The discipline it forces on you is a good training.
When Haskell was a hot topic around two decades ago, ML was also quite often discussed. Today ML almost only means machine learning
That's what I remember from my Computer Science classes 2001-2002. Standard ML was hard to learn back then for a newbie especially a Computer Science newbie.
ML exists today as OCaml and F#
"What fascinated me about Haskell when I was still a teenager? Who knows. I had been coding with increasing enthusiasm since I was 10 or 11 but I was no wunderkind. I certainly hadn’t attained anything like the skill or, more importantly, taste I had after just a few years in the working world. What I like about it today is that it’s quite natural to program in Haskell by building a declarative model of your domain data, writing pure functions over that data, and interacting with the real world at the program’s boundaries. That’s my favorite way to work, Haskell or not."
I adore these sentences.:)When I read it,it feels like I met myself.
I adore these sentences.:)When I read it,it feels like I met myself.
"It’s quite natural to program in Haskell by building a declarative model of your domain data, writing pure functions over that data, and interacting with the real world at the program’s boundaries. That’s my favorite way to work, Haskell or not."
Are there any good resources you can share to learn this specific way of programming?
Are there any good resources you can share to learn this specific way of programming?
https://pragprog.com/titles/swdddf/domain-modeling-made-func..., even though it's F# rather than Haskell. And maybe https://leanpub.com/algebra-driven-design depending on the exact use case.
Yes, it's better to spend 15 years to learn Haskell than keep creating messy imperative programs without knowing how to improve.
Sure, lord it over the rest of us peons. We can’t all be overachievers, you know.
"It’s quite natural to program in Haskell by building a declarative model of your domain data, writing pure functions over that data, and interacting with the real world at the program’s boundaries. That’s my favorite way to work, Haskell or not."
Haskell can be intimidating, though, so I would recommend F# for most beginners. It supports OOP and doesn't require every single function to be pure, so the learning curve is less intense, but you end up absorbing the same lesson as above.