>>Do the advantages you've pointed out apply to teamwork, though? That's supposed to be where frameworks make life easier.
Frameworks make life easier for teamwork, sure—as long as everyone knows the framework and has the same (presumably correct =P) understanding of it. In practice here, everyone's understanding of rails was slightly different, and we had to establish a whole lot of in-house convention, and the churn on that was really painful. Like, we switched to using mountable engines. Cool idea, but it was ugly, and we ended up with pieces that were mountable and pieces that were not, and it was fragile and hard to deploy. We've had that problem across many iterations of Rails. (And, some teams having adopted Angular, it looks like there's going to be some issue there since the next version of Angular is supposed to be backward incompatible.) I just don't see that happening with the Clojure apps. I've let a complete neophyte add stuff to my main web app, and he's gotten useful work done. (He made some goofs because he didn't get the "stateless" thing, but that's about it.) I had a graphic designer come in and fix the Hiccup to make it more professional looking. She didn't have a hitch. Separation of concerns, simplicity, clarity...I guess they do have some value. On Mon, May 4, 2015 at 3:47 PM, gvim <gvi...@gmail.com> wrote: > 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. > -- 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.
