verttii

Personally I find functional style awkward in js. Mostly because data is not immutable, there are no functional operators (composition, application etc.) and no algebraic data types + pattern matching.

But most importantly, prototypal inheritance, in other words invoking the object's own methods as if they were pure functions is what really puts me off.

Many functional languages acknowledge this and are not pretending to have low-level language facilities. Instead, they have built-in mechanisms (FFI) to interface with those low level languages whenever needed.

Haskell's focus is arguably making correct software, not the fastest implementations. Such intensive focus on correctness is not usual. In that light I do feel it's somewhat under-represented.

Trails in Finland are spotless. But I guess that's cos there's just not many people to begin with.

Actually nowadays it's discouraged to use list comprehensions in Haskell. Even though he didn't complain about it, Python has very poor facilities for functional programming overall.

Distribution itself might be a world of pain depending on the nature of your application. For example stateful apps where low latency is expected.

Load testing tools like Tsung.

So what's the point of attempting to max out the count of idle connections on some cloud engine?

But in this concrete case his point is valid, I'd likewise expect Erlang's BEAM to outperform node.js in concurrency any day of the week. Elixir being new is fairly irrelevant because it compiles down to the same erlang BYTE CODE. Erlang is 30 years old.

I'm writing most of my apps in Elixir which is also functional. I got no problems wiring side effects with it despite it being less imperative than some C#/Java/friends. In fact, I'd write high availability apps on Elixir any day over C# or other OOP/imperative lang. I don't ever want to touch any safety-critical systems though, but I do care about correctness of the business logic. Somehow I have zero interest in Microsoft langs/runtimes in general.

That said, Haskell just feels like a different beast. I also don't know how interop would actually work with these different solutions, would feel like unnecessary complexity if anything. Only to end up losing the benefits of Haskell's strong typing.

I've been struggling to justify spending more time & effort on concepts mostly exclusive to Haskell, only to be able to be productive on it. I keep thinking I should brush up my Elixir skills instead.

Got it, I'll keep an eye on this. Thanks for this recommendation!

The best resource for me has been Matt Parsons' blog: https://www.parsonsmatt.org/

Thanks, I'll switch to it now based on your recommendation. Desperately want a decent Haskell editing setup, the bad tooling is killing my productivity and making me consider quitting Haskell.

Edit: Ok so I tried it. Template Haskell seems to break it, which my projects use heavily. And does not even report syntax errors in some files. Seems like yet another dead end for me as an editor setup, unfortunately.

We absolutely need more hands-on Haskell tutorials and blogs. I've been massively more productive with Haskell with the help of just a few well written blogs that are full of tutorial posts.

We got a lot of books detailing various type theories, algorithmic nuances and so on in Haskell, but very little resources to actually help anyone get off the ground with practical web development.

Are you using that? Doing Haskell on vscode has been a painful experience for me.

I guess it ultimately boils down to productivity. I mean that's what high level programming languages are built for to begin with right?

The real question is is it worth the time & effort.

Yeah it's a gamble. It didn't work against the USSR in 1968 but it did work with the Baltics in 1991.

China is as strong and determined as ever, I really don't see any way the protesters would get what they ultimately want.

OK Thanks for adding some context!

What I'd do is simply break down the larger pure function into smaller pure functions and sequencing them in the monad.

This way you would still retain purity with your functions but you could log every intermediate step by simply logging their output (and its corresponding input). Would probably make the code more maintainable as well.

From what I understand Haskell has great tooling for function profiling. Unfortunately, I got no experience with these yet so I can't say if they'd help you solve such problems.

Edit: Btw sounds like property based testing might work well as a solution to this kind of problem. It works really well with pure functions.

Haskell doesn't work that way at all. If you have variables inside a function, due to laziness their values may or may not ever be computed. Moreover, Haskell compiler sort of reduces the equations so the functions are not imperative and the computations would not happen as you expect them to. Logging would not get you anywhere.

However, you can just log the output if you like without putting IO into the function. I see zero reasons why anybody would push such logging into production. It behaves exactly the same way on your own computer as it would in production - it's just a pure function.

Why would I need logging inside a pure function?

Countries who have successfully gained independence have often sacrificed a lot of blood for it. And built strong armed forces to back that independence up with.

Whatever we may think is morally right, HK does not seem to be putting together that hard resistance, nor is it building up its own armed forces to declare and maintain independence with. China thinks HK is legally theirs and nothing we say or do will change their position over it.

That's why I don't see these protests achieving anything.

> You defy your own argument. If that's how you design application, what's the point of bothering with side effect isolation then?

I don't understand this.

If you have a monad like

  do
  ...
  _ <- doSomething arg1
  let result :: Result = pureFun arg2 arg3
  ...

How is that not simpler and better than having that pureFun invoke a bunch of side effects and perhaps even mutate something that you have to be aware of? How does this take away the benefits of side effect isolation?

What about runtime stuff? I've found Haskell is very good at abstracting away your concerns about the runtime considerations and sometimes it will come back to bite you. I mean all that stuff you want to see into when you're running your app in production, like caching, function invocation times, threads etc.

Interesting. Any input on erlang vs elixir debate? Which so you prefer as your primary tool personally?

Not only that, but a lot of the state is essentially the same for many/all users/connections and can be shared.

Let's say in a chat app with a Redux setup I'd maintain channel users, messages, own profile details etc. in the app's own local state. With LiveView I'd only need to store the user specific stuff in this user's own state. Some of which I'd store in the socket.assigns of Phoenix Channels subscriptions even now with a conventional Redux setup.

Out of interest, what are the other problems you've encountered with it? We're considering porting our whole app to LiveView.

it's syntactic sugar

What would you say are some of the main benefits you gained with your journey with Haskell, beyond coming across a lot of abstract concepts?

I'm struggling to justify spending more time on picking up Haskell myself as I can't see clearly what's at the end of that tunnel.

I've posted questions there before but unfortunately got no replies. However, some friendly folks at Slack helped me a lot.