I got an error when I went to the link, you posted in the original post.
On Monday, July 30, 2012 1:08:40 AM UTC+5:45, Aaron Lebo wrote:
>
> Hi Samrat.
>
> Could you explain how you are trying to access the site (address) and what
> is happening?
>
> I started out in noir, and ended up using a lot of the design patterns and
> validation library. I stopped using noir for two reasons: I like being able
> to see the routes of all of my urls on a single page (noir binds them to
> their function definition), and a lot of the tutorials out there concerning
> different libraries are based on raw Ring or Compojure. I didn't want to
> get stuck debugging some minor issue simply because I didn't understand the
> differences between using a library with noir/Compojure, which did happen
> once.
>
> I really enjoyed noir, though, particularly the validation, it is very
> clever, though as I said earlier I'd love it if it did conversion as well
> as validation.
>
> Using Compojure was a blast. It rarely got in the way, which, imo is what
> a routing framework should do.
>
> On the templating side I used Hiccup. That might be one of my favorite
> libraries in any language. I desire writing templates in Python because you
> are stuck opening and closing every brace. It is tedious and error-prone.
> Hiccup cuts down on that tremendously.
>
> <div class="row">
> <div class="eight columns">
> <p id="test">test</p>
> <div id="yep" class="four columns">
> <span>yep</span>
> </div>
> </div>
>
> turns into:
>
> [:div.row
> [:div.eight.columns
> [:p#test "test"]]
> [:div#yep.four.columns
> [:span "yep"]]]
>
> You can't beat that. Notice particularly how easy it is to define ids and
> classes. Plus it is just Clojure, so you end being able to use the whole
> power of the language templating.
>
> On the db side I used korma. It beats the hell out of writing raw db
> statements, but it too stays out of the way. I really like the way that it
> just inserts joins as part of your result hash maps.
>
> (defentity profile)
> (defentity user
> (has-one profile))
>
> (select user (where {:id (*user* :id)}) (with profile))
>
> Something like that would automatically join profile to user and return a
> single hash map.
>
> It is a contrived example, but you get the gist. Only problem I had with
> it was that you end up writing by hand more complex stuff like unions. Not
> a big deal but you want the same convenience.
>
> On Sat, Jul 28, 2012 at 12:12 AM, Samrat Man Singh <
> samratmansi...@gmail.com> wrote:
>
>> I can't access your site. Also, I wanted to ask whether you used Noir or
>> used a lower-level option(Compojure,etc)?
>>
>>
>> On Friday, July 27, 2012 1:44:46 AM UTC+5:45, Aaron Lebo wrote:
>>>
>>> Hello!
>>>
>>> Sometime around 2 and a half months ago, I started to work on a new
>>> project using Clojure. I've been using Python heavily for about 6 six years
>>> working for a small direct mail company and before that started programming
>>> with Ruby on Rails. This new project was something out of left field, so I
>>> had different options on what technology to use. I ended up choosing
>>> Clojure, and my work on the site has been my first real experience using a
>>> lisp, Clojure, and the JVM. I'd like to share my experiences and how that
>>> has differed with my previous Python work.
>>>
>>> Before that, I'd like to make a little plug for my site. It is called
>>> kodefund <http://www.kodefund.com> (www.kodefund.com). The basic idea
>>> is to take the familiar Kickstarter model but to really focus on applying
>>> that to open source development. I feel that previous crowdfunding efforts
>>> have shown that there is an interest by developers to fund projects that
>>> they are enthusiastic about. When this works, everyone wins: the developer
>>> working on the project can devote their full time and effort on the actual
>>> project and still make a living and others get the benefits of the open
>>> source software. I feel like it is preferable over selling licenses to
>>> proprietary software or other efforts.
>>>
>>> So, every project on kodefund is required to be open source. This
>>> differentiates it from other crowdfunding sites, and helps to apply a
>>> filter: you know what you are getting when you go there instead of seeing
>>> dozens of projects for unrelated stuff.
>>>
>>> One other difference is that you can also start a project which is more
>>> or less a "reverse" Kickstarter. This allows you to take an idea for a
>>> project or issue you want fixed, raise funding, and find someone who will
>>> actually implement the project. Other users get to submit "applications"
>>> and you choose from them to find the most capable candidate. Once you chose
>>> an application, that person takes over the project.
>>>
>>> Finally, one other push I want to make is to open up proprietary
>>> software. Maybe your company has written some software in-house, but
>>> there's no real incentive to release it. What if you could crowdfund the
>>> software, get paid to release it, and the open source community as a whole
>>> could benefit from that?
>>>
>>> I feel like crowdfunding and open source software are an ideal fit.
>>>
>>> I'm getting off track here. I'll shift to my actual experiences using
>>> Clojure. I was more than a little nervous about using the JVM. It always
>>> seemed like some huge, scary thing, and digging into Java libraries was not
>>> something I wanted to do. Something which resolved this was leiningen. I
>>> feel like it is absolutely brilliant, and it really makes adding libraries
>>> to your project a non-issue. Things have slowly changed in Python, but it
>>> used to be that downloading dependencies was a global process and you ended
>>> up with a site-packages that was full of dozens of old libraries that you
>>> used for other projects. Being able to specify in my project.clj file
>>> exactly which libraries I need and those getting downloaded automatically
>>> is a really nice feature that I will look for similar functionality in
>>> other languages from now on.
>>>
>>> I was also pleasantly surprised by the library availability. The vast
>>> majority of things that I needed such as oauth2 support and such already
>>> have decent Clojure wrappers. When I did drop down into Java, I found that
>>> to be painless. The JVM really does have a wide swath of functionality
>>> already available. Some of the things that I ended up using were email
>>> libraries, date formatting libraries, and an rss feed generator. There
>>> never was a point where I felt like I was going to have to just roll things
>>> by hand. Most of the hard work has been done.
>>>
>>> Considering the language itself, one of the first things I noticed (or
>>> didn't) was the parentheses. I don't remember when, but they simply are a
>>> non-issue after a short amount of time. One slight thing I did have a
>>> problem with was that inserting a parenthesis at the wrong place could
>>> completely alter the flow of code and it was not immediately obvious. This
>>> is not an issue when you are closing off a line or two of expressions, but
>>> when you are halfway down the page, insert a paren and everything breaks,
>>> it could get frustrating. This is probably resolved through better editor
>>> usage. I unfortunately could never get emacs with clojure-mode and goodies
>>> working properly on my Windows machine, so I ended up using the
>>> counterclockwise Eclipse plugin. It was not a horrible experience but
>>> things such as auto-indenting a large block of code was something I never
>>> figured out.
>>>
>>> Continuing on the surface, some of my favorite parts of the language are
>>> little syntax additions. I absolutely love the syntax for anonymous
>>> functions. Python obviously has limitations with lamdas anyway, but in
>>> Clojure, having a block of code like: (do (println test) (+ 3 3)) and being
>>> able to instantly convert that to an anonymous function by sticking a # on
>>> the front is really nice. Not having to explicitly name function arguments
>>> helps as well.
>>>
>>> Destructuring syntax is amazing. Being able to break a map or a vector
>>> down and bind numerous variables in a let or function is something that
>>> simply is not easily done in Python without some magic. It was nice to have
>>> a function definition of something like (defn index [request] ...) in a
>>> view and to be able to grab relevant needed variables using the {:keys ...}
>>> syntax.
>>>
>>> The language is full of these little bits that are really convenient,
>>> and I was constantly surprised by something new which significantly reduced
>>> the amount of code I was writing. Having used it, it is straight up
>>> painful in my opinion to write markup in anything else. The -> operator,
>>> hash maps as functions, etc.
>>>
>>> One thing which surprised my was the macros. Initially I didn't use a
>>> single macro in my code, and I really couldn't figure out why the were so
>>> lauded and considered important by lots of lisp developers. That changed
>>> later in the project when I noticed a familiar pattern in my code. The
>>> basic problem was that pretty much every single web request has a familiar
>>> flow:
>>>
>>> Does the resource exist? If not, throw a 404.
>>> Does the user have the proper permissions to access the resource? If
>>> not, redirect to login or throw up a permission denied page.
>>> Is this a post? If not, render a form.
>>> If it is and the post is valid, do some work and redirect. If not valid,
>>> render the form.
>>>
>>> This got used over and over. In Django you often see this in the form of:
>>>
>>> def index(request):
>>> item = get_object_or_404(...)
>>> form = Form(request, item)
>>> if request.method == 'POST' and form.valid():
>>> do stuff
>>> redirect()
>>> render('index.html', dict(form=form))
>>>
>>> This isn't the worst thing in the world, but its just extra code that
>>> gets in the way of the literal intent of the code. When I noticed this
>>> pattern I ended up writing a macro which handled the resource check, the
>>> auth check, the validation check, the redirection, etc, for me. Once I got
>>> to this point, I really "got" macros and their power. You simply don't have
>>> the ability to implement your own flow control this easily in Python.
>>>
>>> Now, to thinking and working functionally. Python is imperative in
>>> parts. One of my favorite parts in it is the list comprehensions, which can
>>> be very functional. But for loops and destructive updates abound. Coding
>>> without for and accumulators was maybe the most difficult adjustment for
>>> me. However, once I started using map (with the aforementioned excellent
>>> anon function syntax), I started wanting to use it everywhere I could,
>>> because the concept was so simple. The same goes for reduce. Much of the
>>> pain of lacking destructive updates is mitigated with things like
>>> update-in, and such.
>>>
>>> I guess for me the real question is whether programming functionally
>>> actually reduces the number of errors as some functional advocates put
>>> forward. The problem is that it is so damn hard to objectively compare the
>>> two. Did I have more errors when I was programming in Python compared to
>>> Clojure? I'd say most of my errors actually came from unfamiliarity of
>>> libraries or functionality. The idea that errors can be reduced is
>>> interesting, but I'm not ready to fully commit to that suggestion unless we
>>> really see hard data. I do know that there are places where destructive
>>> updates would be convenient, but I can appreciate basis of programming
>>> functionally.
>>>
>>> Was there anything I missed when using Clojure compared to Python? The
>>> libraries seem to be a wash, the languages themselves are comparable. If
>>> anything I did want maturity in some of the libraries. For example, noir
>>> has an excellent error validation library. However, compared to Python
>>> libraries which do validation and conversion, I found myself writing and
>>> debugging extra functionality that I had to implement. I found myself
>>> digging around in github repos to actual read code instead of documentation
>>> a lot more than I ever did with Python. Obviously these are just issues of
>>> time, and they'll improve. Clojure docs and the cheatsheet help a lot,
>>> though.
>>>
>>> Stacktraces can take a while to get used to, and some of the error
>>> messages are cryptic. I can't say how many hours I spent figuring out why
>>> #([:key "test"]) wasn't working (you can't place a vector literal directly
>>> inside an anonymous function like this. Maybe that should have been obvious
>>> to me, but once I ran across these issues and understood them, the pain of
>>> understanding stacktraces was mitigated by a large margin.
>>>
>>> I guess if there is anything I'd love to see is some kind of style
>>> guide. Python has the PEP8 style guide, which more or less suggests how
>>> code should be written, not that it has to be written that way. There were
>>> lots of times I found myself wondering whether the "right" way was to
>>> indent the if form after the conditional or first argument, or whether it
>>> was considered "bad" form to nest multiple lets, and how that should be
>>> handled. The current cheat sheet is similar, but its not very prescriptive.
>>> I'd love to see something which suggests how common tasks should be done, I
>>> feel like it might help newbies like me feel more at ease. Does such a
>>> thing like PEP 8 exist for Clojure?
>>>
>>> Well, those are some of my notes on using Clojure. I feel a little
>>> embarrassed writing this up because I feel like someone will pick it to
>>> death, and I'm wish I could delve further into hard details instead of
>>> dwelling so much on little syntax differences. It has been a fun, useful
>>> learning experience, anyway. I feel like anyone who has not worked with a
>>> lisp or a functional programming language owes it to their own development
>>> to work with Clojure, it really does help you to understand the whats and
>>> whys of the JVM, macros, and functional programming.
>>>
>>> I'd especially love to see, kodefund, used by the Clojure community. I
>>> feel like it is a great way to get new libraries off the ground, or to find
>>> people to fix bugs, or even to open up previously closed software.
>>>
>>> If there was a project that you were considering putting on Kickstarter
>>> or one of the other crowdfunding sites, please consider kodefund. Unlike
>>> the bigger sites, you will have my full attention to your project, and I'm
>>> more than willing to work with you to improve and change parts of the site
>>> which make crowdfunding more suitable to open source projects.
>>>
>>> I've worked really hard to make things as simple as possible. You can
>>> start or fund a project no matter where you live, all that is needed to
>>> make a pledge is a credit card, and github, twitter, facebook, google are
>>> all supported to sign up. Give it a try, let me know what you think. I've
>>> tried to explain the rationale further here:
>>> http://www.kodefund.com/about/
>>>
>>> So, if you've got any questions about kodefund <http://www.kodefund.com>or
>>> Python/Clojure, I'm happy to answer them. Thanks to those who have spent
>>> their time making this such a useful language!
>>>
>>> --
>> 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 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
