16 comments

[ 7.6 ms ] story [ 105 ms ] thread
> …we eliminate so-called “structured programming” constructs like “for” and “if”. Only function calls, variables, and constants are allowed. The result is that we end up with something that looks a lot more like assembly code; but instead of “GOTO” statements, we use callbacks…

Oh god please no.

Building a nontrivial app in node is already a nightmare.

Well, node is node...

In Clojure I got almost to the point where I can write and reuse almost any layer of my application, I need to connect with Mongo, check, I need to authenticate an user, check, I need to connect with Postgresql, check...

In the next app, if I would need to connect again to mongo I will just need to import the relevant module...

Well, what the author wants is called Haskell(or Scala to some extent) where the logic "is in the type itself", he doesn't know it yet or he wouldn't have written this article.
Frankly I just want to do it in JavaScript-- not because it's good, but because it's "good enough". Know what I mean?
Try Haskell, you'll understand why JS isn't "good enough".
This is where my knowledge gets weak; but, isn't this the type of programming that Ada and various languages that have a matching system are built around?

You have a function that returns an enum and you have to match all the different states of the enum in your handling code. The ones that call your given function have to do the same and so on and so on.

You can still have bugs in this model if I recall, they're just harder to have, I think. Admittedly, this is getting outside of my area of recent experience and expertise, I just swear I've read about something like this before.

"We are getting close to a day where backend development will be commoditized and replaced with declarative tooling— software that writes software that never breaks."

Yeah, and the year after that will be the year of Lisp and Linux.

At a cursory reading, this looks like a re-invention of the Haskell notion of monads for error handling.

Briefly, monads function as a kind of "overloadable semicolon". For error handling it lets you say that if any step fails then you abort the rest of the steps and return whatever the error code was.

The "returns multiple cases" one can also be handled using the List monad and its relatives, which do non-determinism. At the very least, the type system forces you to consider the possibility.

Unfortunately, while Haskell monads can handle multi-exit logic, it is not enforced as a built-in primitive.

I've read and re-read the first page of Google results about monads at least ten times, and I never really "got" it. Maybe I'm just dumb- but it seems to me that the problem remains unsolved.