Hacker News Reader

Comment by eric_h | Hacker News Reader

> The thing I am trying to build is not possible in any other ecosystem today

Umm... what? I'm afraid I don't understand how the "grand vision" behind Clojure adds pixie dust that makes it capable of something another Turing complete language isn't. Care to elaborate?

View on HN

This is the sort of generic programming language flamewar comment we can do without. If you want to discuss questions like this on HN, please pose them without snark.

We detached this subthread from https://news.ycombinator.com/item?id=11883875 and marked it off-topic.

Sorry.

As an aside, I don't think this thread turned into a flamewar, there's some good discussion.

Also, s/he started it ;)

I take both points but the combination of snark and genericness is still an explosives-handling violation.

Thanks for the friendly responses.

> still an explosives-handling violation.

Haha, what a fantastic way to word it. Duly noted.

Turing-completeness is a statement solely about a system's ability to perform computation, in the mathematical sense of the term (take inputs, do something for a while, return outputs, strictly in that order). It says nothing about other desirable properties like usability, extensibility, comprehensibility, etc.

Turing completeness says nothing about your ability to operate within time constraints.

You're getting down voted; probably because the way you worded your question. I'm giving you an up, because I, too, am very curious how something is possible only in Clojure and nothing else.

This is one architecture that is made possible by clojure: http://tonsky.me/blog/the-web-after-tomorrow

To build it outside of clojure ecosystem, you would need to first build all the pieces of the clojure ecosystem

Thanks for pointing me to that article. I've been mulling over for years how to architect apps to remove the server, that layer never sat well with me. I've also found I couldn't discuss the problem with anyone because "clients can't access the database directly!" is such a knee-jerk reaction.

If clients access the database directly, then the database is now the server. You haven't removed the server, you've just moved it.

By removing the server-side layer I mean, for example, moving the "model" logic in MVC to the client. The database is still there, but it doesn't perform any application logic, so the server-side layer is moved to the client, not the database. The challenge then becomes authorization. Ideally even the database would be ad-hoc distributed yet would maintain authorization functions or at least the practical result of them, so there's no server-side whatsoever.

But if your server doesn't enforce data consistency -- that is, the business logic resides on the client -- you can't rely on the quality of your input. And if your authorization sanitizes the data to ensure consistency, then you've just built your middle tier for logic.

You still need to do all the same things as before. Some things you move to the client, other things you move to the dbms. There isn't some functionality that magically disappears when you no longer have, for example, a PHP/Ruby/Python/JS/whatever server mediating between your client and your database.

My proposal is that almost nothing moves to the dbms, everything moves to the client except perhaps authorization. Unfortunately I can't fully defend my line of reasoning without saying, here's a link to my fully described or developed alternative architecture, which I don't have. However that doesn't mean it's not possible, it seems to me to be achievable. Even if it would require changes to HTTP, the database (row, column, and cell-level authorization?), or the browser - the end result would presumably be worth it. I imagine it would be much easier to reason about an application that is data and data authorization on one side, and logic on the other.

> I imagine it would be much easier to reason about an application that is data and data authorization on one side, and logic on the other.

You're basically describing, for example, a Ember/Android/iOS + Rails + Postgres app. Logic lives in the client (Ember/Android/iOS). Data + Authorization lives in Rails + Postgres. And the Rails part of that is really not doing much. It's deciding if a request is allowed, then serializing or deserializing data from the database. I guess you can do that in the dbms, but you still need to do that somewhere.

The object-relational impedance mismatch disappears when the dbms is an immutable time series, which means a whole bunch of plumbing code does indeed evaporate

How do you decide who can write to and read from your data store?

> To build it outside of clojure ecosystem, you would need to first build all the pieces of the clojure ecosystem

That's simply untrue, and even the author's conclusions contradict your point. You can already do all of these things with just javascript. And if you're arguing that javascript has rebuilt the entire clojure ecosystem, then what is the non-aesthetic case for clojure?

I like clojure a lot and I've made a few toy projects with it, but I see its primary value as helping me write better code in all languages I use.

What do you think the time delta would be between building it in JS vs Clojure would be? Just curious.

It really depends on so many different factors. The javascript ecosystem is at least 100x the size of clojure's, but as a consequence, the average quality of what's available is much lower. If the pre-existing libraries and services will work for your use case, javascript is going to be faster, simply because most of the code you need has already been written.

Another important consideration is your familiarity with both. If you have a deep knowledge of javascript and its ecosystem, many of the architectural wins you get from clojure out of the box are fairly trivial to port over. I suspect the reverse is not as true, because a clojure expert dipping their toes into javascript doesn't have as clear a picture of what the limitations are and how to overcome them.

As we can already see in this thread, there's a tendency for people who use clojure to believe that some architectural concepts are literally impossible for all other languages, rather than merely less common or requiring some pre-configuration.

Funny how more and more application are becoming game-like rendering system.

Has this been implemented yet?

I am implementing it (search for Hypercrud) and I know of one group of people separately implementing it (search Posh and Catalysis) I know of no others, if anyone reading this is working on this and would like to share ideas please email me

All Dustin had to say to make the "impossible" argument real is to add the qualifier "practically", so while it is possible to build a highly dynamic, enterprise application entirely out of HTML/CSS (recall CSS3 is turning complete) [1] it is "practically impossible" to do so.

[1] http://my-codeworks.com/blog/2015/css3-proven-to-be-turing-c...

Anything you can do in Clojure, I can do in Blub.

Reply on news.ycombinator.com