andreas_bak

Yes I agree. But, I believe that it is just a perversion. In any project that involves RDBMS writing queries is just a small part of development. Surely you could modify queries with Clojure-QL (with SQL it will be a suicide) but what you gain from it ??? (more free time - I don't think so). Furthermore, having such dynamic "meta-"things in your code, eventually will cost you more time in debugging it.

With SQL it is straight-forward: you prototype your query using some GUI client and then you just embed it in your program. How it can be done with Clojure-QL ?

I am not against new ways of querying RDBMSes but until today SQL seems the most simplest and clean way to do it. Most realistic solution will be not to abstract SQL but develop a new query language for relational datasources (on same level with SQL). I am pro abstractions that simplify things (like TCP) and against naive abstractions ignoring the basic aims of layers under. TCP simplifies things, Clojure-QL complicates them.

PS: The article that you suggested is written by a guy that tend to speculate over his point of view without taking in account the reality. In all modern RDBMSes queries having (a=b and a=c and b=c) will be simplified by query planners (Oracle and Postrgre do it) so there will not be any difference in performance.

1. Why to write an ad-hoc sql parser in Clojure. The result of query is a JDBC ResultSet (on JVM). You may define some functions that transform rows from ResultSet to Clojure terms in order to make your code shorter.

2. They are not simple functions. Compare this : (-> (select (table {} {:employees :p})(where (= :name "John")))(join (table {} {:employees :b})(where (= :p.manager :b.id)))to-sql)

to this :

SELECT p.,b. FROM employees p JOIN employees b ON (p.manager = b.id) WHERE (name = 'John')

Which one is more verbose ?

EDIT: SQL examples with "employees" and "departmets" are very misleading and usually oversimplify the reality.

I read the article. The guy claims that SQL is hard -- yes it is hard for real life cases and there are limitations imposed by underlying theory (relational algebra). Joining the table with itself may be little mind-blowing when you do it first time. It still does not mean that we need to write queries in different language and translate them back to SQL.

A simple question is "how the hell you use prepared statements with such libraries"? And the answer will be is that the FRAMEWORK need to be extended further in order to support them. In other words once you abandon SQL you will never have the same flexibility that it gives, because of artificial constraints imposed by every framework. And your code will become more and more complex because of all these frameworks that are invented not of the real need but as an programming exercise.

I can not understand what problem this library solves ? Why to write SQL in Clojure and translate it back to SQL ?

Examples on website are quite simplistic. They are far away from real life SQL queries that usually bigger and more complex (not select and join couple of tables). What about "group by", joining 5 or 8 tables etc.? How you are supposed to prototype and test your queries on existing schema (there are many good graphical clients for many RDBMSes)? There are many questions remaining unanswered.

At least Clojre-QL do not try to fit a square peg into round hole like Hibernate. Personally I liked Hibernate for some period, until I sat down and learned to use SQL.

As long as you making plans and analyze why to do something or not, you are losing your time on over-analysis. Instead of reading super-analytical and pseudo philosophical 'less wrong' or marketing crap from 'techcrunch', that have little to do with reality, start to do something REAL. When you do something REAL, ideas will pop-up on the course and some believes will be challenged, but this is the only way.

HN is great community but there are some stereotypes that need to be chalenged on personal level:

1. The "SWEAT CAPITAL" is better than Venture Capital, and you have access to it already.

2. If you want to make money, do not think in the box. Here people tend to analyze what already been done. This is not a way - you need to innovate.

3. People will laugh with your ideas and failures. You need to be firm believer in what you do. Respect is gained and not granted.

4. Start doing something "stupid", without prospects of economical gain. you will see that you will end up with something completely different than when you started thinking about it.

5. Stop dreaming -- Start Doing. It is much more rewarding and interesting.

Let It Be.

Yes you are right. I did not notice it. HTTP cache is effective on resources that are same for all users.

One possible solution is to decouple the personalized data and load it separately using AJAX. Votes are already implemented in a similar way.

Generally, I am proponent of HTTP caching. It requires some modifications of web sites in order to be effective but still the whole system remains less complicated, compared to implementations of cache on back-end (like `memcached').

For example reddit, which is similar to HN, is in constant struggle with their cache subsystems (http://blog.reddit.com/2010/05/reddits-may-2010-state-of-ser...). I believe it can be avoided by keeping cache and web site code apart.

It is slow for me as well. It seems that page needs some optimizations in order to be served and rendered faster when the server is under heavy loads.

1. I checked responses using FireBug plugin and it seems that pages are served uncompressed. For example the front page of the site (only html) is 31K uncompressed, with gzip compression it becomes 6.3K (80% smaller size means 80% less bandwidth to use). Most of web servers support compression.

2. All pages seem to be generated on every request, e.g. no HTTP cache is used on server side. Because I did not found any response headers set by caches. If for example, each page was cached just for 1 to 5 seconds it will reduce the stress on database and cpu significantly. On the other hand it will not impact user experience, because cached version is short lived and fresh results will appear on time. For example the front page is the most requested page of the site, assume that it is requested 100 times per second which means 100 queries to the database etc. If this page is cached for 1 second queries and html composition is reduced to 1 time per second. Personally, HTTP caching on server side is my favorite choice because you don't need to modify the program to use it. (super-fast Varnish cache is the most flexible solution I found).

I must mention that The slide idea is taken from (http://hackerslide.com) by `peterc'

I like to see others people work. Sometimes RMSes are linking to things that are just weekend small projects, but still it is nice to publish them and ask for opinions of other members.

I think that spam posts will disappear in few minutes from the frontpage, because nobody votes them up. In this case a kind of collaborative filtering by HN community will do its work.

I believe that by not allowing new users to submit links is a radical approach. There are many kinds of users, for example I crated this account recently (because I lost my old password and did not find a way to recover it). Usually I visit this page 2-3 times a week just for reading. By forbidding new users to post the community will be divided in two classes "the privileged one" (those who have time to read and write comments) and "the rest" (no write access, because probably they do not have enough time for writing comments (my case)).

I think that "classical" approaches will minimize the spam. For example CAPTCHAS will stop spam-bots. And throwaway accounts may be limited by verifying email addresses of members.