Comment by com2kid | Hacker News Reader

Comment by com2kid | Hacker News Reader

> and how tedious and time consuming it often is to implement even trivial things like sending data from the client to the server and vice-versa.

Let's be clear here, the complications there are as follows:

1. Authentication and permissions in regard to the end user who is making the change or fetching the data. (E.g. internal web app, the AWS hosted database has no knowledge of my corporate AD accounts)

2. Authentication/permissions of the service/software that is talking to the database

3. The crap tons of network problems and errors that can occur.

4. Dealing with other possible errors, such as malformed input, or data not being present, data being stale, write conflicts, etc.

5. My backend service is running in a private cluster and my DB is running in a different private cluster.

6. My backend service is running in a private cluster and because of that the nifty subscription DB engine can't try and reach out to reconnect to my service if something goes wrong with the connection because there isn't a routable IP address.

Writing data to a table isn't the problem!

I think a more charitable interpretation would be that they're highlighting how much work has gone into that area (web server frameworks come to mind), compared to how little work they've seen on cleaner techniques and language assistance for managing local state.

That's how I read it at least, reasonable interpretations may differ.

But I cannot agree. I am very down on this. I think this a colossal waste of time.

I do not see the problem they are trying to solve. Doing I/O is hard, not because sending bytes on a wire is hard but because of everything that can go wrong. It is the "everything that can go wrong" part that is hard.

They are going to solve the problem of state with "algebraic data types". That is not new. I am trying to think of a language at a higher level than machine code that does not use algebraic data types. ("Algebraic data types" are not an invention, they are a description)

I cannot see anything new in this. I fear it is another example of making easy things easier and pretend the hard things do not matter.

There have been huge strides in the development of computer languages in recent years. Rust, Go, Swift, Dart.... All of them with slightly different use cases and solving slightly different problems in slightly different ways. But the author knows of Closure... Yes, but.

"One can easily reconstruct the exact state of a Cell program at any point in time." Really? I spend my entire professional life doing exactly that, whatever the system I work in.

This is engineering with machines. State is part of the nature of those machines. It is very well understood and is not a problem (handling state) that we are struggling to solve.

It's pretty bold to say that their programming language project is a colossal waste of time. I recommend steel-manning [0] and reading their post with a more open and curious mindset.

They could have phrased their article better, sure. But lets not cherry-pick one sentence that's barely relevant to the rest of the article and use it to fuel our anger that they aren't solving Our Favorite Problem. Instead, let's focus on what the author is really trying to get across: that a language can help manage the complexity that can come from mutable state.

If you read the article with a more charitable lens, you'll see that the author is saying a lot that could be new to many readers: a language can combine relational data with functional transformations, a language can expose these patterns to enable more solid architecture, a language might support first-class reactive programming, and a language could (if high level enough) offer replaying and snapshots.

That's honestly fascinating, and I would love to see what kind of ecosystem can grow around a language offering such features.

[0] https://themindcollection.com/steelmanning-how-to-discover-t...

If you are interested in approaches to combining programming language and database semantic. There is a bunch of work in this area from the 80s… Look up “Persistent Programming” and “Database Programming Languages” (DBPL).

And yes, get off my lawn :-P

> State is part of the nature of those machines. It is very well understood and is not a problem (handling state) that we are struggling to solve.

Wow, really? If handling state is not a problem, then what problems do we actually have?

Mostly, trust in some form. That is what we know about some one else's state

> compared to how little work they've seen on cleaner techniques and language assistance for managing local state.

Literally every new web framework is some new take on how to manage local state.

You could spend an entire year learning about different state management solutions. From systems that keep backend and front end state in sync, to the entire redux/mobx family, to the stuff that Svelte does.

We are a long ways away from the bad old days of a global "state.c(pp)" file.

Reply on news.ycombinator.com