For those who really want to blow their mind, I suggest learning Coq instead https://softwarefoundations.cis.upenn.edu/
What I Wish I Knew When Learning Haskell
131–140 of 149 posts
Re: What I Wish I Knew When Learning Haskell
#132Earlier quoted context omitted.
Because these language wars are mostly about people defending their group identity that they've invested a lot of effort into forming. If you want to have focused, fact-based discussions about language tradeoffs, it's more likely to be successful if you stick to small groups of people who are mindful of their egos.
This is a fact-based discussion of language trade-offs. The strength of a statically typed functional language, that you are forced to specify correctness of the program at increasingly abstract levels of the type system, is also its downfall because this is inherently inflexible if the business use case of that software suddenly demands incrementally mutating some part or introducing subtle violations of the constra…
The GP meant that the comment was downvoted because of "language wars" downvoters, not that it was language-wary itself. It did take me two readings to realize that, because I was going in with my own bias.
Re: What I Wish I Knew When Learning Haskell
#133If you're thinking of learning Haskell you should consider the software written in haskell as an indicator of, well, something. List all the programs useful for something other than programming a computer written in haskell: Xmonad window manager Git annexe Pandoc What else, let's get the full list. Exclude anything that we can't directly see or use. I say, yes! Learn Haskell! Just don't expect to write any useful pr…
Look at all these hundreds of companies who use Haskell to write apparently useless software. https://haskellcosm.com/
Look at the thousands of people who learned Haskell and then also felt inspired to write a monad tutorial and publish it on the internet. Your search engine will help to see just how many there are.
Contrast with the number of useful applications you can actually install and run that are for some purpose that is not programming.
In fact there are more Haskell textbooks you can read than haskell programs you can install (excluding programs for programming - because that's some pyramid scheme vibe there).
This tells us something, I didn't even suggest what it tells us. What it suggests to you is what you thought of.
And fwiw imho pandoc is extremely useful! And Haskell is great fun and worth your time to learn!
What have you written in haskell that we can use?
Re: What I Wish I Knew When Learning Haskell
#134A few years ago I accidentally deleted my entire Haskell assignment about 1 day before it was due. Within a few hours I rebuilt it from scratch. That's when I realized the power of functional programming. There's no way I have been able to recover that quickly if I had used an imperative programming language. Since that experience I've tried to follow a functional programming style whenever I can. I've realized that…
But it was a programming assignment. Building a thing fast is, outside of very few situations, not a thing to optimize for. Building something to be maintained and evolved over time by non rockstars is far far more important, IMO. Perl is great for ripping through some script quickly but it has problems for long term maintenance.
It's definitely possible to write "boring Haskell". getting fancy is more of a cultural tendency than a necessity when building things with Haskell.
https://www.snoyman.com/blog/2019/11/boring-haskell-manifest...
Re: What I Wish I Knew When Learning Haskell
#135Earlier quoted context omitted.
What I think he meant is more like "either do things the functional Haskell way or you don't do them", as in, there is no non-functional fallback or alternative in the language, which some functional languages have.
There's escape hatches here and there. If you need imperative code, use IO or ST. If you need to debug output something, Debug.Trace. If you need to temporarily bypass purity there's unsafePerformIO and friends (or they can occasionally be used permanently if you do a lot of analysis I believe). It's a pretty practical language compared to its reputation.
Sure, IO and ST are escape hatches, but they're not escape hatches that beginners struggling with the concept of a higher order function are going to be able to use.
Re: What I Wish I Knew When Learning Haskell
#136Earlier quoted context omitted.
There's escape hatches here and there. If you need imperative code, use IO or ST. If you need to debug output something, Debug.Trace. If you need to temporarily bypass purity there's unsafePerformIO and friends (or they can occasionally be used permanently if you do a lot of analysis I believe). It's a pretty practical language compared to its reputation.
Actually, someone said, “Haskell is the world’s best imperative programming language.”
Somebody said it, but it's glib, and not particularly true. I believe it was a comment on do notation, the bind operation, and programmable semicolons. The customizability is definitely cool, but nobody could possibly argue that imperative programming in Haskell is ergonomic.
Re: What I Wish I Knew When Learning Haskell
#137Earlier quoted context omitted.
Both of your questions have the same answer. (x:xs) means x is the first element and xs is the rest.
Aha! Thanks. Obviously picking first element as pivot makes for a very poor Quicksort. Though I presume a better approach, say median of first, mid and last elements, would add but an extra line?
The reason the first element is used as the pivot is that these are linked lists, not arrays, so it would take linear time to access the middle and end. This isn't a real quicksort.
Re: What I Wish I Knew When Learning Haskell
#138Earlier quoted context omitted.
> yet is an area where functional languages are uniquely poorly suited Can you clarify if you mean that the type system gets in the way here, or the same would apply to even dynamically typed functional languages? I'm trying to understand if you think a static type system is the hindrance here, or the language being functional in paradigm.
Type system designs in statically typed functional languages are intended to represent increasingly abstract correctness constraints by transforming the business logic of the problem at hand into rules subject to the validation of the compiler. This is quite different than object oriented or even compiled imperative languages where type system constructs contain data and function units that represent internalized con…
Sounds like you would be better suited using some form of dependently typed system as far as type systems go.
If I understand you correctly now, a functional language with no real type system (and thus no such compiler enforced constraints) like Elixir would be imperative in your book and therefore more suitable to facilitate constantly changing business requirements.
Thanks for taking the time to detail your thoughts for me!
Re: What I Wish I Knew When Learning Haskell
#139Earlier quoted context omitted.
Because these language wars are mostly about people defending their group identity that they've invested a lot of effort into forming. If you want to have focused, fact-based discussions about language tradeoffs, it's more likely to be successful if you stick to small groups of people who are mindful of their egos.
This is a fact-based discussion of language trade-offs. The strength of a statically typed functional language, that you are forced to specify correctness of the program at increasingly abstract levels of the type system, is also its downfall because this is inherently inflexible if the business use case of that software suddenly demands incrementally mutating some part or introducing subtle violations of the constra…
> This is a fact-based discussion of language trade-offs.
I'm sorry, but it's an opinion-based discussion. No hard facts were presented here. While I see the reasoning behind such opinion, it directly contradicts opinion of pure FP proponents and somewhat contradicts my own experience.
> the business use case of that software suddenly demands incrementally mutating some part or introducing subtle violations of the constraints the system was designed to enforce
Sure, sometimes it's very convenient to add quick hacks, but there is definitely a tradeoff from maintainability perspective. I wouldn't like to work on a codebase full of mutable state and constraints broken in unprincipled ways. On the other hand, I never used Haskell and religiously functional Scala, so maybe I underestimate the scale of the problem. For me Scala with immutable collections, ADT, lenses, IO, typealiases and typeclasses as extension mechanism served extremely well. Could you please provide few concrete examples of type system abuse?
Re: What I Wish I Knew When Learning Haskell
#140Earlier quoted context omitted.
Look at all these hundreds of companies who use Haskell to write apparently useless software. https://haskellcosm.com/
Look at the thousands of people who learned Haskell and then also felt inspired to write a monad tutorial and publish it on the internet. Your search engine will help to see just how many there are. Contrast with the number of useful applications you can actually install and run that are for some purpose that is not programming. In fact there are more Haskell textbooks you can read than haskell programs you can insta…
> What have you written in haskell that we can use?
My three commercial Haskell projects are detailed here[0].