Hacker News Reader

Comment by cube2222 | Hacker News Reader

I think one more problem with Scala, apart from the lack of stability and having to solve the language's problems instead of your application ones, is one of local maxima.

Most of the ecosystem uses monads. And the way most projects end up using monads is have "the one monad" that every function returns. ZIO is an example of that. Understandable, since the alternative is to have tons of different function colors.

However, since in that case the monad really is just a configurable semicolon semantic, you've just gone full circle and chosen a single global one.

And in that case, why not just choose a language where that semantic already is the core semicolon semantic of the language? You're living with a ton of complexity for very limited gain.

View on HN

It seems (to me) less complex to have that as "just a library".

In most of my little projects, I don't use ZIO, I just have a tiny library I wrote years ago that lets me write stuff that works ok whether it's a Future[Seq] or a Seq[Future] or a Future[Seq[Future[Seq]]] underneath. https://github.com/wbillingsley/handy

If ZIO (or some other choice) were baked into the language, I'd be using their choice of async libnrary for everything whether I want to or not.

And I wouldn't be able to switch to the new-shiny-and-exciting-thing that comes out when I want to explore it because "sorry, X was what the designers chose when the language was written, so X it must be".

In Scala, I can use my little thing I'm familiar with, or I can try out ZIO, or Cats-Effect, or Akka Streams (before the licence change). I get to explore concepts very quickly and very easily without having to shift languages and learn a new set of build tools and syntax at the same time.

> why not just choose a language where that semantic already is the core semicolon semantic of the language?

The semicolon isn't semantic. A "semicolon" monad is essentially a single global context object. Most languages let anyone anywhere introduce a global context accessible from everywhere else. At least a monad lets you track it all.

It's not just context. It's also asynchronicity and error handling for example.

The semicolon semantic is how operations separated by semicolons (or newlines) are evaluated and how they impact the general state the program is in. Which is also what a monad's flatMap does, in a configurable way.

No, it is just context. Which context you choose in which part of your code is up to you. Somewhere I might choose ZIO. Elsewhere I might just choose an error-context. Or a state-context. Or a "let me accumulate some extra information while doing data-rprcessing"-context.

And it is always explicit when you are in a context and which one it is. This is really the strengths over languages where this concept is missing. Those languages will just merge and mushup contexts and you never know exactly which things are safe to use and not.

I know you can do it, the question is whether it's mainstream to do it, or whether in practice you end up with a single one in 95% of the cases.

Based on using it a bit and talking to many, more or less disillusioned, scala developers, my opinion is: it's not worth it.

It's fine for us to disagree though. There's enough programming languages and projects for everybody.

It is very mainstream to do that.

Show me a project that is not just a small playground that uses either ZIO or cats-effect and does NOT use another context such as Either/Try or Option or List, ...

1. Because different projects will want different monads

2. In my experience, having up-conversions between different monads is intuitive low-noise

> Because different projects will want different monads

It doesn't look like that to me, based on how the ecosystem currently converges on a single one. I understand there may be some projects that do that, but if the majority converge, then it's still needles complexity.

However, I might be wrong. I've been an external observer for a while already.

History proofs this wrong. Just look at it: first there were Scala Futures and Twitter Futures. Then there came Scalaz and Monix, later Cats-effect. Now ZIO also joined. And each library even brings different kind of effect types.

And all of that works, even in combination! This is as if you mix angular and react. Sure, you should try to not do that as much as possible, but the mere fact that you can do this in Scala is a sign of awesome language and library design that is far outstanding compared it the majority of other languages.

You could never come up with the "one true solution" from the very beginning.

> You could never come up with the "one true solution" from the very beginning.

I think I can! I mean, that's what science is for, right?

I'm not so sure. The problem is that the world is moving, including hardware, software, interfaces but also people and process. Languages have to optimize against a moving target. So naturally it's a good idea to optimize for something moving and not something static.

This is what makes Scala good. The language itself is not very complex actually, but it enables complex and powerful libraries.

We are still in the phase where concepts are settling. Pretty sure nobody in a 100 years will think that Monads are a good idea.

> We are still in the phase where concepts are settling.

Yes of course concepts are still settling, and they always will be.

> Pretty sure nobody in a 100 years will think that Monads are a good idea.

Why? I for one am pretty sure monads will be a useful concept a hundred years from now.

What about functors, will that concept also be obsolete?

Listen, Monads are fine, Functors are fine, use them wherever and whenever you like. The problem I have with them is that they are making things explicit that are intuitively clear (Monads more than Functors). That is useful in some situations, but in most situations it is not, and just uses up precious brain capacity. If you go to the shop, you are not expecting someone at the entrance telling you that you have to pay for what you buy, and before paying, you are not telling the cashier that you are going to pay them now. You just do it.

Monads are like numbers. You can think they are not a good idea, but they are just a matter of fact and existence.

Also, in a 100 years maybe our brains will be completely different. How do you optimize your programming language for that? I don't think you can.

Given that our brains have been the same for a few thousand years, maybe I don't need to optimise for that.

Anyway, what we currently have as programming languages are all workarounds. Necessary for now, because how else would we program? But in the end we need to converge programming, math and logic, and once this is done, we will be ready for anything. And we won't need monads as a crutch, forced upon us by a type system. I am sure the concept of number will outlive the concept of monad in terms of popularity.

> But in the end we need to converge programming, math and logic, and once this is done, we will be ready for anything. And we won't need monads as a crutch, forced upon us by a type system.

1. Math is filled to the brim with monads, it's just that mathematicians are necessarily specialists, and tend to think about things in terms of their applications to their specialties: they talk about closure operators or algebraic theories or formulas in a formal language, rather than monads as such. But that doesn't mean the monad structure isn't there.

2. Convergence between math and programming (which I agree is desirable) will almost certainly see type theory become more prominent, not less. There is some chance that programmers turn to constraint solvers or ML models for program verification instead, but if they do, mathematicians will not follow.

Type theory is already dead, it just doesn't know it yet.

Programming languages will converge after(!) natural languages have converged. Not gonna happen in our lifetime!

> I am sure the concept of number will outlive the concept of monad in terms of popularity.

It already does. I don't get your point...

> Programming languages will converge after(!) natural languages have converged.

Interesting point. But I think you emphasise too much the surface syntax of the language. The language will be a new form of mathematics, and it will be universal, with adapters to various natural languages, of course.

That's beyond me. I guess I prefer to look at what can happen during my life-span. :)

Oh, I am working on that universal language right now. Shouldn't take more than 15 more years or so.

Ping me when you have something presentable!

Ok!

One example:

Any project using a transactional database will want a monad for actions that occur within a single transaction (see e.g. the Slick `DBIO` monad).

Reply on news.ycombinator.com