Hacker News Reader

I'm not sure why the team used single-letter names

I find myself doing this quite a bit. I think the reason is that it's so pervasive in the core.clj code. Take the documentation for update-in below:

  (update-in m [k & ks] f & args)
    'Updates' a value in a nested associative structure, where ks is a
    sequence of keys and f is a function that will take the old value
    and any supplied args and return the new value, and returns a new
    nested structure. If any levels do not exist, hash-maps will be
    created.

After having looked at a lot of clojure doc, those single letter names make sense to me (k = key, ks = keys, f = function). I use the same style when writing "core-like" functions, but anything remotely application specific is descriptively named.

That makes sense. I was under the impression that they were using it for their program-specific items. Using single letters for common things like k, v, f, args, etc seem more "universal" to other languages than using (defn f [a b c d e] ...).

Of course, he didn't show us any of the funky code he was talking about, but I get this impression from the line about using single letter names instead of highly descriptive names.

I should also take the time to look at the Clojure Core one day. Thanks for reminding me to put that on my to-do list.

Clojure Corey's worth reading, but know that it is considered to be extremely non-idiomatic. Several reasons:

1. Bootstrapping. Some functions are defined somewhat verbosely because the higher order functions are defined later.

2. Performance. By definition, everyone uses core, so core is on everyone's critical path. Therefore, core must sacrifice idiomatic code and brevity for performance. You should make the same tradeoffs only after measuring.

3. Evolution. Clojure has gained features and, since stability is valued, core doesn't get revamped to utilize them without greater justification.

> It is a wonder that they don't complain about the lack of frameworks a'la RoR/Django

No it isn't, because all the basic things needed are there ... Ring, Compojure, ClojureQL, etc... If those libraries where missing, then you'd see people complaining.

On the other hand this does highlight the advantage of using Clojure. Being a pragmatic functional programming language, it's easy to work with and combine small and simple modules, instead of needing a framework that includes the kitchen sink.

I write both rails and clojure.

There's no good clojure web framework for the fat stuff rails is good at, and it doesn't have the same level of plugin maturity, not by a long shot. That's years away. Clojure's good as an API server for a RIA, but it's probably less productive than rails for many use cases. The tools just aren't there, it takes years for tools to get that good. While the java integration is good, using clojure as java glue isn't so fun.

Clojure's strengths are speed, safety via immutable data, and being concise. It's great for a web server if you legitimately have a case where rails is too slow (you probably really don't though). Clojure's also great for non-web programming tasks.

My current project on which I've been working for the past 2 years is built on top of Python/Django and adjacent tools.

The thing I experienced is this - once you outgrow the primary use-cases for a monolithic framework, all of that nice packaging and conventions and modules that play well with each other - start getting in your way, soon to be replaced by custom implementations of whatever you need and all that time you saved initially will be extra time you have to spend to strip out those functionalities, in addition to the time take for building those same things from scratch.

I also worked with Rails btw - for instance you can find like a gazillion plugins for authentication and yet none of them did what I wanted on one project I had, so I had to implement my own authentication logic, after spending hours trying to tweak such a plugin first. That same project needed storage of files on S3, including pictures. Again, there are like a gazillion plugins for that, but none of them did what I wanted. So again, I had to implement it by myself. After trying endlessly to tweak Paperclip or others.

For this project I'm working on the admin interface was initially bootstrapped on top of Django's Admin. Which eventually became a liability and had to be replaced completely. The Django's ORM is also becoming a liability - because it couldn't handle queries for complex scenarios that were unrelated to "objects", so right now the project also makes use of SQLAlchemy - and I'll probably have to pull Django's ORM completely from the project, because the project is also doing sharding right now and I want to expand that to most tables and I can't work with a connection object that's a singleton, not to mention that the "objects" exposed will end up being completely different than the schema used in the DB table, so the object-mapping that Django's ORM does will stay in my way.

In the end, if I need to sum up the things that are still from Django in this project, there are surprisingly few things left.

So if you think about it, for small projects frameworks like Django/Rails are too heavy and for large projects they kind of get in the way and it's better off to start from scratch, importing components as needed, because that way you'll build abstractions that are suited for your domain and that will last longer.

Yes, I found Clojure frameworks, handlers and middleware to be lightweight and easy to use. I'm amazed at how well structured and easy to set up a Clojure web stack can be. Still working my way through the different libraries, and enjoying it.

" I started by rolling my own over and over again, only to discover a data structure or technique that erases 50 LOC and opens up a whole new world of program reuse. I have zero idea how someone coming from Python, Java, or Ruby would handle the transition, but I imagine it would be very messy at first."

This is a good point and keeps happening to me. Otoh, there are a lot built in (and so a lot not to reproduce accidentally). clojure/core has > 500 symbols in it[1]. Is there a systematic way to learn what is 'built-in' to Clojure vs waiting till one stumbles across specific items?

[1] (count (ns-publics 'clojure.core)) --> 580

(on the version of Clojure on my machine -> 1.4.0)

The cheat sheet's groupings can make finding things easier.

http://clojure.org/cheatsheet

Do the puzzles at www.4clojure.com and be sure to "follow" the top 20 or so users. Once you solve the puzzle, you're shown the solutions of those users that you follow. I learned a lot of neat tricks that way!

I read [1] and discovered some stuff there, but it's a bit hard to find new things there when you don't have application for them. In this case [2] really helped me - I subscribed to some top-solving users and after solving a problem I learned alternative approaches.

[1]: http://clojuredocs.org/quickref/Clojure%20Core

[2]: http://4clojure.com/

> Was it the lack of structure that made them go for it in the first place?

Here are the first two posts that discuss their decision:

http://www.pitheringabout.com/?p=693

http://www.pitheringabout.com/?p=749

Personally, I think "rolling your own" is the best way to learn things. Only when you understand things, when they are really internalized, use the built-ins.