And for non-functional languages?

Not everybody wants to spend next 5 years learning thinking bottom-up, mastering category theory, monads and all that for such a task like writing a silly webpage you wouldn't rather be doing.

[rant] Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology. I program in Haskell/Scala but pushing functional programming everywhere is IMO just insanity and everybody is silent about many warts and weirdness of purely functional programming. [/rant]

Elm is the opposite. From this article:

https://medium.com/@eeue56/why-type-classes-arent-important-...

"Right now, any Elm developer can examine Elm code that another developer has written, and fully understand what is going on. I consider this a major thing that Elm has got right."

And

"Elm is targeted at the main source of users it has — Javascript developers. Javascript developers may be familiar with typeclasses, but it is less likely that they are than Haskell developers. Alternatives like Purescript provide more abstractions and powerful type systems suited to those from the Haskell community. There are many of us Haskell users who sit happily with Elm too."

Elm favors simplicity and pragmatism over academic FP lingo. You need to change your way of thinking a bit, true, but it benefits the architecture. And it'll take weeks, not years!

You will not find the words "monad" or "category theory" or "algebraic datatype" used in the Elm docs.

Thanks! Do you know any good (Udemy?) course in Elm that won't take too much time and gets into important parts quickly and thoroughly?

The guide is probably the best resource to get started: https://guide.elm-lang.org/ It introduces you to the language as well as the concepts / architecture.

I don't get why you need udemy course. Just read official tutorial with open sandbox/project.

maybe this? https://pragmaticstudio.com/courses/elm

> And for non-functional languages?

I would recommend Typescript then.

> Frankly, I am not sure why is functional paradigm considered a savior and better approach for inherently non-concurrent web frontend technology.

True, FP excels at concurrent programming, but that's far from its only strong point. I'd propose that React-like architectures (which are based around a pure Model -> View function) and functional languages are a match made in heaven.

> I would recommend Typescript then.

Funny, all people using Typescript I know use it in functional way (computer vision/AR in a browser).

I'm surprised that you think FP requires mastering category theory. Au contraire. It's perfectly possible (and indeed easier for programmers) to understand the abstractions that Haskell and Scala pioneer (higher-kinded types, and things like type-classes as well as monads which are basically enabled by HKTs) without category theory. It is true that monads were discovered via category theory, but in retrospect programmers could have discovered them -- after all they are (simplifying a bit) merely a way of generalising composition.

Scala and ML-variants like Ocaml, F#, Reason.js are perfectly good imperative languages. They don't force you to go purely functional. I always recommend that my students (whose first language is Java) start by treating Scala as a "nicer Java", and then slowly explore Scala's more powerful features. Indeed, I'd argue that Scala and the aforementioned ML-variants are (slightly) better general-purpose imperative languages than the Javas, Pythons, PHPs and Javascripts of this world, because they are more consistent, they have types/type-inference, and their statefulness fully supports higher-order state and powerful modularisation without restriction, not to mention pattern matching.

Being able to use functional idioms without compromise if and when desired (including, but not restricted to, pure functional programming) is another benefit of Scala and ML-variants.

Monads existed before their connection to category theory was discovered (by Wadler and company), they just didn’t have an elegant way of describing or naming but. them, and definitely the connection allowed them to push them more.

The biggest problem of very functional code on the web is simply debugging it. So much control flow is buried in compositions that there isn’t much to grab on in terms of break points or variable inspection. Pure languages exacerbate this problem by making state more difficult to dig out and pin down at run-time.

Exactly. Debugging is one of the biggest problems with FP, and when you hear some prolific Haskell hackers talking about no longer being capable of understanding code they produced 10 years ago at the peak of their mental performance, it's difficult to commit to it exclusively.

> Debugging is one of the biggest problems with FP

I don't see why that's a problem with FP and not just the lack of tooling in most FP languages. Debugging in F# via Visual Studio is a breeze, and OCaml's time travelling debugger looks pretty good.

I guess if you start using nth-order functional compositions and everything is a recursion, it's super difficult to figure out what is going on from e.g. stack traces or just simple log statements. And often FP programs are more-less solutions to "puzzles" and to understand the solution you need to keep that "puzzle" on mind. Now what are you doing if you have multiple levels of "puzzles" at the same time and you need to connect two separate subsystems via some deep-level information exchange, given there are no mutable variables/singletons for you? I am sure anyone taking FP seriously hits this kind of problems regularly and they often take long time to come up with satisfactory pure implementations.

Just a clarification for anybody else who might be reading this: there absolutely are mutable variables in pure fp languages like Haskell, you just have to explicitly ask for them (and reflect that fact in the type), i.e:

    do
       x <- newIORef 0
       writeIORef x 2
       print =<< readIORef x

will print 2. In fact, I'd argue that many times writing programs with mutable state is actually easier in Haskell/etc, especially when it comes to concurrency where something like software transactional memory [0] is invaluable (and more or less practically unusable in other ecosystems), if it fits your constraints.

[0] https://en.wikipedia.org/wiki/Software_transactional_memory

For F#, is it a debugger designed for F# or just good integration with VS’s .net debugger? If the latter, I should mention that the problem remains even when using C# if your code gets too functional (e.g. getting rid of some LINQ for debuggability is a common trade off).

Indeed there are some quirks in VS 2015 even in C#, like writing a function as a generator isn't as pleasant as it could be. Haven't tried VS 2017 yet. I think we're a little spoiled on .NET though, we've forgotten how bad debugging is in other languages!

Interesting. Where do you hear that? What I've heard (and experienced) is that Haskell makes is easy to come back and understand code written a long time ago (because the language allows one to structure code very clearly).

I'm not a historian. It's certainly true that monads or monad-like things where discovered independently in many context. This isn't even surprising, given how natural, and trivial in a sense monads are. But the systematics realisation of the concept and its wide applicability comes from algebra and the efforts to recover algebra categorically. Let me quote from Wadler's [1]:

The notion of monad comes from category theory [...] It first arose in the area of homological algebra, but later was recognised (due to the work of Kleisli and of Eilenberg and Moore) to have much wider applications. Its importance emerged slowly: in early days, it was not even given a proper name, but called simply a "standard construction" or a "triple" [...] Eugenio Moggi proposed that monads provide a useful structuring tool for denotational semantics [...] He showed how lambda calculus could be given call-by-value and call-by-name semantics in an arbitrary monad, and how monads could encapsulate a wide variety of programming language features such as state, exception handling, and continuations. Independent of Moggi, but at about the same time, Michael Spivey proposed that monads provide a useful structuring tool for exception handling in pure functional languages, and demonstrated this thesis with an elegant program for term rewriting [...]. He showed how monads could treat exceptions [...] and non-deterministic choice [...] in a common framework.

[1] P. Wadler, The essence of functional programming.

Yeah, I like the balanced approach - I'd love to use whatever programming mode that is available to me when I see fit, whether it is imperative mode, functional mode, self-modyfing mode, GOTO/JMP-mode, everything-is-a-modifiable-object mode, Deep Learning-assisted mode etc. I just don't like when somebody forces on me "the one right way", which was the feeling I got from the parent post.

It's not that bad.

I've been learning Elixir (a functional language) for a new project I'm working on and even with only being able to allocate 20-30 minutes a day on it, I don't feel like I need to relearn everything. This is with no prior functional language experience, just a bunch of general experience with Python and Ruby.

I have no formal CS education and while I've heard the terms category theory and monads before I have no idea what they are. In my mind, monads are some Haskell related meme and category theory is thinking about whether or not to use categories on a blog engine.

I found Elixir to be curiously easy to adapt to. I spent like 15 minutes glancing Elixir's documentation and now I'm running a Phoenix based web app (somewhat comparable to Rails but not really) following an "error based development" work flow.

This is where you try to do something, completely fail at it, look up the answer and figure out how to apply it. I don't even know how most of Elixir / Phoenix works yet I'm able to accomplish real things.

After spending 15 minutes reading Phoenix's docs on routing, I actually feel like I understand Phoenix's routing system better than other frameworks in different languages that I've worked with for years. This is partly because it's so easy to just trace a function call back to another function call and understand what's going on (plus their docs are badass).

If you want an imperative and statically typed language, try Kotlin: https://kotlinlang.org/

...which targets JavaScript in addition to the JVM (and being an officially supported language for Android development): https://kotlinlang.org/docs/reference/js-overview.html

Immutable dats structures in CLJS pairs well with react type frameworks. Trying to make js pretend it supports immutable structures is what turned me off the most about react/js

I ended up going with vue which uses mutations instead of having to return structure copied from functions.

Just made more sense to me. Maybe MobX does this for react? Idk

That's incredibly high praise for Clojurescript. It's got some great features but it has flaws, too. I feel like many people new to web dev would be more confused setting up a Clojurescript project than they would be with JS. It was a lot of googling when I did it a couple weeks ago, and that's coming from someone who has done several times over the years (what's this boot thing, I was told lein was the best thing ever?).

Those are all great languages. It is important to realize that they will increase bundle sizes, which is a common rant about web pages these days. Hello world in Bucklescript/Reason, for example, is 23 KB (anything touching the std lib at least), Elm much bigger than that. My friend's 500 line Clojurescript/Reagant app was over 500 KB uncompressed, 5k lines of JS will come in at 140 KB.

It's worth being aware of the tradeoffs you are making, because often when people are selling new tech they tend to overstate advantages and understate disadvantages.

> It is important to realize that they will increase bundle sizes

Absolutely, and it wouldn't make sense to program a tiny static webpage in e.g. Purescript.

That said, to put that into perspective, pulling 350 npm modules for a bigger project is kind of the norm now. Using compile-to-js languages will incur more overhead still and it depends on the project whether that's acceptable or not, but many times it most definitely is (also, I hope webassembly will help with bundle sizes in the future.)

I'm not really up-to-date re Clojurescript's package manager, but I know people who've specifically stated that one of the reasons for using Clojurescript is that package management and bundling is just so much easier than the standard JS npm/yarn/bower/gulp/webpack/etc amalgamation.