Results from 2011 State of Clojure survey
Chas Emerick
The results are in:
http://cemerick.com/2011/07/11/results-of-the-2011-state-of-clojure-survey/
Cheers,
- Chas
Timothy Washington
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Ken Wesson
* The results seem to confirm the arguments here that there's a
problem with documentation and with the lack of a good "starter kit".
Making the command line REPL better might help in that regard too (tab
completion would not even be too difficult, given Clojure's
introspective capabilities; just prefix-matching against (map name
(keys (ns-map *ns*))) should do a decent job.
* Lisp is “oatmeal with fingernail clippings mixed in”? Who said that?
WHAT?! LARRY $*@! WALL said it?! Well HE's hardly one to complain
about Lisp's alleged readability deficits! :)
* It would be nice to be able to see superpositions of last year's and
this year's graphs somewhere, so the changes are made directly
apprehensible to the eye, where applicable (same questions asked in
both years).
* How would you characterize your use of Clojure *today* -- you do
know that HTML supports true italics, right? :)
* What is the status of Clojure in your workplace -- the numbers sum
to exactly 100, suggesting you made the options mutually exclusive.
But the middle item potentially could have overlap with the ones
directly above and directly below it and there are no "I don't know"
or "N/A" type options showing in the output data.
* Public relations -- Project status and activity. This area seems to
suggest the main Clojure page should be covered in tickers and feeds
of various kinds, but I'm not so sure about that. A lot of that stuff
would be just so much clutter to a lot of users -- and others might
find it *intimidating*: "What the heck *is* all of this stuff? Am I
expected to understand *all* of it before I can do anything useful
with this thing?". Google gets by with a very spare main page -- no,
in fact it's one of Google's major plus points. So there's certainly
no rule that says "success requires a cluttered main web page". My own
ISP's main web page is a huge mess of stuff mostly irrelevant to why a
customer would go to it -- random news tickers and other "portally"
stuff that has nothing to do with Internet service status, checking
your billing/usage/account setup, forwarding email while away, and the
like, and finding the latter is a pain. There's also what's been said
here about too many different possible "starter kit" configurations
mentioned, like emacs+SLIME, Enclojure+NetBeans, Eclipse+CCW... --
wouldn't that apply more generally to any large globs of stuff on the
front page? I'd suggest showing signs of activity in two main ways:
one, list the five most recent posts of some developer blog that gets
a new article every so often and two, possibly list the most recent
few threads to get new posts in this mailing list and link to them at
Google. And of course update the boilerplate cruft like the date on
the page regularly -- but a script can do that automatically, or even
dynamically generate the page with today's date. It's phony but it is
probably effective and doesn't add clutter, and adding the two feeds I
suggested doesn't add much and points people at this list and at
current developer activity. A few more things maybe wouldn't hurt
either, e.g. a Featured Library or Tip of the Week or some such,
changed weekly. The developer blog, if adopted, should include at
least two categories of items: development milestones achieved
(particularly, decisions made, things implemented, and releases) and
significant uptake events (this company/product/web service disclosed
using Clojure, Heroku started supporting Clojure, etc.).
"... so that people who wander into clojure.org can immediately have a
positive impression, rather than requiring of them an analytical
comprehension of Clojure’s minutiae?"
An argument could be made that Clojure is aimed more at those who do
that sort of "analytical comprehension" than those looking for the
latest jazzy fad, but an argument could also be made that attracting a
broader base is good and "jazzy fad" is a straw-man argument. :)
--
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.
Phil Hagelberg
> * How would you characterize your use of Clojure *today* -- you do
> know that HTML supports true italics, right? :)
Obviously *today* is meant to be rebound to a new value in the future.
-Phil
Ken Wesson
ROFL...
(doto
(Thread.
#(loop []
(Thread/sleep 86400000)
(set! *today* (Date.))
(recur)))
(.start))?
Meikel Brandmeyer
Am Dienstag, 12. Juli 2011 02:36:34 UTC+2 schrieb Ken Wesson:
An argument could be made that Clojure is aimed more at those who do
that sort of "analytical comprehension" than those looking for the
latest jazzy fad, but an argument could also be made that attracting a
broader base is good and "jazzy fad" is a straw-man argument. :)
Maybe clojure is not directly aimed at those "analytical guys", but simply made by one. So Rich maybe just doesn't see a problem?
Sincerely
Meikel
Sergey Didenko
Public relations -- Project status and activity. This area seems to
suggest the main Clojure page should be covered in tickers and feeds
of various kinds
Just a script that updates the date can backfire very badly if other site areas look outdated in the eyes of a random visitor.
That is coming from the common pattern observed in usability studies - a random visitor in "scanning mode" needs to decide quickly whether to trust the site. Thus a lot of clutter is bad, no news is bad, the latest date in the footer without noticeable news is bad.
An argument could be made that Clojure is aimed more at those who do
that sort of "analytical comprehension" than those looking for the
latest jazzy fad, but an argument could also be made that attracting a
broader base is good and "jazzy fad" is a straw-man argument. :)
When people are looking for a new shiny thing among 100 of other just new things, they can turn into "scanning mode" despite the fact that in other conditions they " do
Ken Wesson
<sergey....@gmail.com> wrote:
>
>> Public relations -- Project status and activity. This area seems to
>> suggest the main Clojure page should be covered in tickers and feeds
>> of various kinds
>
> I think the main site needs just a pane with a big noticeable header "News",
> that shows one-two latest important stories and updates one time per 5-15
> days. Also has a link, a few links on where to read much more news (feeds
> for blogs, aggregators, twitters, etc). It's purpose not to "create
> clutter", but to give an impression that "Clojure" is not outdated for a
> random visitor.
I know what the purpose would be. And also what the effect would be if
it was done badly, say by cramming every remotely relevant news feed
onto the front page. :)
> Just a script that updates the date can backfire very badly if other site
> areas look outdated in the eyes of a random visitor.
?
> When people are looking for a new shiny thing among 100 of other just new
> things, they can turn into "scanning mode" despite the fact that in other
> conditions they " do
> that sort of "analytical comprehension" "
What other new shiny languages are there with any traction? Scala, and maybe F#?
Colin Yates
--
Adam Burry
> FWIW, I like clojure.org the way it is. Without sounding like a complete
> muppet, I think of Clojure as a set of surgeon's tools, all clean and layed
> out on a shiny metal tray. Minimalist, simple, clean and massively
> effective once you have thought about it are the attributes I associate with
> Clojure and clojure.org fits that. On the other hand, I think of Scala as a
> bunch of "handy man" tools in a bag, slightly less coherent, messy and a bit
> more excitable and scala-lang.org re-enforces that.
Many of the tools are wrapped in plastic and you need a helper to find
them, open them, hand them to you, and clean them. You've got so many
layers on you can't feel anything. The patient is moaning with pain
and draped in so much stuff you can hardly tell they are human. And
for big jobs you use the same Black and Decker tools that home
builders use.
Adam
Colin Yates
--
Ken Wesson
> You've never seen a surgery up close.
>
> Many of the tools are wrapped in plastic and you need a helper to find
> them, open them, hand them to you, and clean them. You've got so many
> layers on you can't feel anything. The patient is moaning with pain
Let me know which hospital you went to so I can avoid ever traveling
there. Obviously their anesthesiologists aren't worth the paper their
degrees are printed on.
Sergey Didenko
He can choose between Python, server side Javascript, new C#, Go, Scala, F#, Haskell, Erlang, haXe, Clojure.
Besides the languages itself, the "outsider" wants to evaluate libraries, community, platforms, support, etc.
That could be much more challenging than comparing a few bare languages.
Colin Yates
That could be much more challenging than comparing a few bare languages."
--
Ken Wesson
<sergey....@gmail.com> wrote:
> You know that from inside. A Clojure "outsider" can have a completely other
> point of view.
>
> He can choose between Python
Not new
> server side Javascript
Not new
> new C#
Despite what you just said, not new
> Go
Haven't heard of it, so probably not shiny enough
> Scala, F#
Mentioned those
> Haskell
Not new
> Erlang
Not new
> haXe
Haven't heard of it, so probably not shiny enough
> Clojure.
So far, looks like the "shiny and new" category is Clojure, Scala, F#,
and maybe one or both of the Go and haXe you mentioned. The rest
definitely aren't particularly new.
> Besides the languages itself, the "outsider" wants to evaluate libraries,
> community, platforms, support, etc.
That puts Clojure and Scala ahead of F# and the three of them ahead of
nearly everything else.
Tamreen Khan
--
Ken Wesson
> What does something being shiny and new have to do with how good its
> libraries, community, platforms, and support are?
See below.
> Heck, I'd say something being new would detract from it library-wise.
Not necessarily, if it can interoperate with existing libraries, such
as is often the case with new JVM languages that can use existing Java
libraries.
> Sergey's point was that when
> someone begins a new project they have the options of all those languages;
> Clojure isn't just competing with new and shiny things.
In Sergey's own words:
When people are looking for a new shiny thing among 100 of
other just new things, they can turn into "scanning mode"
despite the fact that in other conditions they "do that sort of
"analytical comprehension""
So the discussion was specifically about a hypothetical developer
checking out *new* things. That developer probably already knows about
(and has rejected, for whatever reasons) C#, Python, Javascript, etc.
(aside from whatever they're currently using, but may want to move
beyond or supplement).
It's not hard to think up the likely objections from a lot of people,
too, and why they'd be looking for something new:
C#: Microsoft; no complete free software implementation
Python: poor performance
Javascript: interpreted, so slow; "isn't this just for adding annoying
ads to web pages"?; "I turn that shit off in my browser, why would I
want to actually write the stuff?" :)
Haskell: in its own universe without familiar tools and libraries;
ditto Scheme, Common Lisp, Smalltalk
Erlang: too different (but this is also likely to be leveled at Lisps
including Clojure).
C, C++: Pointer arithmetic, SIGSEGV, what is this, the dark ages?
Sounds like the goddamned Spanish inquisition!
Java: verbose, you need to write three classes and implement a whole
passel of interfaces, dependency inject a few megabytes of XML, and
apply the Singleton, Visitor, and Iterator patterns just to blow your
nose in this language.
Of course, there are others whose objections are much simpler:
C#: Not Lisp.
Erlang: Not Lisp.
Java: Not Lisp.
Python: List comprehensions and first class functions, but where are
my macros? Not Lisp.
Javascript: eval works on *strings*? You have *got* to be kidding me.
Not Lisp. Next!
Haskell: A bit like Scheme and it even has monads but syntaxy, with
type warts everywhere and no macros. So, not Lisp.
Smalltalk: the BlockContext lacks some of the capabilities of true
first class functions and *where* are my macros? Not Lisp.
C, C++: function pointers but no ability to declare anonymous
functions that close over locals and return them? And what the hell
kind of macro system is THAT?! Sorry. Not Lisp.
;)
Chas Emerick
I talked for a bit in the results post about mailing list threads going into the weeds; at least IMO, this one qualifies. It wouldn't be the worst thing in the world if it died right here. :-)
Cheers,
- Chas
Jeremy Dunck
...
> It's not hard to think up the likely objections from a lot of people,
> too, and why they'd be looking for something new:
> Python: poor performance
>
> Javascript: interpreted, so slow; "isn't this just for adding annoying
> ads to web pages"?; "I turn that shit off in my browser, why would I
> want to actually write the stuff?" :)
For what it's worth, the story is changing on both of these. See V8
and PyPy. I agree these still hold as common objections, but the
facts argue the perception now.
Ken Wesson
> On Tue, Jul 12, 2011 at 5:48 PM, Ken Wesson <kwes...@gmail.com> wrote:
> ...
>> It's not hard to think up the likely objections from a lot of people,
>> too, and why they'd be looking for something new:
> ...
>> Python: poor performance
>>
>> Javascript: interpreted, so slow; "isn't this just for adding annoying
>> ads to web pages"?; "I turn that shit off in my browser, why would I
>> want to actually write the stuff?" :)
>
> For what it's worth, the story is changing on both of these. See V8
> and PyPy. I agree these still hold as common objections, but the
> facts argue the perception now.
Yes, I know. In my opinion, the objections to JS and to Erlang that I
named are illegitimate (besides performance as an objection to JS,
anyway); but they're likely to reflect common perception and knee-jerk
reactions, too, and it is upon this fact that I was remarking.
Python's major weakness, in this multicore age, is the global
interpreter lock -- has there been any progress on creating a viable
Python breed that has true concurrency?
Jeremy Dunck
> interpreter lock -- has there been any progress on creating a viable
> Python breed that has true concurrency?
FWIW, Jython and IronPython don't suffer from the GIL.
CPython chooses to not penalize single-threaded performance in order
to boost multi-threaded. The GIL-removal approaches tried so far have
been based on finer-grained locks, which have single-threaded
overhead.
I think this makes sense given the maturity of the ecosystem and the
single-threaded legacy.
But PyPy doesn't have that constraint, and gives such good
improvements over CPython that I think they'd be wise to abandon the
single-threaded favoritism.
Ken Wesson
> On Tue, Jul 12, 2011 at 9:47 PM, Ken Wesson <kwes...@gmail.com> wrote:
> ...
>> Python's major weakness, in this multicore age, is the global
>> interpreter lock -- has there been any progress on creating a viable
>> Python breed that has true concurrency?
>
> FWIW, Jython and IronPython don't suffer from the GIL.
>
> CPython chooses to not penalize single-threaded performance in order
> to boost multi-threaded. The GIL-removal approaches tried so far have
> been based on finer-grained locks, which have single-threaded
> overhead.
Sounds like the interpreter is guarding global mutable state that is
mutated during ordinary program execution (and not just during
application bootstrap when the equivalents of defs and defns are run
to populate namespaces). Perhaps a deeper redesign is in order?
Jeremy Dunck
> On Tue, Jul 12, 2011 at 11:06 PM, Jeremy Dunck <jdu...@gmail.com> wrote:
>> On Tue, Jul 12, 2011 at 9:47 PM, Ken Wesson <kwes...@gmail.com> wrote:
>> ...
>>> Python's major weakness, in this multicore age, is the global
>>> interpreter lock -- has there been any progress on creating a viable
>>> Python breed that has true concurrency?
>>
>> FWIW, Jython and IronPython don't suffer from the GIL.
>>
>> CPython chooses to not penalize single-threaded performance in order
>> to boost multi-threaded. The GIL-removal approaches tried so far have
>> been based on finer-grained locks, which have single-threaded
>> overhead.
>
> Sounds like the interpreter is guarding global mutable state that is
> mutated during ordinary program execution (and not just during
> application bootstrap when the equivalents of defs and defns are run
> to populate namespaces). Perhaps a deeper redesign is in order?
Perhaps, but I think the more likely outcome is that PyPy becomes the
"standard" interpreter.
Devin Walters
Sent via mobile
pmbauer
Albert Cardona
"It seems that relatively few people are taking advantage of some of
Clojure’s most sophisticated and unique features: metadata; protocols,
records, and types; and multimethods. These facilities are absolutely
game-changers, at least IMO. Either most domains have no use for them
(I can’t believe that), or most people don’t know how to use them
effectively, thus they are left unused. Those of us that write about
and teach Clojure, take note."
What prevents me from using it is that clojure 1.3.* is still alpha or
early beta, and it's been for a long time.
If clojure 1.3 was released and development continued into 1.4, I
predict that protocols and records would suddenly start being used a
lot more.
Albert
Ambrose Bonnaire-Sergeant
Jonathan Fischer Friberg
From my own experience:
metadata, when I started to learn clojure, I thought "this is awesome". When I realized that metadata only applies to clojure types, it felt unreliable and I never got to using it.
protocols & records/types - they're straightforward, I use them.
multimethods - since close to every mention of multimethods also involves telling how slow they are, these are most often shunned.
Jonathan
Ambrose Bonnaire-Sergeant
multimethods - since close to every mention of multimethods also involves telling how slow they are, these are most often shunned.
James Sofra
abstraction provides gets you such a long way compared to collection
libs in other languages that you don't have to reach for the other
features as quickly.
I think Rich even stated that as one of the reasons for delaying their
introduction in the first place, he wanted people to become
comfortable making full use of seqs.
Cheers,
James S
On Jul 13, 9:03 pm, Ambrose Bonnaire-Sergeant
Chas Emerick
Phil Hagelberg
> "It seems that relatively few people are taking advantage of some of
> Clojure’s most sophisticated and unique features: metadata; protocols,
> records, and types; and multimethods. These facilities are absolutely
> game-changers, at least IMO. Either most domains have no use for them
> (I can’t believe that), or most people don’t know how to use them
> effectively, thus they are left unused. Those of us that write about
> and teach Clojure, take note."
Or it could just be that some of the other things on that list were so
compelling that they overshadowed these.
* The REPL
* Functional Programming
* Ease of development
These are the bread-and-butter of programming, so much that I'd have a
hard time ever working in (or even taking seriously) a language that
didn't support them. I'm a fan of using multimethods to achieve
polymorphism, but polymorphism is only needed in a small subset of the
code I write, while the features above affect *everything*.
-Phil
Ken Wesson
> Albert Cardona <sapr...@gmail.com> writes:
>
>> "It seems that relatively few people are taking advantage of some of
>> Clojure’s most sophisticated and unique features: metadata; protocols,
>> records, and types; and multimethods. These facilities are absolutely
>> game-changers, at least IMO. Either most domains have no use for them
>> (I can’t believe that), or most people don’t know how to use them
>> effectively, thus they are left unused. Those of us that write about
>> and teach Clojure, take note."
>
> Or it could just be that some of the other things on that list were so
> compelling that they overshadowed these.
>
> * The REPL
> * Functional Programming
> * Ease of development
Good point. Though the items on that question were not mutually
exclusive (you could tick more than one), it's likely some people
ticked the one they thought most compelling and that others ticked
three or four, but only the ones they considered to be "bread and
butter" rather than "the icing on the cake".
> These are the bread-and-butter of programming, so much that I'd have a
> hard time ever working in (or even taking seriously) a language that
> didn't support them.
What about ones that seem to go out of their way not to? Java comes to
mind. VB adds in "from Microsoft" and "no free software
implementation" for added fun. :)
Languages that do have those three items you considered crucial:
Lisps, of course, and I think Python and maybe even Ruby. Smalltalk
may be a bit of an oddball case: with its "BlockContext" closures it
has roughly half of FP available (there are limits on creating and
returning and then reusing them, or using them in multiple threads)
and its "Transcript" objects are something of a REPL (it's even
possible to create new classes and methods at it by typing the right
incantations, something like BaseClass subclass: NewName ...) and
interactive development and debugging there can make development
somewhat easier than in, say, Java.
Particularly, it's rapid prototyping and quickie testing that the REPL
helps, and modularization and making small, composable, easily
testable bits and clever HOF-based abstractions that FP helps, that
contributes to the third item on your list.
> I'm a fan of using multimethods to achieve
> polymorphism, but polymorphism is only needed in a small subset of the
> code I write, while the features above affect *everything*.
Hence icing vs. bread-and-butter. Or put another way you may
appreciate the socket wrench in the toolbox even if the jobs you do
mean you mostly use the hammer, the needle-nose pliers, the
screwdrivers, and the rotary tool and reach for the wrench only
occasionally.
Brian Marick
On Jul 13, 2011, at 6:03 AM, Ambrose Bonnaire-Sergeant wrote:
> I've found that (some of) Clojure's advanced features are best taught in terms of simpler ideas
> that most programmers would be familiar with.
+1
-----
Brian Marick, Artisanal Labrador
Contract programming in Ruby and Clojure
Occasional consulting on Agile
www.exampler.com, www.twitter.com/marick
Luc Prefontaine
Luc P.
--
Luc P.
================
The rabid Muppet
Sean Corfield
> What prevents me from using it is that clojure 1.3.* is still alpha or
> early beta, and it's been for a long time.
Well, those features are all in Clojure 1.2.0 so nothing is preventing
you using them.
That said, so far I haven't had much need for those features, although
we just added our first code using multimethods in the last week or so
(very slick solution to an event sourced email delivery analysis
problem - we dispatch on a dynamic combination of event and current
state so multimethods were the obvious, simplest and, in this case,
probably fastest solution!).
We're already using Clojure 1.3.0 in production at World Singles (in
fact our build today updated us to Beta 1 - we previously went live
with Alpha 7 and then used Alpha 8 in dev/QA for a while but were on
Beta 1 by the time we scheduled our next production build). We also
just added a cron job that uses lein run to execute a new scheduled
process - I was pleased at how straightforward that was, although of
course it "downloaded the world" the first time it ran (thank you
Maven!).
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
Sean Corfield
> Or it could just be that some of the other things on that list were so
> compelling that they overshadowed these.
>
> * The REPL
> * Functional Programming
> * Ease of development
True. Look at the results - the top five big wins are:
* Functional programming
* Platform (JVM) compatibility / interop
* The REPL
* Immutability
Next are Macros, Concurrency, Ease of development. Also "big wins". I
think folks would have to check almost everything to put the features
Chas highlighted into the "big wins" category.
Perhaps a more interesting question for next year would be: "Which of
the following Clojure features are you using?" - they don't have to be
big wins but it would be nice to know how widely used they are.
Chas Emerick
On Jul 13, 2011, at 8:37 PM, Sean Corfield wrote:
> On Wed, Jul 13, 2011 at 11:41 AM, Phil Hagelberg <ph...@hagelb.org> wrote:
>> Or it could just be that some of the other things on that list were so
>> compelling that they overshadowed these.
>>
>> * The REPL
>> * Functional Programming
>> * Ease of development
>
> True. Look at the results - the top five big wins are:
> * Functional programming
> * Platform (JVM) compatibility / interop
> * The REPL
> * Immutability
>
> Next are Macros, Concurrency, Ease of development. Also "big wins". I
> think folks would have to check almost everything to put the features
> Chas highlighted into the "big wins" category.
>
> Perhaps a more interesting question for next year would be: "Which of
> the following Clojure features are you using?" - they don't have to be
> big wins but it would be nice to know how widely used they are.
My phrasing may very well have gotten in the way. "Big wins" isn't exactly precise language. :-(
- Chas
Sean Corfield
>> True. Look at the results - the top five big wins are:
>> * Functional programming
>> * Platform (JVM) compatibility / interop
>> * The REPL
>> * Immutability
>>
Well, I think it clearly identified the "big wins" so it worked in
that respect! :)