borar

Not in general.

What I meant is the term "railroad" is specifically conceived in the F# "world" so it's logical that one does not find it elsewhere. CEs are a concrete language feature which, although similar to do notation, is unique enough. So similarly normal to not see it elsewhere :)

The first two are F#-specific.

11 years for me...

What was the problem or question to solve?

This is another formulation of my point. Unfortunately the "human factor" seems to be somehow a notion in the software industry. But it is nonsensical in other engineering disciplines. Rightly so, because it comes down to individualistic anti-intellectual stance and that learning is special.

The "needs" are indeed relevant when we deal with different categories of applications: F# is not better for systems or embedded or game programming, Rust, C, etc. are better. But F# and C# are the same category so the "needs" are the same.

While I understand the good intentions behind such reocurring statements, I am less careful and "politically" balanced: #fsharp is absolutely inherently better. The "needs" are irrelevant, objective properties are what matters in engineering. Just like precise power tools vs manual mediaval tools.

I am guessing you mean something like "if/when the last F# programmer leaves"? This is very unlikely, either there are more remaining or others who can pick it up. People can learn things :)

The right answer is indeed "you don't need to hire F# programmers".

Even more so, given that the seminal paper on F# computation expressions just uses the monad and monoid terminology extensively, as it should.

Seq does have bind though, it's only called differently.

Functional programming and its idioms are the most fitting and sensible interpretation/realization of #eventsourcing. Fold multiple composable values of types provided by the layered model, alongside the use-case specific version, apply model logic, store a new record. "Aggregates" are a mistake.

The best language for the Web!

Why would people use other programming languages for frontend dev when #PureScript is just right there?

#FunctionalProgramming

I think I understood the popularity of "modern" as a term. It embodies the implicit and unconcious understanding that most of the (visible online) software industry is a web of ad-hoc, anti-fundamental knowledge, hype-driven, half-assed ideas which break easily. Then its on to the next "modern".

And then there is PureScript as well.

Usually the "mini applications" are easy to recognize and define unambiguosly. Evolution of long-lived business applications follows this as well: a new (business) capability needs to be added, which clearly belongs to the application, but is stand-alone within the problem domain.

Persistence is also, in general, shared. Some DB tables can be used by multiple components, some are specific to one. With #eventsourcing the journal and the record type is shared.

Every vertical component has its own data access interfaces (remember, Onion), URL handlers, data access implementation, tests, etc. Vert. components can also share types and functions from "common modules" which are at the "base" of the vert. components. For example the common User type. 🔽

All use-cases for stock management of scheduling are two other vertical components. Multiple vertical components can have their own models of the same domain notion, tailored at their purpose. A User type appears everywhere, but is more extensive/different in the user management vert. component. 🔽

A vertical slice, which I usually call a vertical component, is a cake piece going through all layers of the Onion. It is a mini application on its own, in a way, focusing on a set of related use-cases. Not too fine-grained, for example all use-cases of user management is one vert. component. 🔽

My 5c about this, as always somewhat heretical. "Bounded context" is vague and not really interesting/useful. Vertical slice architecture is not an architecture, but a principle *within* an architecture. In particular, in the Onion architecture (my default). #DDD 🔽

Only if you are making a fat client and the back-end is merely a thin layer between it and the DB and other infra.

Maybe thou pure just followeth m, returneth to sanity of
m.

I see. What is the difference with a function returning a Lazy and possibly performing side-effects?

Once evaluated, Lazy always returns the same value without re-evaluation. Does this "caching" also happen here?

Having said that, PureScript is like you are suggesting: F# 'match <exp> with' in PureScript is 'case <exp> of' and 'function' is simply 'case _ of'.

A function in its nost basic representation, as learned at school, is a table with two columns. From this point of view, the 'function' keyword and what follows it makes total sense.

Just to be sure, are you compiling in the release mode with tail call optimization turned on?

Secondly, did you try making the nested function a top-level one?