> I'll have the draw of letting them work in the best tools, not making them compromise so it's easier for management to hire less serious programmers.
Why are developers who have not worked with Clojure "less serious" than those who have?
Why are developers who have not worked with Clojure "less serious" than those who have?
In a typical Java shop or enterprise code factory, after 2-5 years you reach a plateau and the only way up is to become an "architect" or move into management. So that's what the better people in the mainstream Java world want to do, and ultimately the tenor is focused on "enterprise architecture" and Spring/Hibernate add-ons instead of making beautiful, powerful, or maintainable software and solving hard problems.
The Clojure community (I'm at Clojure/West as we speak) is full of people who (a) are really good, like top 1%, and (b) have at least the intention to be career-long programmers (in some capacity).
That's something you don't see in the Java shops. Yes, there are good programmers in them, but they usually are planning a move into management because the way most companies do software is limiting and puts you at an artificial ceiling after no more than 5 years.
Is it a gross simplification to make this about languages? Perhaps, but the empowerment that languages like Clojure give to individual contributors can be a game changer. It's reminiscent of what startups used to be, before the VC-funded ecosystem became MBA Culture's west coast colony.
Says someone part of the Clojure community. How does it feel to be one of these top 1% developers?
This kind of attitude is why the Lisp community has had a terrible reputation for five decades.
I have attended the conj in the past and taken a bit of training in Clojure-based tools (Cascalog). These days, I am using Clojure for online programming challenges and various learning activities.
The Clojure community is like others - some people are very humble and welcoming. Some less so. But it feels like an open community in most cases and I say that as a true introvert.
My take on the idea of "top 1%" devs in Clojure is that there is a clear set of top Clojure hackers who are also invested in the craft of coding. It doesn't seem to be particularly ego-driven, but there are some incredibly hard-working devs in that group. I have observed a few, well-known names in that community invest a ton of time in reading academic papers, trying ideas out with Clojure implementations, and then quite publicly sharing the results. I think this was more what was being shared rather than chest-thumping of "oh, I'm at the Conj and you're not" perspective.
I think it says much more about you that you read that into the post, than it says about the lisp community.
fwiw I only program as a hobby and while I think clojure is great to write in, it's a severe pain in the ass to figure out what the hell someone else was thinking when they wrote their code.
The problem with clojure and all lisps, as I see it, is that they make it easy on the author, hard on the reader. It's so simple to create your own special DSL that everyone does it. Now i have to learn a thousand languages.
This is a bit of a problem in Clojure because Lisp gives everyone the ability to play at being a language designer, but there's a reason that most language designers are extraordinarily experienced computer scientists: designing easily readable languages is hard.
Where, in my opinion, Lisp's DSL abilities shine especially well is when the Lisper is just taking a well understood domain with well understood terms and translating those terms into Lisp. Where Lisp's DSL abilities can shoot the Lisper in the foot is when the Lisper creates a DSL for a problem domain that's less understood, and where the terms used in the DSL will be less immediately obvious.
A good example of Lisp's DSL abilities really shining through is Hiccup, the HTML compiler. For instance:
(hiccup.core/html [:body [:div { :id "divTop" :class "headingcontainer" } [:h1 { :class "superheading" } "Welcome!" ]]])
is understandable because we understand the concepts of 'htmlness' 'bodyness' 'divness' 'h1ness'. We understand what it means for something to be a 'body' in the terms of HTML. However, when the domain the DSL is modelling isn't well known to the reader, then the DSL becomes significantly harder to understand than normal procedural code.
So yeah, Lisp can be a bit of a double-edged sword, but it's also possible to see how it acts as a gigantic force multiplier for small teams who understand their problem domain really, really well. This is why I believe it makes such a fantastic startup language: to write really good Lisp, you have to understand the problem you're trying to solve really freaking well, and that's a big part of running a successful startup.
Every library you use in any language is a DSL that you have to learn.
Lisps give you more power when defining a DSL, which means people can make them harder to use and understand, but it also means they have the power to make it easier to use and understand.
Library still have to follow the semantics and syntax of its language host. DSL does not.
Claiming that a community you belong to is full of smart people doesn't mean you're claiming to be one of them.
But no, of course Clojure people are all the smartest programmers and are making all the biggest advancements in computer science.
Are you saying Clojure shops don't need architects? They don't need managers? Everyone just Clojures their way through "hard problems" and individually drives the business in new and more profitable directions? A language enables this?
Sorry, but claiming that a language is "empowering" doesn't somehow magically make anyone who uses it an uber genius.
Developers aren't a commodity and good developers don't want to be treated as a commodity. In the java world this means good developers don't stick around.
Companies that hire Clojure developers are frequently much more progressive about it (because if they weren't they wouldn't be using a language like clojure)
> I don't think they have any intention of climbing the management ladder because they didn't after two years
> I, arel, am in a good position to judge the quality of my previous coworkes, and they have all been fantastic!
Well, 'arel', first of all thank you for your useful contribution to hacker news.
Second of all, if in all of your 10 years in various companies (you also sound like you have been doing Java only, so this applies doubly so) you have never maintained any shitty Java code from a shitty Java programmer, well, you must either have been very lucky, or you must be one of them, don't you?
Some background just for you my friend: I've seriously programmed in (in order) C, C++, assembly, Java, Ruby and Python... and many other languages in between.
I've had to maintain, fix, performance optimise, make sense of badly written code in C, C++, assembly, Java, Ruby and Python.
Stop looking to demonise one set of developers and you will see that poorly written code and stupidity is everywhere, I can certainly see that.
Also thank you for creating an account just to reply to me. I'm honoured.
Seems like the key word here is "typical", and you risk drawing overly broad conclusions from your own experiences and/or the "conventional wisdom" one arrives at from reading too many forums.
I wonder how the software engineers who work at Google or Twitter and write applications in Java that "solve hard problems" feel about your assessment of their motives and goals.
The same thing of course applies in the other direction; you can't tell what someone's intentions are from the fact that they're using Clojure.
Average programmers don't learn Java because they're deeply interested in increasing the quality of their craft. They learn Java because it's what they were taught in school and/or because it will get them a job most easily. The bottom 80% of the programmer bell curve really doesn't give a shit about what kind of tools they use, as long as it keeps them employed.
When you get to programmers who really love programming, who want to write the best code possible and are willing to go out of their way to learn tools with very little chance of landing them that next corporate job, you're most likely in that top 20% already. So anyone who has learned Clojure, or at least can explain rationally why someone would want to learn Clojure (ie understands the benefits of functional programming), is probably not a benchwarmer idiot.
As a hiring founder who has absolutely zero interest in hiring below that top 20% (really, below the top 5%, ideally the top 1%), and has limited time to peruse a thousand basically identical resumes, applying a filter that gets rid of 80% of potential applicants is a Good Thing.
The point I was making was that there is a massive and grossly unfair generalisation solely about Java developers being made here and all over HN... that they don't really love programming, or want to write the best code possible. You might feel the language precludes that but then I would beg to differ and we are back to blub allegories.
By your own figures (which I don't agree with) the top 20% of a big number is a large amount of talented programmers you have excluded from your search because you cant get past the crud. Developers who have taste, know the JVM inside out and can write tasteful, readable, lightweight (yes) and highly performant code. Code that runs everyday in the big houses such as Google, Twitter, Linkedin...
I've interviewed many Java, Python and Javascript developers and our screening process helped to weed out the very hopeless, not perfect but most.
First a scan of their resume - is it generic, do they have experience in complex projects, a github account, a blog, contribute to open source, opinionated?
Second a real programming test that can test style, consideration of performance, typical gotchas. This should be automated so you can outright reject incorrect output... not fizzbuzz.
Other people more experienced on me have commented on just how bad the average programmers are at simple tests - across all disciplines.
http://blog.codinghorror.com/why-cant-programmers-program/ http://www.kegel.com/academy/getting-hired.html
I appreciate you don't have the time and you seek out developers who have challenged themselves with a more powerful language as your shortcut to find the elusive 1% but I imagine you'll find it is not insurance against poor architecture, algorithm selection, performance, unreadable code and applications that fall over in their first day.
The generalisations you and others make are unfair to a particular community of developers who just happen use a mainstream language (a sin in itself on HN) but care every bit as the rest.
But getting back to my original point way at the top of this thread, lost in the noise... I'm not using Clojure because I'm trying to put a snob filter into my hiring. I'm using it because it's the best tool for the job. I'm working with graph database and a graph data model. When I tried building it in an OO way (in Ruby, but I'd have the same problem in Java), I found myself violating the Law of Demeter and passing internal state around a lot. I felt I was choosing between good OO and good graph design - intermediate objects were messing with my architecture.
When I switched to Clojure and a functional paradigm, it all fell together beautifully. I feel very little friction between the requirements of the problem space and the requirements of the language. Right tool for the job, you know?
So what I'm addressing isn't a plan for hipster language snobbery - I'm finding the silver lining to the cloud of a relatively obscure language. Conventional wisdom avoids using non-mainstream languages because it's harder to find talent (read Crossing the Chasm for why). But in Crossing the Chasm terms, I want early adopters for my programming staff, not early majority. And Java is so mature that it's the choice of conservatives, much less early majority.
So maybe I'm not selecting for talent so much as personality type.
Measured by what metric?