codygman

> , I feel like I can confidently say structural typing, in practice, is MUCH easier, better and fun to work with than nominal typing. I can think of times I literally spent days trying to work through some refactoring in Java that was a nightmare because of the constraints of nominal typing, where the structural typing approach of TypeScript makes it trivial.

The obvious takeaway here in some respect is gradual typing is better and nominal typing is annoying for little gain.

What if the true answer were you need a more flexible and powerful type system.

I think that moderate so-called "pragmatic" languages are the worst experience because of their lack of guiding principles.

> If it really sucked then people wouldn't use it.

What if they never give an alternative a chance? Then that scenario could happen quite easily.

> if you recognize that some common construct is in fact a semigroup or functor, does knowing this actually buy you anything?

At least in Haskell one thing it means is you can use lots of new helper functions.

> guide you to some nice properties, such as easy composition.

Yep, which gets you code re-use for one.

Someone already did and the goalposts just got moved again: https://news.ycombinator.com/item?id=24352585

> There are some tiny niches where functional programming is particularly useful, but outside of them the code is classically difficult to read, write or debug

What niches are these where FP is "classically difficult to read, write or debug"?

> map is also quite natural, but isn't it telling that the way a human will do this on paper is by reptition of the same task in sequence... i.e. a for loop.

Would they?

Catching up on comments and kind of fuzzy, but this is pretty cool :)

    foldr1  (&&) ( [ (==3), (==4) ]  <*> pure 3 )

> This actually is pretty ugly.

What precisely is "this"? From my point of view at best it's calling out FUD and an unsupported claim sold as obviously true.

It's not abuse to challenge unsupported claims and call them what they are.

That sort of attitude cultivates horrible horrible things... One example being science denial.

> I'll change my mind with evidence. You have provided precisely none.

Your initial claim had previously no evidence.

Others provided evidence and your responses have me no confidence that spending energy changing your mind was/is worth it.

> Go got rid of Generics which made programming so much simpler. I can't wait for its new Generics feature though.

What? If getting rid of generics made programming so much simpler why can you not wait for its new Generics feature?

> Mathematicians mostly care about value semantics but programmers need to care about how it's realized in hardware too.

Exactly! The thing is this book gives a method where you care about value semantics, keep the ideal representation, and then care later about how it's realized in the hardware!

> "Oh, this thing turns out to be a Monoid! Let me abstract it."

You seem to have an example in mind where this leads to the "making everything a mathematical problem" , can you share it?

> Haskell communities do it very differently by making everything a mathematical problem, and it's only math experts who feel comfortable with the code.

I program in Haskell every day and I have no idea what Haskell code you have in mind.

Also as I've said elsewhere, nearly everyone reading this has more math experience than this Haskell programmer without a degree or calculus class under their belt.

As a professional Haskell programmer for a bit now, I see no problem with a chat app in Haskell.

In fact, something close is wire[0] whose server source code is here[1].

They are a secure alternative to slack and mattermost for the curious.

0: https://wire.com/en/explore/competitive-advantage/ (this gave the best explanation in the comparison section of what it actually is imo)

1: https://github.com/wireapp/wire-server

When you design software focusing only on the business logic and domain the end result will be better than if you have to do it while juggling implementation and performance concerns.

> We have no metric to use to quantitatively score one design as something unequivocally better than another design.

Given the current state of software development, it's not fair to place that burden of proof here when it's not used elsewhere.

> 95% of Go programs could be replaced with a single traverse

This is a rather abrasive way of putting it that tries to communicate this point. I would have found it difficult to even entertain when my Gopher squishee on my desk and I came across it as someone very in love with Go at the time.

The point though is that for loops in Go are unstructured, but very flexible. That lack of structure lets you have any organization you have, probably influenced by previous languages you've used.

Structured recursion like folds and maps enforce a certain pattern to this, the same goes for traverse.

That idea isn't specific to traverse though, it generalizes to all of the Haskell abstractions. The reason people talk about composability so much is because composable code means re-usable, concise as in KISS , and elegant code.

This "theoretic book" can help you design a very good api. If you mean REST api's by chance, remember those were theoretic once too!

> But if more boilerplate translates to greater readability (i.e. less abstraction & much closer relation to the problem domain) then I would argue that the added boilerplate is justified.

The added boilerplate usually translates to less readability and distracts from the "essence" of the problem or the main idea a piece of code is trying to communicate.

> Applications written in haskell you can run on your computer for doing something other than programming is still a list that you can count on your fingers.

Before you make such strong claims, you should at least try and validate they're true. Please stop spreading this lie.

> I am turned off as well from the abstractionauts in the software world

Is there any way you can give examples of this in Haskell?

If I'm just blind to them by now I'd like to know, but most "abstractionaut" criticisms I've heard seem to ignore the pragmatic ideals driving the reasons for the abstraction and ignoring inherent complexity.

> C/C++/Java code is never bug free, but it's not tremendously difficult to write real-world applications using these languages, simply because of how well their memory models/object models/features map to the way most programmers think.

My argument that it has nothing to do with object oriented mapping to the way most programmers think, and is almost totally a function of familiarity.

> Yet they are robust - all the bugs in the commonly traficked code paths have already been sussed out, and from outside the software looks like an impenetrable, rugged piece of craftsmanship.

I disagree. I think they only feel robust. I think more importantly this mode of development is defensible and always gives one something concrete in the case of being asked "so what's the product of this 3 days of work?".

> Bad code that ships is better than good code that doesn't.

Sometimes, but not always. The bad code that ships however always feels better and gives the feeling that progress is being made.

That works fine until a wall is hit and things have to be rewritten or worse hacks have to be added. That ends up taking more time than the original solution, but guess what... no one is going to bring that up.

That means the correct solution never has a chance to get the points it earned to be weighted more highly next time a decision of correctness vs speed is made.

There are pre-built frameworks for handling the common "ship the bad code, never say it's so bad it's a net loss, and just iterate on the crap on top of crap you have" so that all levels of the organization feel more comfortable.

> With all that said, I do wish that we had better software, and that correctness mattered more.

It can't matter until technical debt is analyzed on a meaningful time scale and actual observations happen, rather than what amounts to making things seem like they're going smoothly.

> The other reason is that many FP users are too enthusiastic about creating abstractions.

Are they? I'd argue most real-world Haskell code doesn't abstract enough, perhaps out of over-reaction to this untrue assertion that seems prevalent these days.

> This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions.

A lack of that isn't the fault of re-using powerful abstractions at the base, it's a failure of not making the concrete implementations more obvious.

It would be most constructive if we could work with examples, but I don't know what the origional commenter had in mind since that hasn't been my experience with industrial Haskell.

> Industry programmers didn't sign up to learn about category theory. They do what they do because they like building things. There is a subset of those Industry Programmers that does indeed like learning about category theory and all of these other concepts necessary to grok languages such as Haskell - but it isn't a critical mass by any means.

Why all the conversation about category theory? I've read most of Algebra Drive Design and I think you've mentioned it more times than the book!

> Yes, Elm lacks the horsepower that other pure FP languages have, but at least it doesn't lead a developer to think "hey, I didn't sign up to learn about Arrows and Monads. I just want to write a TODO list".

You can write your TODO list in Haskell without thinking about Arrows for sure, and very likely without thinking about Monads.

You might have been bitten by this before:

    1. Make it work
    2. Make it right
    3. Make it fast (uh-oh your nice design prevents performance optimizations, time to scrap it)

The reaction to that is usually to think more about performance ahead of time so you don't get trapped by your theoretically perfect design when the real world comes crashing down.

With your hard-won experience you do away with those childish notions of being able to make a perfect elegant design where you don't have to worry about performance until the end.

The most valuable thing you'll find in Sandy's book is that you can actually ignore performance until the end and nearly always (always maybe?) be able to make it fast.

You can regain your optimism from your younger years before the bad experiences and resume this path:

    1. Make it work
    2. Make it right
    3. Make it fast

I think it goes without saying that I highly recommend Sandy's book and think it could be the way forward for quickly writing correct, elegant (composable/re-usable!), and FAST programs.

> But recently I started to think that one of the reasons that prevent it from becoming more popular is that the community focuses too much on "mathematical" abstractions.

Many times being in the middle of any two extremes is a pretty bad experience.

If you shy away from math though, you get closer to tapping into the average programmers experience in other languages.

Because of that, it's easier and more familiar.

Those things are good for adoption, but not necessarily a Haskell experience that is so good it's clearly better.

I think the direction Sandy goes in does achieve something objectively better.

My advice is to try it out and don't let the "it's too mathy like Haskell always has been" comments bog you down.

Do be prepared to learn a new paradigm and solicit help from others to be able to learn it in a timely manner.

- A Haskell programmer who never made it past algebra

> However, based on the website and sample chapters, it’s not clear that there will be strong arguments made here about either scalability or performance

I've read most of it, performance is addressed after correctness.

The trick is that your correct API never has to change to get better performance.

I don't want to give too much away though and I highly recommend this book.

> I don't know many programmers who are jumping to use Haskell for their personal projects.

If you don't use Haskell or are suspicious of it, would you expect to know other programmers who use it?

We have data that can more strongly make the opposite claim that people do use haskell for personal projects:

> The functional language Haskell is the tag most visited outside of the workday;

https://stackoverflow.blog/2017/04/19/programming-languages-...

The advantage (or potential problem as you see it) is typeclasses encourage thinking about the meaning and behavior of what you are doing.

For simple cases, the end result of no typeclasses can be compelling sometimes.

For larger cases, taking away that useful tool to wrangle inherent complexity usually results in more complexity taking the form of gobs more simple code that obsfucates the task at hand.

> Haskell code can be optimised to run very fast indeed, but resulting optimised code does not look much like idiomatic Haskell at all.

It's still Haskell though, which means it can compose nicely with all that idiomatic Haskell!

Further I'd argue that you typically don't have to go to that level of optimisation.

I'd be very confident in my above statement replacing node or Python REST apis at least, but can imagine that not holding true in other domains.

In that case though, my first point still holds and I find that advantage very powerful.

> I think the problem is FP has built its own set of abstractions that imperative programmers aren't used to.

What you describe as a problem sounds like a solution to me :)

I'm curious whether you think there are imperative abstractions that could be used over the commonly used FP abstractions.

That avenue of discussion sounds potentially valuable and fun to me :)

> But that requires compiler-as-a-service, and GHC is not. And writing your own analyser for a language is quite a task.

Yep. Haskell-language-server is very nice, though there are some performance issues I've experienced with a template Haskell heavy large codebase.

For many cases though, the experiences is very smooth after install.

Install issues are close to being sorted out with static binaries being downloaded in the vscode extension for instance.