Moved
Heads up to anyone on this site (or RSS readers), I'm moving towards a custom-built django blog. More details on the new site.
This is the start of things to come (after my road trip), I promise.
For historical purposes, this site will remain here for a while.
Django’s Flaws
This is a response to Brandon Taylor. It was a bit lengthy, so I thought a post would be better off.
Like you, I felt this "poor" design pain from Rails. The less then spectacular docs (although that's changing too) made me prefer Django over it.
With that being said, the settings.py of Django is a crutch. There's quite a bit of needless configuration: You need to set template directories, installed apps, etc. While that's less than Java, why can't there be some reasonable defaults? Make template point to a local 'templates' subdirectory; default directory for media files; default to sqlite3 database config; time-zone defaulting to your computer's time settings; etc.
No migrations. Sure there are third party apps, but an official version would be nice. Most projects would be greatly aided by such a feature.
Django's reverse URL lookup system is a pain. Besides the fact that the {%url%} is usually long with all the parameters (imagine a date-based a blog post URL). get_absolute_url in models seem dirty and hackish, but it's a lot shorter. Rails' routes provides this style of url referencing (by model instance).
Why isn't there JavaScript integration with Django? Sure you can say it provides free choice, but that's why Rails has an advantage: it's not using the best javascript framework, in my opinion, but something is better than nothing. It's far easier to write simple javascript code through Rails then it is in Django.
Related to the JavaScript issue is the templating problem. A view function usually only directs to one template. How would one support themes? What about different templates based on the incoming client? This has to be manually handled by custom-view code. Rails' render_to dispatcher in the controller makes this a lot easier.
No doubt Django's admin is awesome; however, it's more towards data entry and site admin (hence the name) but not regular usage -- it's not designed for web apps which have users "managing" their own content: for that you want to create a polished experience for the end user. Validations for both frameworks are done through the model.
Recently, the admin interface has gotten a lot more extensible, but it's still designed for the site admin in mind. While Rails' scaffolding isn't great, it's closer toward user-generated content, you're improving the design on behalf of the end user going to see it. Writing HTML isn't fun -- for me at least.
If you like the argument from more of a Djangoist, I'll refer you to one of the creator's of Django.
http://simonwillison.net/2009/May/19/djng/
I've shared many of his pain points.
But Django's documentation is second to none in comparison to any open source project. Django's querying system through models is also great in comparison to Rails. Rails 3 intends to copy Django on that respect.
The merb probably slowed the progress of Rails in the recent years.
Clojure
I've recently picked up on Clojure, a LISP-dialect that runs on the JVM and I absolutely love it; but like other programming languages, it's difficult to convince others to try a programming language other than c/c++ or PHP.
Many friends are in the blub paradox camp: people view programming languages only in the mental model of his/her favorite programming language. Languages more powerful are deemed "unnecessarily complex", where languages less powerful are viewed as inferior.
In the Programming Languages course, we covered functional programming. The person next to me said:
"c++ can do functional programming, it has function pointers."
For someone that ever passed functions without any messy declarations knows that it's just not quite the same. Ruby is particularly nice with blocks, which is syntactic sugar for passing a function to another function:
with_file('myfile.txt') { |line|
puts line
}While with_file doesn't really exist in ruby, it can be easily implemented by someone to open a file, iterate it line by line, and close it. On the other hand, c doesn't provide as nice syntax for something like this.
In clojure, syntax is similar, with the (in)famous parenthesizes.
(with-file "myfile.txt" (fn [line] (println line)))Some people may say that's a lot of parenthesizes, like any other LISP, but they're mostly in different places. Idiomatically, this with-file would be a macro - a function that generates code to compile. A good use of a macro abstracts boilerplate code away: such as the declaration of the function in the example above.
(with-file "myfile.txt" line (println line))As you can see, lisp deals away with most of the character syntax that other languages have. Macros can do other handy language-abstractions. For example instantiating an object make take several statements:
MyClass obj = new MyClass();
obj.setProperty("value");
obj.doMagic();
obj.checkForErrors();There's some repetition here. Clojure has interop support with java, and supports java objects without any wrappers. The above code in clojure looks like:
(doto (MyClass.)
(.setProperty "value")
(.doMagic)
(.checkForErrors))For one more pair of parenthesizes, you get to avoid typing the type of class twice, and the variable you're operating on. All while maintaining the readability of the code. That's a pretty sweet deal if you ask me.
There are more issues Clojure touches upon. No doubt multi-threading is a growing concern as CPU manufacturers add more cores, but multi-threaded applications are difficult to make. Dealing with deadlocks is a perplexing experience many first-time threading programmers. Clojure's immutable data structures and concurrency semantics ensures no deadlocks. It's quite a different experience than worrying about if your code functions properly.
I'll leave it to you to check out clojure. Clojure's creator, Rich Hickey, is probably the better person to look for the design philosophies of clojure via his screencasts.