On 04/05/2015 15:24, Timothy Baldridge wrote:
The thing that bugs me the most about these sort of conversations about
"best practices" is that they often present a set of solutions without
first analyzing the problem at hand.
If I came to this mailing list and asked "I want to write a websever in
Clojure..what should I use?". The response would most likely be Ring +
Compojure. Okay, not bad options, but that recommendation has been given
with absolutely no analysis of what I'm trying to accomplish. What if I
need async? What if I need web sockets? What sort of connection load am
I expecting? Will my system handle mostly persistent connections (like
websockets or SSE), or will it be more canned (and cacheable) data? If
someone recommends Ring to me, I may be pigeonholed into some system
I'll have to refactor later. Perhaps the best option is Aleph or Pedestal.
That's the real issue with canned responses like rails tutorial. They
assume my needs match your needs and match the needs of most people.
That's just not the best way to go about doing software development. And
it's a problem I've seen in so many areas of computing.
I've lost countless hundreds of hours of my life to frameworks that
default to bulky serialization formats (like XML or JSON), or frameworks
that assume LAN connections to the servers, or frameworks that assume I
won't be using multi-threading, or frameworks that assume I won't try to
load 10k rows on a single page, or frameworks that assume any number of
things. The thing I love the most about the Clojure community is that,
more than any other community I've been a part of, they try to ask you
to think before you jump.
So what I would recommend is more of a set of guidelines, and matrices.
List all the frameworks/libraries on one axis, and features on another,
and start commenting. Make a page like this:
(http://en.wikipedia.org/wiki/Comparison_of_video_container_formats)
Mention that Ring is well supported by the community, but doesn't work
well with fully async servers, mention that Aleph does all the async you
need, but is a bit non-standard. Mention that data.json is pure Clojure,
but cheshire is most likely faster.
Just present the options, and let the users make up their own minds. You
don't understand the needs of all of your users. So don't try to solve
their problems, instead present them with options and let them make up
their own minds. I guarantee you that whatever tech you recommend to
someone, the won't like some aspect of it, so better to present them
with all the options and let them choose, then they can only blame
themselves if it doesn't work out exactly like they expected.
A seasoned professional/Clojure guru like yourself will obviously prefer
a customised approach but the beginner and mid-level developer faces a
different problem - how to get something fully-featured up quickly and
maybe get paid for doing a job within a limited budget & timescale where
exploring all the options and how to fit them together just isn't an option.
I'm all in favour of library composition but not exclusively. In the
Python world they have Django and a tradition of do-it-yourself
lightweight options. I don't understand why we can't adopt a similar
approach.
gvim
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
