Clojure: a pragmatic data driven language?

Is that ‘The Great Unification’ of 3 fundamental forces, from particle physics?

1 Like

Yes, the Great Unification Theory thinking, in scientific research, simplicity and unity are important guiding ideologies, and Clojure (lisp) and The Pure Function Pipeline Data Flow perfectly reflects this idea.

In addition, the traditional Chinese philosophy, the Tao ---- the great unification of everything.

Thanks. I entirely agree about Taoism (/Zen) philosophy being relevant too but my reading is fairly superficial so I wasn’t sure if Taoism had a Grand Theory too. I had similar reactions to homoiconicity and reading about The Way. I think humans are drawn to ever greater abstractions as a way of efficiently capturing knowledge but perhaps ‘enlightenment’ requires us to accept the possibility that some things may be unknowable, so we must trust our instincts. Acceptance of uncertainty seems to have been the direction of travel in physics for the last century.

You had me at “Lisp.” :grinning:

Pragmatism is a claim. If compared with Python for a given problem, it should be shown the equivalent Clojure code is 10 times shorter and 10 times as powerful. No concept, no Tao, just efficiency.

1 Like

simplicity and unity are a source of strength for achieving your goals. that is Tao:

Keep it Simple and Unified.

This is a job that looks simple and hard to do.


1 Like

That’s not the full story. You’d also want to show that it would be more maliable to future extensions and modifications, and that it would lead to fewer defects, as well as take less time to code and test, and that it performs with better performance and scale given programmers of equivalent talent and experience in the respective language.

And that’s just really hard to demonstrate. Which is why simplicity is brought up. Because the empirical proof is really hard to put together, you need to approach it from a more philosophical angle, a proof from first principles. So if you can show that independent, unwoven, composable pieces are less prone to defect, and more amenable to modifications and extensions, and can perform efficiently and at scale. And then you can show that Clojure lends itself to build apps using such independent, unwoven, composable pieces. Then you’ve made a pretty good argument in my opinion. Maybe as good as you possibly can given how hard it is to demonstrate these things.


it has been pointed out to me that one may try to reason in the following direction…

tomato - fruit / vegetable
light - wave / particle

but… i am not really sure if i like this parallel at all… :smile:

…now… i just came across the following… and i thought it to be quite delightful … so… i guess i just wanted to share this… you know… for the sake of promoting general amusement… :slight_smile: … also… mind you the date on that mail! :slight_smile:

Date: 3 Oct 92 08:30:03 GMT
From: (B. Gabriel Helou)
Subject: A Grim Fairy Tale
Newsgroups: rec.humor.funny

I don’t know where it originated, but I’ve seen this around the office
lately. It made me chuckle; it made me sigh.

                         A Grim Fairy Tale

Once upon a time, an American automobile company and a Japanese auto
company decided to have a competitive boat race on the Detroit River.
Both teams practiced hard and long to reach their peak performance. On
the big day, they were as ready as they could be.

The Japanese team won by a mile.

Afterwards, the American team became discouraged by the loss and their
moral sagged. Corporate management decided that the reason for the
crushing defeat had to be found. A Continuous Measurable Improvement
Team of “Executives” was set up to investigate the problem and to
recommend appropriate corrective action.

Their conclusion: The problem was that the Japanese team had 8 people
rowing and 1 person steering, whereas the American team had 1 person
rowing and 8 people steering. The American Corporate Steering Committee
immediately hired a consulting firm to do a study on the management

After some time and billions of dollars, the consulting firm concluded
that “too many people were steering and not enough rowing.” To prevent
losing to the Japanese again next year, the management structure was
changed to “4 Steering Managers, 3 Area Steering Managers, and 1 Staff
Steering Manager” and a new performance system for the person rowing the
boat to give more incentive to work harder and become a six sigma
performer. “We must give him empowerment and enrichment.” That ought
to do it.

The next year the Japanese team won by two miles.

The American Corporation laid off the rower for poor performance, sold
all of the paddles, cancelled all capital investments for new equipment,
halted development of a new canoe, awarded high performance awards to
the consulting firm, and distributed the money saved as bonuses to the
senior executives.


This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.