On 04/05/2015 23:17, blake wrote:
I went from Ruby to Clojure in short-order and while I struggled
mightily with the functional aspect (after assiduously avoiding those
concepts for years), I much prefer every aspect of Clojure web
programming to Rails.

The bible of rails programming is the Hartl book. In the edition I read,
before you got to any actual programming, you were introduced to
14—fourteen! I counted!—different domains, including things like RSpec
and Cucumber. And it was all treated with this, "Well, you can figure
out what this all does because, hey, it looks just like English"
attitude, with a patina of "you don't need to know what's going on under
the covers".

The advantage of having an opinionated framework is that it saves one
the effort of having to make up one's own mind. This means you're
trusting someone with literally no understanding of your problem domain
to make up your mind for you. It's sort of amazing that this works at
all, and that there aren't =more= vulnerabilities turning up like the
Rails XML hack.
​
This made me really uncomfortable with Rails.

My current Clojure web app is more sophisticated than anything I did
with Rails, though my Rails apps doubtless carried far more untapped
potential. But I know just about exactly what it does. I know because I
added each piece of middleware as I needed it, and this allowed me to
understand what going on. I needed access to Mongo and MS-SQL, so I
added those. I needed a front-end so I started with Hiccup, which is
"obvious" (and remarkably similar to Smalltalk's Seaside, which I've
used), and then added in some Javascript.

I'll turn the Javascript into Clojurescript, but I felt that was too
much to absorb at once. And unlike Rails, I didn't need to absorb every
hot library du jour to get going. (And damned if in Rails, each tutorial
has a different idea of which libraries are essential.)

Then I added authentication, and threading (which was ridiculously
easy), and so on. Each piece as needed, with an understanding of what
was going on. Now, I don't get ALL of it. But I know where my weaknesses
are. I have, now, an opinionated framework, but it's made of =my=
opinions. And I made those opinions by looking at what the libraries I'm
using did, which is way simpler in a shallow functional world than in an
object-drill-down world.

In Rails, you don't know what you don't know.


Do the advantages you've pointed out apply to teamwork, though? That's supposed to be where frameworks make life easier.

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.

Reply via email to