devonrt

Django is arguably the most used Python web stack, but it's also a much more controversial choice than Rails is in the Ruby world. I hear "you'll outgrow Django really quickly" a lot; whether that's true or not I can't say since I've never used it. Also, there seems to be a lot more choices for web frameworks in the Python world: Django, Pylons, web.py, Tornado, Flask, CherryPy, Zope etc. I'm not sure if this is the case in the Ruby world. All I ever hear about are Rails and Sinatra.

Quieter, eh? I had a chance to drive the original a while back and it was already pretty damn quiet.

A really incoherent article that's wrong in a lot of ways. The title is misleading because the author's main beef is with the idea that functional languages are the "solution" to the concurrency "problem." He admits that he's tried to learn both Erlang and Haskell and given up because the languages are too hard, too complex and "absolutely full of academic shitheaddery" and points to the reference manuals of Haskell and OCaml as proof (edit to add: Erlang is the opposite of "academic shitheaddery". Totally born and bred for business!). I might come off as an asshole for saying this, but if attempting to learn and then giving up on Erlang and Haskell is your only experience with functional languages then you're not in a position to comment on it. Keep digging into Haskell until you run into a Monad Transformer stack a mile long or spend some time with Clojure.

The author then conflates Actor based concurrency with functional programming in general. Let me lay my bias on the table right now: I'm sick to death of hearing about Actors. Erlang put them on the map and I think Scala made them popular, but Scala missed the point. Erlang's actors are only one piece of its distributed-ness; there's a lot more to Erlang that lets it scale as well as it does: a VM tuned for a large number of green threads, a transparent network stack, the supervisor model etc. Scala has none of these. Not only that, but actors themselves only solve one tiny problem in the world of concurrent (really, for actors, distributed) computing. They do nothing to address shared state. Finally, neither of these languages is really, truly functional.

If the author has titled the post "Actors are Overrated" I might have agreed with it.

To get started with Clojure you need to know much about the Java platform. The first parts of Java that you will brush up against are classpaths and dot-separated namespaces and I don't think these are overly difficult to understand. clojure.core and clojure.contrib expose most of the Java standard libraries in a Clojure-esque way.

Agreed. The Android Market is an absolute ghetto compared to Apple's App Store. It makes me think there's room for a third party to build a better, more heavily curated marketplace for Android apps.

I agree with the spirit of the post, but not (many of) the actual points. Look at the list of languages the author points to in the first paragraph: PHP, Python, Ruby and Objective-C. Only one of these has anything remotely close to an "officially sanctioned experience" and that's because it's a proprietary system.

His first complaint is that getting started with Clojure involves starting a REPL and that this is not how actual development is done. Well, no, it isn't. It is however, where you will spend most of your time. Not only that, but the most accessible documentation on both the Ruby and Python official sites mostly involve using a REPL. Clojure's only problem is that running the REPL is slightly more involved. Also, Clojure 1.1 is not already outdated and I'm not sure where the author got this idea. 1.2 will have some great features, but AFAIK will be completely backwards compatible. I'm not sure where a beginner would even learn about 1.2 without some serious internet trolling.

Next the author complains about how difficult obtaining Clojure is difficult. There is a "Download" link right on the clojure.org homepage that lists zip files for both 1.1 and 1.0, both of which include the source. This is less difficult than getting Python or Ruby, which involves downloading and installing a pre-compiled binary or compiling it from source. Also, the author complains about 1.2 not being available, even though 1.2 has not been publicized and is still in beta; true beginners probably don't know that 1.2 even exists.

The author complains about the fact that there are a whopping three choices for IDEs for Clojure, despite the fact that each of these IDEs also have plugins for Ruby, Python and PHP. There are no fewer IDE choices for these languages. If you ask most Rubyist which IDE you should use many of them will tell you TextMate, and editor that is neither free nor cross-platform. The author then brings up Xcode; well, of course every Objective-C developer uses Xcode, they don't have much choice. Clojure's myriad of IDEs is not a problem unique to Clojure.

Build systems, again, I don't think this problem is unique to Clojure. Where is the great documenation for Rake? Or Buildr? What build system do Pythonistas even use? Seriously, I've been using Python for a while now and I have no idea if there exists a canonical build tool. Comparing these platforms to the likes of Objective-C and .NET in terms of tool support is just unfair, in my opinion.

Like I said, I agree with the spirit of the post. Clojure is not an easy language to get into, but it has very little to do with the points the author made. Much of the cognitive load involved in getting started with Clojure has to do with the fact that it's a Lisp and most programmers are used to ALGOL syntax and Object Oriented semantics. Another thing to keep in mind is that Clojure is an incredibly young language. Much, much, much younger than Python, Ruby, PHP, Objective-C or even Scala. Taking into account Clojure's youth it's amazing that it's as far as it is.

That guide is, sadly, very out of date and ironically linking to it probably makes it more likely to turn up first in Google search results.

Which parts did you find frustrating? Did you use ELPA? I ask because I've been using Clojure for so long now that I don't run into a lot of hurdles setting up new development environments.

Some of these arguments are very weak, especially for Kia which amounted to "Well, Ford and GM couldn't handle a dozen brands each so obviously Hyundai can't handle two." Couldn't the author give at least sales figures?

I'm currently planning a trip and have looked at both. CouchSurfing seems to rely a lot more on a sense of community, whereas Airbnd is more "business-y", which only makes sense given that CS is free whereas Airbnd is not. CS users are encouraged to maintain an up to date profile; the intricacy of some people's profiles rivals MySpace profiles of yore. Airbnd has a much nicer website.

Clojure has (roughly the equivalent) of problem #1. Java has a lot of, err, great libraries, I guess but many of them are, sadly, hidden behind a Java-esque API. To use them from Clojure you will need to spend time wrapping up the Java-esque nature of the API into something more Clojure-like and unfortunately the answer to the question "How do I do X in Clojure" is often "Use Java library Y." Thankfully Clojure's Java interop is relatively painless.

Personally I spent a long time in the Java world and then migrated to Python and Ruby. I was shocked at how easy to use many libraries are in the Python world. Libraries like Feedzirra, Mechanize, Python Twitter Tools and so on don't really have equivalents with respect to ease of use in the Java world.

Are gamers actually eager for a new Starcraft game? It's been my experience that Starcraft players are eager for a new Starcraft game.

The process has gotten a lot easier and Leiningen has made things way easier. lein-swank is just dreamy and comes close to providing all that nifty class-path handling functionality that something like Eclipse provides for Java. A lot of great work has gone into things like swank-clojure and Leiningen and it's amazing that the Clojure community has pulled together such a great set of tools in such a short period of time. There are languages on the JVM coughScalacough that have been around for a lot longer and really seem to be lagging behind in terms of tools.

This does not include Clojure, nor Leningen (the Clojure build tool), nor does it work on Windows or any environment that does not have apt-get. No doubt, you will end up with a perfectly suitable environment for playing around with SBCL.

edit to add: How does one even know to install SBCL and hit M-x and type slime to get started? You and I might already know these things, but it doesn't really help a stone-cold newbie, they still need a more concrete starting point.

I can attest to the fact that setting up a Clojure/Emacs/Slime/Leiningen environment is a huge PITA. Something like Clojure Box helps, but it sacrifices flexibility in favor of ease of use and hides a lot of underlying configuration from a new user. A big part of the problem is a lack of a "canonical" setup; if you Google around for Clojure and Slime most directions you find will be out of date, highly personalized, or both. They will probably involve checking projects out of a multitude of repos (be they CVS, SVN, or Joe Blow's GitHub branch) and copying mystifying emacs configuration without really understanding what it all does. And then, after all of that, it still might not work. God help you if you want to get it all to work under Windows.

Don't get me wrong, I love Clojure and I... well, I don't hate Emacs, but it's frustrating to have to deal with a lot of setup when one just wants to hack in a new language.

Yes, and it was my favorite part of the program!

(Sorry about the multiple login, I mistakenly logged in with clickpass last time)

As far as I can tell Apple doesn't really care how people use iTunes to play and organize their media; it's, at best, secondary functionality at this point. I'm sure there are developers at Apple working on this aspect of iTunes but I think the primary focus for iTunes from here on in will be as a gateway into the iTunes store and device syncing.

Which is a shame, really, because there aren't a whole lot of alternatives out there for OS X.

I didn't necessarily suggest that the menu not be organized at all, just that the strict categorical hierarchical menus are lame. Why do some text editors go under the Utilities menu and others under the Programming menu (like Emacs). It's hard for a new user to know which menu a program is going to be under immediately after installing it, so they have to scrub all of them until they find it.

Why not have a more semantic approach? Why can't I tag my applications and have the application menu be more like a tag cloud and let applications be under multiple menus. At least then I could put Emacs under Editors and Programming.

Calling 10.04 perfect is a real, long stretch. Even the authors own description of 10.04 hardly amounts to "perfect."

Its cosmetic changes are, in my opinion, dubious at best. Window controls are on the left hand side of the Window for no good reason. The color scheme is way too dark, it made me long for the old human theme. UI elements are glitchy in places. The "Me Menu" is useless to me. And why the heck did they ever remove the startup/shutdown options from the system menu? Why are they off on their own?

I like the idea of the Ubuntu Software Center but its execution leaves a lot to be desired. Last time I checked it was just another front end to apt. Many of the packages available are totally useless to the vast majority of people.

Ubuntu One and the Ubuntu Music store, well, we'll see how those go. Personally, I've never, ever used them and I have to wonder if they're the type of things that will actually draw people to Ubuntu

And, well, I hate to come off as a curmudgeon because I really do like Ubuntu, but to say that 10.04 blows OSX and Windows 7 out of the water is just wrong. It doesn't. For instance, why does Ubuntu still have the same old application menu? Both OSX and Windows 7 (and even KDE4) have moved away from this model. The categorized, hierarchical menus that have been around forever are really unhelpful. Why can't I search this menu like in Windows 7 and KDE4? For that matter, why can't I easily search everything like I can in Windows 7 and OSX (spotlight). If they really want to compete with Windows or OSX they need to give me better ways to find, sort and organize everything on my computer.

I appreciate the intent but I do find it a little annoying that I had to register, agree to a vague TOS and then verify my email address to look at the guides. The guides themselves were ok, but I'm sure similar information can be found elsewhere on the Internet without having to hand out my email address.

I like Processing, and you can do pretty much anything you want with it but I will point out that it was not necessarily built with charts, graphs, and plots in mind; it's relatively "low-level." Any type of graph or visualization you want will have to built pretty much from scratch with the primitives available. This might not put you off, but it's something to keep in mind.

For one, this was Pharo Smalltalk; a fork of Squeak that's still in beta. For another if I was shipping an application to a customer I probably wouldn't ship it with the workspace, or any of the development tools really. I would also consider buying a license for a commercial Smalltalk if that was the case.

It's funny because I had a really refreshing experience with Pharo lately. A part of the workspace threw an exception and I was presented with the option to debug it. Hitting debug brings up a debugger with the full stack available and the source of the error. Within a few minutes I was able to track down the error, fix it and have the fix go live immediately. Compare this to what it would take to debug and fix an error in, say, Eclipse. The difficulty of checking out the Eclipse source, dealing with potentially confusing and convoluted source code, wrangling with a labyrinthine ant or Maven build process etc. makes it not worth your while to fix the problem.

Whatever the pros and cons of the image based system may be the immediacy and transparency of it is really enjoyable. It's a shame that the idea has been pretty much abandoned by all but a small contingent of developers.