Clojure stack
László Török
--
Nick Zbinden
László Török
--
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
Nick Zbinden
does not really lack far behind scala/akka and its much simpler.
I don't really know about IDEs I can see how that could be a problem.
Timothy Washington
--
Sean Corfield
> This is an interesting discussion. Rich Hickey and Steve Yegge recently
> weighed in on the Seajure discussion group (and later discussed on HN).
> Yegge basically takes Laszlo's position (clojure needs to start saying yes),
> while Hickey takes Nick's position.
Looking at Yegge's list of "yes" languages, I wouldn't want to use any
of them (I have in the past and did not enjoy them - or at least not
for very long). The problem with "yes" languages is that they're
"kitchen sink" languages and they end up being a mass of confusing,
inconsistent, bloated, random stuff.
However, I really don't think that discussion - nor your quoting of
Phil's note about patches - has much bearing on Lázló's original
point. The typesafe folks, apart from offering consulting, training
and mentoring (which Clojure/core already do), are putting together a
standard "stack" / platform which is mostly already promoted (and to
some extent endorsed) by the core project, with the exception of Akka
- and it certainly makes sense for Akka to get rolled in these days.
Scala is trying hard to be Java.Next() and that really means it has to
present a unified, standard "stack" to the biggest Java community:
"The Enterprise". Scala wants corporate approval and wants Joe Java
Developer to be comfortable moving to Scala for corporate / enterprise
work.
I don't think it's realistic to think that Clojure will displace Java
in those environments - Scala is quite a big shift for such places,
Clojure would be a quantum leap! Clojure is also about four years
younger than Scala so I think we have a few years of maturing and
shaking out ahead in the area of tools and libraries before we're in
the situation Scala is in right now: able to standardize on a
recommended / endorsed set of commercially supported tools and
libraries.
I like Clojure because it's light and agile. I used Scala for a while
and it feels like Java, albeit much cleaner and more powerful - and
therefore more productive. For the vast majority of what I do / need
to do, Clojure is a much better fit than Scala / Java.
Another point that has a bearing on this discussion, IMO, is that the
Clojure community seems pretty divided between Emacs and non-Emacs in
terms of tooling / environment. I don't see that ever being resolved
so I don't see how a single, standard, unified Clojure "stack" could
appear that would / could really satisfy the "mass market"...
--
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)
Ken Wesson
> This is an interesting discussion. Rich Hickey and Steve Yegge recently
> weighed in on the Seajure discussion group (and later discussed on HN).
> Yegge basically takes Laszlo's position (clojure needs to start saying yes),
> while Hickey takes Nick's position.
>
> http://groups.google.com/group/seajure/msg/2d2ec7ac9f2b4713
> http://news.ycombinator.com/item?id=2466731
> https://groups.google.com/group/seajure/msg/daa02d326a9ec69a
After a cursory look at the first of these, I'd have to sympathize
with Hickey here.
Point 1: Yegge says "To get users, languages have to say Yes. You
can't ever say No."
This is a false dicohtomy. It's certainly possible to say Yes some of
the time, without saying Yes all of the time.
Point 2: Yegge says "You shouldn't force people to code in a certain
style -- and by 'force' I mean exerting cultural pressure by saying
things like 'If you would rather use Common Lisp, go ahead'".
But if Clojure starts accepting any randomly suggested features into
core (and particularly lots of mutable this, non-threadsafe that,
etc.) it will stop being Clojure and *become* Common Lisp, or
something more like it than like Clojure is now. And there's no point
in that. If you want a thread-unsafe, non-lazy, mutable Common Lisp
running on the JVM and calling Java libraries we already have Armed
Bear. Clojure must distinguish itself rather than be very like, but
incompatible with, an existing language if it is to survive. And so
far it has, but not if Yegge had his way.
But then there is a point that both sides have missed. Hickey says
this in response: "As far as 'languages have to say yes', I propose
the following thought experiment - YesLang. Each user of YesLang will
get a coupon entitling them to add or change one feature as their
needs require."
But each user of Clojure already has this coupon, and in a reusable
form. It's called "defmacro". If you want to significantly change or
add to Clojure, you can, even down to a pretty low level. If you want
other people to use your shiny new feature you can make your macro(s)
and supporting code available as a library -- though people may very
well choose not to use it. You can even implement your own reader, add
reader macros, and preprocess your code through that if you want to,
though nobody seems to bother, or fork the whole project, since it is
open source.
We also have:
> Technomancy has complained that...
> > Many patches etc run afoul of that because they don't meet that
> standard.
> The problem is not that they aren't applied, it's that they are ignored
> without discussion of their faults
If this is true, and the faults weren't so self-evident that they
didn't need any discussion, then we may have a problem. I'd need to
hear both sides of the story here though to judge, as I hope would
anyone in a stronger position to exert influence.
Timothy Washington
For the record, I'm trying to get a better understanding of the issues myself. So mea culpa. I should have provided more context on technomancy's statement. From my understanding, the issue had to do with technomancy not getting patches accepted at a faster pace, into clojure core (anyone with more insight, please chime in):
http://offtopic.bestinclass.dk/post/2532135003/has-clojure-development-stalled
But that's also been countered with the opposite - that Clojure has had breakneck pace and innovation (which from my vantage point, seems to be true). So I just took the broader acceptance / clojure stack vs. not, to be another aspect of which direction to pull the community (or, is the community saying "yes" enough). Sean, you're correct that they're not directly related technically.
I'm a former java developer, whose tried scala, ruby, etc. And with clojure, I haven't been this intellectually excited since I designed my first DSL :) So I'm interested to know if there are any problems and how to address. Thanks for the comments - clarifies things for me.
--
Chas Emerick
Sean Corfield
> I'm a former java developer, whose tried scala, ruby, etc. And with clojure,
> I haven't been this intellectually excited since I designed my first DSL :)
My commercial background is primarily (in historical order): C, C++,
Java, CFML - then later Groovy, Scala and now Clojure. Back at
university, I worked with Lisp a fair bit (and Prolog) and spent three
years doing research on functional language design and implementation
- then OO came along (with C++) and steamrollered everything else :)
I'm very pleased to see functional programming being taken seriously
again these days and attracting people from mainstream / OO
backgrounds!
> So I'm interested to know if there are any problems and how to address.
As Chas and others have hinted, tooling support is fairly immature for
Clojure and there's quite a split between the "old school Lispers"
with Emacs / Slime / Swank / etc (not intended as a knock but it seems
the folks who favor this stuff are long time Emacs and/or Lisp users?)
and the "former Java devs" with Eclipse / IntelliJ / NetBeans and
their plugins. Even on the build tool side we have Leiningen, Cake and
Maven fans. It's hard to tell whether a single choice at any level
will become the clear "winner" (and I'm not convinced such a thing
would be a good idea).
If you have a favorite IDE with your Java / Scala background, there's
a Clojure plugin for it that will probably suit you.
The game changer is likely to be having a live REPL in your IDE and
using it to adopt a very incremental, experimental approach to writing
code. I'm just getting into that mode now (after first picking up
Clojure about a year ago!) and finding it to be immensely productive -
and a radical change to how I used to develop. I find it much easier
now to figure out and build up solutions, a piece at a time, teasing
tests and small reusable functions out of my experiments so I
gradually evolve toward a clean, well-tested solution to each problem.
Alan
> > I'm a former java developer, whose tried scala, ruby, etc. And with clojure,
> > I haven't been this intellectually excited since I designed my first DSL :)
>
> My commercial background is primarily (in historical order): C, C++,
> Java, CFML - then later Groovy, Scala and now Clojure. Back at
> university, I worked with Lisp a fair bit (and Prolog) and spent three
> years doing research on functional language design and implementation
> - then OO came along (with C++) and steamrollered everything else :)
> I'm very pleased to see functional programming being taken seriously
> again these days and attracting people from mainstream / OO
> backgrounds!
CL, followed by a more enthusiastic leap towards Clojure.
> As Chas and others have hinted, tooling support is fairly immature for
> Clojure and there's quite a split between the "old school Lispers"
> with Emacs / Slime / Swank / etc (not intended as a knock but it seems
> the folks who favor this stuff are long time Emacs and/or Lisp users?)
> and the "former Java devs" with Eclipse / IntelliJ / NetBeans and
> their plugins.
terrified by it, partly because of the attitude of superiority Emacs
users tend to have. But I was learning lisp, and Emacs was reported to
be the best tool for lisp, so by God I learned Emacs. A year later: I
still use Eclipse for Java, and occasionally for its "Team" SVN
features, but I use Emacs for everything else. I try to hide my new-
found attitude of superiority :).
László Török
--
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
--
Sean Corfield
> For what it's worth, a year ago I had never touched Emacs and was
> terrified by it, partly because of the attitude of superiority Emacs
> users tend to have. But I was learning lisp, and Emacs was reported to
> be the best tool for lisp, so by God I learned Emacs. A year later: I
> still use Eclipse for Java, and occasionally for its "Team" SVN
> features, but I use Emacs for everything else. I try to hide my new-
> found attitude of superiority :).
I used Emacs fairly heavily back in the version 18 / 19 days (I had to
go look that up in Wikipedia... I actually thought I'd been using
Emacs 17 so maybe I started with it earlier than I now think), and it
was the best thing around (for the C and assembler I was writing).
Over the years, I've gotten used to other IDEs that feel more
integrated with their environment. Emacs hasn't really changed (which
is part of its strength, if you like that). Because of its association
with Lisp and the fact that so many Clojurians swear by Emacs, I tried
it again recently for Clojure but I couldn't get back into it after so
many years using Eclipse... and since I do work in several other
JVM-based languages, Eclipse was really a better fit for me anyway.
It's clearly a very personal choice tho' - I know lots of people who
don't like Eclipse and prefer IntelliJ or NetBeans, both of which I've
tried and can't get along with either :(
Gregg Williams
true on multiple levels. I'd like to focus the community's attention
on a neglected area that I believe is extremely important to Clojure's
success. I'll do so by restating Steve's main idea in slightly
different words:
Clojure needs to start saying yes...to newcomers.
That's a pretty self-evident statement to make, isn't it? If curious
programmers have a bad initial experience with Clojure, they'll just
leave. And I think this is happening. A lot.
Much of the "saying yes" discussion (see the discussions pointed to in
Tim Washington's post on 5/16/11) has to do with language and
implementation problems that lead to bad initial experiences with
Clojure. I want to focus on how the majority of the Clojure community
is contributing to bad initial experiences. To say it in the plainest
terms possible:
The Clojure community is, overall, newcomer-hostile.
The attitude that oozes from the words that are actually said sound
something like this: "We're smarter than you, and it shows in
everything we do. If you can't keep up, too bad. If you don't do
things the proper way--that is, the way *we* do them--you're not
welcome here."
Let me give you some examples.
EXAMPLE 1: clojure.org
Clojure.org is probably many newcomers' first exposure to the
language. On the "Functional Programming" page, the second page with
actual code in it, the reader is introduced to the defn keyword as
follows:
-----
defn is a macro that makes defining functions a little simpler.
Clojure supports arity overloading in a single function object,
self-reference, and variable-arity functions using &:
(defn argcount
([] 0)
([x] 1)
([x y] 2)
([x y & more] (+ (argcount x y) (count more))))
-> #'user/argcount
(argcount)
-> 0
(argcount 1)
-> 1
(argcount 1 2)
-> 2
(argcount 1 2 3 4 5)
-> 5
-----
And that's all it says.
Imagine being a newcomer to the language, probably someone who is
unfamiliar with any version of Lisp. Look at the terminology. What is
"arity overloading"? What is a "single function object"? What does
"self-reference" refer to? What does "using &" mean? And how does the
code sample work? If you've never seen Clojure code before, how could
you possibly expect this code snippet to make any sense, given this
*and nothing more* ?
Let's say the newcomer is lucky enough to get a REPL working. He
decides to use the built-in help system to find out more about defn:
-----
user> (doc defn)
-------------------------
clojure.core/defn
([name doc-string? attr-map? [params*] body] [name doc-string?
attr-map? ([params*] body) + attr-map?])
Macro
Same as (def name (fn [params* ] exprs*)) or (def
name (fn ([params* ] exprs*)+)) with any doc-string or attrs
added
to the var metadata
nil
user>
-----
Now imagine you're the newcomer who's used to looking at Java code.
Look at "([name doc-string? attr-map? [params*] body] [name doc-
string? attr-map? ([params*] body) + attr-map?])".
Which of these characters are actually something you'd type, and which
are notations that you *don't* type? What's an "attr-map"? What's the
format for a "doc-string"? There's *nowhere* on the clojure.com site
that tells you--or even give you hints on--how to make sense of this.
I still don't know how to read it, and I've been studying Clojure for
1 1/2 years! (And by the way, I do understand a lot about Clojure; I
wrote this article: http://pragprog.com/magazines/2010-11/getting-clojure.)
The problem is that the entire contents of the clojure.org site is
written by an expert, for experts. To a newcomer, it says, "This is a
language for Very Smart People, who don't need any more explanation
than this. If you don't understand--well then, this language is not
for the likes of you."
EXAMPLE 2: Cryptic code
Rich Hickey likes to use single-character variables, and code in
bloggers' articles often shows off Clojure's elegance through brevity
and minimalism. Such code may be praiseworthy when buried deep inside
a running application. However, it hurts the cause of greater Clojure
adoption when it's shown with little or no explanation in a blog
article. The result, unintentional as it may be, is that a beginner
thinks, "Yikes, how am I to make sense of this? They don't even bother
to give me any hint as to what is going on. Why bother even trying?"
Take, for example, the code below from one Clojure blogger. (I mean no
disrespect; this blogger has been most generous by sharing his
considerable skill with the community. My point simply is code like
this is easy to find.)
-----
(let [scoreboard {"Allison" [10 11 12 1e3]
"Franky" [5 2.34 1/4]
"John" nil}
scores (for [[player scores] scoreboard, score scores]
score)]
(/ (reduce + scores) (count scores)))
-----
Take a look at lines 4 and 5--there's a lot going on there, and it's
cryptic. It doesn't help that:
* the author uses very similar symbol names ("score", "scores", and
"scoreboard")
* the author uses the symbol "scores" to mean two different things
* in the surrounding text, the author doesn't even mention what the
code is supposed to do
I find this last point a lot in blog entries, sometimes even in
Clojure tutorial books: the author leaves several steps of learning
implicit and assumes the reader will infer them from the code itself.
Again, the message to the newcomer is, "We're writing for experts like
us. Find your own way in, if you want it bad enough."
* * * * * * * *
In conclusion, the Clojure community is unintentionally saying "no" to
beginners. It is doing so through its websites, its official
documentation, its community ambassadors (bloggers), and a lot of its
everyday conversation (Google groups, Hacker News, etc.).
I hope you can see that I'm saying these things only because I *want*
to see Clojure succeed. The community's "we're-all-experts-here"
mindset is driving newcomers away. (By all right, I should have been
one of them--but I'm an extremely stubborn cuss.)
Here's what will happen: Newcomers will walk out the door if we don't
give them every encouragement to stay, if we don't actively help them
with whatever problems they experience themselves as having. Clojure
will remain this quirky little fringe language with a small oddball
(but very smart!) following, less important than R or Lua or any
number of niche languages that have reached out to the larger
programming community.
Or...
*You* can decide to put some effort into Clojure's *social*
excellence, as well as its technical excellence. Talk to newcomers on
*their* terms; make them feel welcome. Remember that you once had
trouble understanding things about Clojure, and frame your answers in
ways that would help the old "newcomer" you. Spend just a little time
taking one newcomer under your wing. Show them code that promotes
their understanding, right now; once they understand, show them how to
"collapse it down" into the code that dazzles.
In the movie "Annie Hall," Woody Allen said something like, "A
relationship is like a shark. It has to be constantly moving forward
or it dies." I think this is true for a programming language as well,
and I think that "moving forward" means "growing the user base."
I've *been* saying yes to newcomers--go to http://www.GettingClojure.com
--but I need your help.
Are you ready to say yes...to newcomers?
Gregg Williams
manager, http://www.GettingClojure.com
On May 16, 7:33 pm, Timothy Washington <twash...@gmail.com> wrote:
> This is an interesting discussion. Rich Hickey and Steve Yegge recently
> weighed in on the Seajure discussion group (and later discussed on HN).
> Yegge basically takes Laszlo's position (clojure needs to start saying yes),
> while Hickey takes Nick's position.
>
> -http://news.ycombinator.com/item?id=2466731
> -https://groups.google.com/group/seajure/msg/daa02d326a9ec69a
> I think it's an interesting point of contention. Hickey has done a brilliant
> job of building a very elegant functional language. But should we dismiss
> Yegge's point altogether? He's not the only one making it. Technomancy has
> complained that...
> standard.*
> *The problem is not that they aren't applied, it's that they are ignored
> without discussion of their faults*
> Now, I don't want to reduce the conversation to gossip. But what IS the
> right balance between proper idiomatic code, and tools and training wheels
> for broader acceptance?
>
> Tim Washington
m...@mired.org
>Steve Yegge's main idea, that "Clojure needs to start saying yes," is
>true on multiple levels.
>I'd like to focus the community's attention
>on a neglected area that I believe is extremely important to Clojure's
>success. I'll do so by restating Steve's main idea in slightly
>different words:
>Imagine being a newcomer to the language, probably someone who is
>unfamiliar with any version of Lisp. Look at the terminology. What is
>"arity overloading"? What is a "single function object"? What does
>"self-reference" refer to? What does "using &" mean? And how does the
>code sample work? If you've never seen Clojure code before, how could
>you possibly expect this code snippet to make any sense, given this
>*and nothing more* ?
>Let's say the newcomer is lucky enough to get a REPL working. He
>decides to use the built-in help system to find out more about defn:
>
>-----
> user> (doc defn)
> -------------------------
> clojure.core/defn
> ([name doc-string? attr-map? [params*] body] [name doc-string?
>attr-map? ([params*] body) + attr-map?])
> Macro
> Same as (def name (fn [params* ] exprs*)) or (def
> name (fn ([params* ] exprs*)+)) with any doc-string or attrs
>added
> to the var metadata
> nil
> user>
>-----
>
>Now imagine you're the newcomer who's used to looking at Java code.
If the clojure community says "yes" to newcomers properly, then they won't be newcomers for very long - they'll be experts for most of the time they're using the language. That's why the reference manual that's clojure.org and the REPL documentation is right as it is.
>Look at "([name doc-string? attr-map? [params*] body] [name doc-
>string? attr-map? ([params*] body) + attr-map?])".
>
>Which of these characters are actually something you'd type, and which
>are notations that you *don't* type? What's an "attr-map"? What's the
>format for a "doc-string"? There's *nowhere* on the clojure.com site
>that tells you--or even give you hints on--how to make sense of this.
>I still don't know how to read it, and I've been studying Clojure for
>1 1/2 years! (And by the way, I do understand a lot about Clojure; I
>wrote this article:
>http://pragprog.com/magazines/2010-11/getting-clojure.)
>
>The problem is that the entire contents of the clojure.org site is
>written by an expert, for experts. To a newcomer, it says, "This is a
>language for Very Smart People, who don't need any more explanation
>than this. If you don't understand--well then, this language is not
>for the likes of you."
>EXAMPLE 2: Cryptic code
I'm going to skip this - there's not enough context to know if the examples were appropriate for the audience or not.
>Here's what will happen: Newcomers will walk out the door if we don't
>give them every encouragement to stay, if we don't actively help them
>with whatever problems they experience themselves as having. Clojure
>will remain this quirky little fringe language with a small oddball
>(but very smart!) following, less important than R or Lua or any
>number of niche languages that have reached out to the larger
>programming community.
>
>Or...
>
>*You* can decide to put some effort into Clojure's *social*
>excellence, as well as its technical excellence. Talk to newcomers on
>*their* terms; make them feel welcome. Remember that you once had
>trouble understanding things about Clojure, and frame your answers in
>ways that would help the old "newcomer" you. Spend just a little time
>taking one newcomer under your wing. Show them code that promotes
>their understanding, right now; once they understand, show them how to
>"collapse it down" into the code that dazzles.
<mike.
--
Sent from my Android tablet with K-9 Mail. Please excuse my brevity.
Sean Corfield
> Steve Yegge's main idea, that "Clojure needs to start saying yes," is
> true on multiple levels.
Well, there's always some truth in most of his rants but I'm not sure
I'd agree that the main thrusts of this particularly rant are true -
he conflates too many issues to be able to discuss it holistically
(unfortunately).
> Clojure needs to start saying yes...to newcomers.
I've actually found the Clojure community to be one of the most
welcoming and most helpful of almost any technology that I've picked
up in about 30 years. YMMV, I guess, and I'm sure it depends on your
programming background.
> That's a pretty self-evident statement to make, isn't it? If curious
> programmers have a bad initial experience with Clojure, they'll just
> leave. And I think this is happening. A lot.
Hard to tell how much it's happening really but I will concede that
I've seen a number of people struggle with the instructions here:
http://clojure.org/getting_started
Let's walk thru the process from a complete n00b's p.o.v. (since this
is the Getting Started page)...
First thing discussed, the github repo. If I go there (not wanting the
source but being hopeful about a download), and click Downloads, and
pick either the .tar.gz or the .zip options, I get an archive of
source code. Fail.
Let's try other downloads offered (since I don't want "alpha"
anything)... clojure-1.2.0.zip looks promising... OK, it is a full
source download but it *does* include a .jar file and java -jar
clojure.jar does actually start a REPL. Not a great experience but it
sort of works.
Back to the Getting Started page to see what next.... CLR? Nah.
Development collaboration on JIRA? Nah. Feedback and discussion on the
Clojure Google Group? Not clear that's going to help a n00b (but it
would!).
Link to Clojure Programming wiki. OK. (who maintains that and how
up-to-date is it?)
Explanation of what's in the download... Far more than a n00b needs to
know (bytecode library? really?)...
Suggestion: Under "Setup" at the top, provide a link to the Downloads
page: "Clojure releases can be <a
href="http://clojure.org/downloads">downloaded here</a>." Then
simplify the rest of the setup section so it's clear what a n00b
really needs.
Under "Editing" further down, change the Getting Started link to point
here: http://dev.clojure.org/display/doc/Getting+Started (it points
to, and mentions, the old Assembla site).
> The Clojure community is, overall, newcomer-hostile.
I think that's a broad overstatement, at best. See above - I've found
the community to be immensely helpful and welcoming. I think there is
a (fairly reasonable) expectation that developers picking up a new
language are willing to do _some_ amount of background reading and
experimentation rather than expecting everything to be handed to them
on a plate, especially with a language as new as Clojure.
> Clojure.org is probably many newcomers' first exposure to the
> language. On the "Functional Programming" page, the second page with
> actual code in it, the reader is introduced to the defn keyword as
> follows:
I agree that showing (defn hello "Hello world") first would be a
better experience for n00bs here and it's definitely arguable that
this page could use some love to make it more approachable. I think a
better approach would be to agree on a standard "learning Clojure"
site (perhaps the Clojure Programming wiki?) and direct folks there
for an introduction to Clojure.
> Imagine being a newcomer to the language, probably someone who is
> unfamiliar with any version of Lisp. Look at the terminology. What is
> "arity overloading"? What is a "single function object"? What does
> "self-reference" refer to? What does "using &" mean? And how does the
> code sample work?
I thought the code was pretty easy to understand and all of those
terms were familiar to me except for the use of &. I remember when I
first read that page and thought "OK, argcount empty list is zero,
argcount singleton list is one, argcount two element list is two,
argcount two plus something list is... hmm... add argcount two
elements to count of the something... that must mean that & more is
the rest of the arguments... that's kinda cool!". I didn't fully
understand it but it pointed me in the right direction.
> Let's say the newcomer is lucky enough to get a REPL working. He
> decides to use the built-in help system to find out more about defn:
Now, I will say here that most n00bs I've seen exposed to the REPL
expect two things to "just work":
1. typing help or (help) should display _something_ useful (even if
it's just a link to the docs),
2. typing exit, (exit), quit or (quit) should exit the REPL (if we
tell them control-d works in advance, problem solved).
Both of those could be solved fairly easily - if only by making sure
that both points are addressed on every "official" Getting Started
page when the REPL is first mentioned (i.e., a brief mention in the
documentation, rather than changing the code).
> Now imagine you're the newcomer who's used to looking at Java code.
>
> Look at "([name doc-string? attr-map? [params*] body] [name doc-
> string? attr-map? ([params*] body) + attr-map?])".
>
> Which of these characters are actually something you'd type, and which
> are notations that you *don't* type?
I'd instinctively expect something? to be optional and something* to
mean zero or more. Basic regex and something I've seen in
documentation for decades. I'm genuinely surprised you're asserting
there are developers out there who would not know that (I'm not
denying the possibility, just expressing surprise - it simply wouldn't
have occurred to me).
> What's an "attr-map"?
An attribute map... map of attributes... so it's some name/value
pairs. It's optional so I wouldn't worry about it at first - I'd
expect to see it in a definition at some point and try to figure it
out from that.
Perhaps I'm just used to reading language syntax specifications?
> What's the format for a "doc-string"?
I'd assume a plain ol' string used (somehow) for documentation unless
something told me otherwise (such as an error message or some
documentation). And it's optional so I probably wouldn't worry about
it until I saw some code - at which point it's pretty
self-explanatory.
> There's *nowhere* on the clojure.com site
> that tells you--or even give you hints on--how to make sense of this.
Hmm, you are right that doc-string is not explained on clojure.org.
It's mentioned in passing on the Special Forms page but that's it.
Fortunately, nearly all real Clojure code seems to have obvious,
readable doc-strings so I don't think people would be in the dark for
long.
> Rich Hickey likes to use single-character variables
And the Library Coding Standards page emphasizes that:
http://dev.clojure.org/display/design/Library+Coding+Standards
(I'm surprised it doesn't recommend k / v for key / value when dealing
with maps)
When I programmed in FORTRAN (and early Algol-family languages), it
was common practice to use i, j, k for loop indices so this doesn't
seem odd to me (and even today, programmers the world over tend to
assume i, j, k are loop indices and n is some sort of size / count).
> code in bloggers' articles often shows off Clojure's elegance through brevity
> and minimalism.
But isn't that part of the whole attraction of a Lisp? Code is elegant
because it is minimal, simple, brief...
> I find this last point a lot in blog entries, sometimes even in
> Clojure tutorial books: the author leaves several steps of learning
> implicit and assumes the reader will infer them from the code itself.
That is certainly a valid complaint to make to specific authors and
I'm sure most authors would appreciate such feedback since it would
help them get their message across better to their readers. I know I
always appreciate feedback that helps me write better blog posts.
> Talk to newcomers on
> *their* terms; make them feel welcome. Remember that you once had
> trouble understanding things about Clojure, and frame your answers in
> ways that would help the old "newcomer" you. Spend just a little time
> taking one newcomer under your wing.
Last week I gave an Introduction to Functional Programming talk at a
CFML conference. I mostly used Clojure as the example language
(although I also had some CFML examples). Several attendees started
trying Clojure out pretty much immediately and I expect to be helping
them get up and running via IM, email and my blog, with posts like
this:
http://corfield.org/blog/post.cfm/getting-started-with-clojure
(and several follow-ups where I've posed a small problem and offered
solutions in Clojure and other languages).
At work, I'm helping one of my colleagues come up to speed as we
introduce Clojure into our production codebase which is mostly CFML
with a little Scala. Over time I expect that to shift so most new code
written in the model is Clojure, with CFML used for the view /
controller portions (where that language really excels, IMO). I don't
expect our use of Scala to grow much.
It's also worth saying that there is a perfectly defensible position
that says if you dumb down the documentation and offer too much
hand-holding, you will get an influx of programmers whose skill level
may lead to a lot of poor code that then gets Clojure a bad reputation
as an unmaintainable, poorly performing language. Don't think it can
happen? Look at Basic, CFML, PHP which all have a reputation for
poorly structured code because of too many n00bs being able to pick
them up easily and write bad code.
Heck, even Java suffers from this to some extent! It has become so
mass-market that pretty much any programmer can pick it up and churn
out completely awful "OO" code. I've seen lots of terrible Java code
written by less-than-average developers because Java is sufficiently
newcomer-friendly. Perhaps it's inevitable as a language gets popular
but maybe we should not rush to enable that happening in Clojure... :)
Ken Wesson
> Now, I will say here that most n00bs I've seen exposed to the REPL
> expect two things to "just work":
> 1. typing help or (help) should display _something_ useful (even if
> it's just a link to the docs),
> 2. typing exit, (exit), quit or (quit) should exit the REPL (if we
> tell them control-d works in advance, problem solved).
Easy enough to fix:
(ns clojure.core
...)
...
(def help "See http://www.foobar.com/baz/quux.html for a tutorial.")
(def exit "Type (quit) to exit.")
(defn quit [] (System/exit 0))
>> Rich Hickey likes to use single-character variables
>
> And the Library Coding Standards page emphasizes that:
> http://dev.clojure.org/display/design/Library+Coding+Standards
>
> (I'm surprised it doesn't recommend k / v for key / value when dealing
> with maps)
Probably should. Most of the short-and-descriptive but
more-than-one-letter names for things will tend to shadow core
functions. Shadowing e.g. list is bad enough; list isn't called very
often, and if it's been shadowed by an actual list, boom!
#<CompilerException java.lang.ClassCastException:
clojure.lang.PersistentList cannot be cast to clojure.lang.IFn>
right at the call site. The error message pretty much tells you
exactly what's going wrong there, too.
Shadowing map is much worse, as map is called quite often, and if it's
been shadowed by an actual map you'll be scratching your head for
hours:
(map f some-seq)
with an actual map in a local named "map" will attempt to look up f in
it, and on not finding it (extremely likely) will return some-seq as
the "not found" value. This of course is exactly what (map identity
some-seq) would be expected to do, so you're likely to think f is for
some inexplicable reason failing to actually do anything and may spend
quite a while testing and debugging f and tearing out your hair before
realizing what went wrong. Oh, I think the benefits of Clojure being a
Lisp-1 are worth this risk, but it's something to watch out for.
Fortunately, most IDEs highlight the names of core functions
distinctively, so you should instantly realize if you're shadowing
something while typing in a new let or loop binding or argvec.
--
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.
pmbauer
The problem is that the entire contents of the clojure.org site is
written by an expert, for experts.
More verbose, newbie-friendly docs are important too, but take a lot more time and effort (clojuredocs.org, clojureatlas.com have great promise in this regard)
So I don't think this newbie-unfriendliness is out of malice or arrogance as much as perhaps one of focus and lack of resources.
Great newbie-friendly docs, starter kits, etc. take time and work - work that's honestly tedious compared to implementing a new concurrency construct or blazing fast primitive support. And in fairness, if you have the mind to do the latter, I'd rather not have that person wasted working on the former.
Granted there are broken windows on clojure.org that detract from its image:
e.g.
* spotty details on the contribution process (info scattered between jira, clojure.org, mailing list, no process info links on github)
* missing info/visiblity on state of clojure.next
* public hudson server often showing builds broken for weeks/months
EXAMPLE 2: Cryptic code
single-character variables
That it is a bit of an eye-brow-raiser for people of the "Uncle Bob" clean coder school that emphasizes verbose, literate naming conventions.
It's something to get used to - every language has its idioms.
The biggest inhibitor by far for adoption is tool support (unless you attend the Church of Emacs).
Compared to Scala and (especially) Groovy, Clojure tool quality is green, but acceptable for a three-year-old language.
These things take time.
Thorsten Wilms
> I've actually found the Clojure community to be one of the most
> welcoming and most helpful of almost any technology that I've picked
> up in about 30 years. YMMV, I guess, and I'm sure it depends on your
> programming background.
Same here, except 30 years ago, the technology I may have picked up
would have included pacifiers :)
That said, setting things up to work with Clojure really feels like an
investment, currently. http://try-clojure.org/ really helped me
regarding motivation to get through it. I started using Emacs because of
Clojure, after a failed attempt to set up CCW and I don't look back.
After initially installing a Clojure package on Ubuntu, I then learned
that it was totally unnecessary for a project using Leiningen ...
>> Look at "([name doc-string? attr-map? [params*] body] [name doc-
>> string? attr-map? ([params*] body) + attr-map?])".
> I'd instinctively expect something? to be optional and something* to
> mean zero or more. Basic regex and something I've seen in
> documentation for decades. I'm genuinely surprised you're asserting
> there are developers out there who would not know that (I'm not
> denying the possibility, just expressing surprise - it simply wouldn't
> have occurred to me).
Despite using ? and * in bash, that was not clear to me. I even briefly
thought about the use of ? to mark predicates, but of course that makes
no sense, here. It's hard to get into the shoes of someone who doesn't
know what you know. But all it takes in a case like this is about one or
two sentences of explanation.
> It's also worth saying that there is a perfectly defensible position
> that says if you dumb down the documentation and offer too much
> hand-holding, you will get an influx of programmers whose skill level
> may lead to a lot of poor code that then gets Clojure a bad reputation
> as an unmaintainable, poorly performing language. Don't think it can
> happen? Look at Basic, CFML, PHP which all have a reputation for
> poorly structured code because of too many n00bs being able to pick
> them up easily and write bad code.
I even heard complaints about there being way too many bad examples out
there for Python. Inevitable, at some point, if a PL goes mainstream, I
guess. Luckily, you just need enough users to build a healthy
eco-system, not take over the world.
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
Nick Zbinden
- The people in the comunity are genaraly very nice and help noobs
(stackoverflow, irc. mailinglist ...)
- Clojure.org has very cool content.
- Clojure.org is not a good place for noob
So i propose some things that I think would make a better clojure
expirance.
- A beginner friendly tutorial on the clojure getting started page.
- take the debugging proviling away form there and put them into
there own places
- How to get clojure running? There should be an example of how to
download, compile and start clojure AND there should be references to
the other ways to get clojure to run lein, cake, cljr
- On clojure.org should have more links to recources, for example all
books about clojure (like in scala http://www.scala-lang.org/node/959),
there should be EASY to find links to clojuredocs, gettingclojure ...,
the Videos interduced clojure many people the should be put on
clojure.org.
- The news don't get updated enough that makes it look like nothing
happens.
A lot of information is in the web (blog ...) we just have to collect
it and present it on clojure.org
Phil Hagelberg
> I've seen a number of people struggle with the instructions here:
>
> http://clojure.org/getting_started
>
> Let's walk thru the process from a complete n00b's p.o.v. (since this
> is the Getting Started page)...
>
> First thing discussed, the github repo. If I go there (not wanting the
> source but being hopeful about a download), and click Downloads, and
> pick either the .tar.gz or the .zip options, I get an archive of
> source code. Fail.
>
> Let's try other downloads offered (since I don't want "alpha"
> anything)... clojure-1.2.0.zip looks promising... OK, it is a full
> source download but it *does* include a .jar file and java -jar
> clojure.jar does actually start a REPL. Not a great experience but it
> sort of works.
point to 1.2.1. The zip of 1.2.0 contains a very broken "clj" shell
script. Not shipping a launcher with Clojure is a shame, but it's
better than including a broken one.
Then we have half the page talking about debugging and profiling, but
in all the time I've used Clojure I haven't ever felt the need to do
either of these things. Definitely not "getting started" material.
> Back to the Getting Started page to see what next.... CLR? Nah.
> Development collaboration on JIRA? Nah. Feedback and discussion on the
> Clojure Google Group? Not clear that's going to help a n00b (but it
> would!).
>
> Link to Clojure Programming wiki. OK. (who maintains that and how
> up-to-date is it?)
>
> Explanation of what's in the download... Far more than a n00b needs to
> know (bytecode library? really?)...
which only a handful of people have edit rights. If this were on the
wiki we could have cleaned it up by now. Perhaps clojure.org shouldn't
have its own "Getting Started" page at all?
The thing I've seen causing the most confusion (not specific to
clojure.org or the wiki but just "getting started" in general) is
simply the notion that you don't really need to "install Clojure" to
get running with it, which is very different from every other language
I've used. People start looking in apt-get or macports and may find
something (usually way out of date), but the vast majority of seasoned
users don't go this route, opting instead for Clojure build tools and
editor environment integration. I'd add this to the wiki this myself,
but naturally I'm afraid my version would be rather biased.
-Phil
pmbauer
Ken Wesson
The recommended way definitely should be one of the painless installs.
This works:
* Download NetBeans, configuring on the NB homepage for J2SE, and run installer.
* Run it and browse for plugins; find and install Enclojure.
* Restart NB and voila!
So does this:
* Download Eclipse J2SE.
* Run it and browse for plugins (Eclipse Marketplace); find and install CCW.
* Restart Eclipse, reset perspective, and voila!
(Warning, that second to last item is non-obvious, and the symptoms of
not doing it are also not obvious to diagnose.)
Both result in much nicer REPLs; but also the baggage of having to
create a project and start the REPL in that context. But then, they'll
also help you manage your .clj files.
pmbauer
The recommended way definitely should be one of the painless installs.
This works:
* Download NetBeans, configuring on the NB homepage for J2SE, and run installer....
So does this:
* Download Eclipse J2SE....
Ken Wesson
>> The recommended way definitely should be one of the painless installs.
>> This works:
>>
>> * Download NetBeans, configuring on the NB homepage for J2SE, and run
>> installer....
>>
>> So does this:
>>
>> * Download Eclipse J2SE....
>
> Sure, but that's still a lot of work just to get a simple repl.
If ALL you want is a SIMPLE repl you can just go to the tryclojure site. :)
pmbauer
If ALL you want is a SIMPLE repl you can just go to the tryclojure site. :)
László Török
http://www.infoq.com/news/2011/05/scala-29;jsessionid=BCF6B009442F5F0D9C18A06D3790C3DA
--
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
Wasn't someone posting here not long ago about a lightweight Clojure
editor/IDE they were working on? What ever happened to that?
At the same time, there's only so much you can shrink the install.
Don't forget the JDK alone weighs in at three-quarters of that:
jdk-6u25-ea-bin-b03-windows-i586-27_feb_2011.exe, 76.69 MB
(found on http://download.java.net/jdk6/6u25/promoted/latest/binaries/)
So, it's tryclojure or it's an at-least-75-meg download. One of the
prices we pay for being a JVM language, I guess.
Ken Wesson
> On Thu, May 19, 2011 at 5:58 PM, pmbauer <paul.mich...@gmail.com> wrote:
>> "So now you go download this 100MB IDE" is a little heavy. No?
> Don't forget the JDK alone weighs in at three-quarters of that:
>
> jdk-6u25-ea-bin-b03-windows-i586-27_feb_2011.exe, 76.69 MB
>
> (found on http://download.java.net/jdk6/6u25/promoted/latest/binaries/)
Oh, and that's the SMALLEST one on there, not counting the two tiny
Solaris 64-bit ones, which I can only presume can be that small
because a load of dependencies ship with 64-bit Solaris but have to be
bundled with the JDKs for other operating system.
Of course, "buy this $50,000 Solaris mainframe" is even worse than
"download this 100MB IDE" for heaviness. :)
pmbauer
David Nolen
Scala gets parallel collections (i.e. leverage multi-core CPUs)
http://www.infoq.com/news/2011/05/scala-29;jsessionid=BCF6B009442F5F0D9C18A06D3790C3DA
just to give this thread a new spark...:)
Ken Wesson
I take it you mean something distinct from pmap and preduce by
"parallel collections" here.
Ken Wesson
> Mmm, not quite.
> Doesn't clojure run just fine with the 15MB JVM?
Do you mean the JRE? And if so: for development, rather than just deployment?
pmbauer
Korny Sietsma
--
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
--
Kornelis Sietsma korny at my surname dot com http://korny.info
"Every jumbled pile of person has a thinking part
that wonders what the part that isn't thinking
isn't thinking of"
m...@mired.org
>I'm beginning to think this has degenerated a bit into argument for
>arguments sake.
>
>Yes, JRE. You don't need the JDK to read/eval .clj files. And in the
>context of where this all started, namely, critiques to the current
>getting
>started experience for new users, a 75MB JDK + 100MB IDE is exactly the
>sort
>of heavyweight, intimidating experience that detracts from initial
>exposure.
>Clojure isn't just competing with Groovy, Scala, and other JVM
>languages for
>developer attention. Websites like try-clojre.org have their place, but
>aren't really in this context.
Doesn't nearly everybody include a JVM with their OS distibution these days - with the exception of Windows? If so, then skip installing it for everyone but Windows, add the JRE to the Windows binary, and note that "unusual" Unix/Linux. Systems may need to install either the JVM or JRE (if someone is running one of those, they're almost certainly used to this by now).
Now add a clj script for Unix systems, a batch file for Windows (preferably one that can start from an icon) and similar for the Mac. For an editor, just bundle a properly configured copy of JEdit (until someone gets around to writing a light-weight IDE in clojure). Provide a writeup on "other editors/IDEs" containing pointers to paragraphs on how to install plugins for various popular IDEs and and how to configure other editors for tweaking clojure, along with instructions to load code into and switch to any REPL they support it.
That should get you a distribution that works with little or no hassle for most newcomers, and easily gets them to the point of being able to work on various web problem sets using Clojure.
Sean Corfield
> After initially installing a Clojure package on Ubuntu, I then learned that
> it was totally unnecessary for a project using Leiningen ...
Yeah, part of me wishes that Leiningen would get official endorsement
as "the" build tool for Clojure in the same way that sbt has become
the semi-official / partially-endorsed build tool for Scala. Having
tried to introduce quite a few people to Clojure that do not have Java
backgrounds, Leiningen has always ended up being the simplest choice
and the easiest for them to understand.
> Despite using ? and * in bash, that was not clear to me. I even briefly
> thought about the use of ? to mark predicates, but of course that makes no
> sense, here.
I was really puzzled when I first saw function names containing ? (and
other punctuation) but I've gradually gotten used to it. Even today
tho', I sometimes look at Clojure code containing things that don't
immediate say "identifier" and I have to squint and shake my head :)
> It's hard to get into the shoes of someone who doesn't know
> what you know.
Very true - and that's probably why the documentation isn't as
n00b-friendly as it could be.
Ken Wesson
> Lein is one such option, but unlikely to get official recognition giving
> clojure/core's (arguably correct) decision to stick to maven.
Talk about a heavyweight, intimidating experience. :)
Ken Wesson
This sounds workable. Though, again, I thought someone here already
was making a lightweight Clojure IDE?
Also, on Windows you might want to bundle the javaw from a JDK and not
just a normal JRE, even if not the full JDK (the OpenJDK license, at
least, should permit such a distribution). Otherwise users won't (for
some silly reason) have access to the server VM, and therefore won't
have access to that VM's superior HotSpot optimizations.
michele
amount of web pages trying - with good intentions - to help you
installing the Emacs-Clojure stack, but usually lacking some important
detail. It feels like playing a jig-saw puzzle without being able to
look at the picture on the box. Being new to Clojure and Emacs, you
really have to be devoted and have a lot of spare time.
On May 17, 9:17 pm, László Török <ltoro...@gmail.com> wrote:
> Chas, Sean, Alan,
>
> thank you for taking the discussion back on track. I completely support
> Rich's position re protecting Clojure form becoming bloated with half-baked
> features. (half-baked = conceptually and practically mature)
>
> I'm happy to have Rich as a "benevolent dictator for life" :) ( live a happy
> and long life, Rich, a keep the Clojure ball rolling! ).
>
> However, I'm not really ready to accept the fact that you have to be an
> old-school lisper (with Emacs et. al) to be able to use it with pleasure. I
> tried Emacs on Ubuntu, and I quit after two weeks, because I was simply much
> more productive using Enclojure. Maybe it's unfair, but every time I try a
> functional language IDE, I compare it to coding in F# using Visual Studio,
> which was a very pleasant experience.
>
> I'd say, it still wasn't quite 100%, but the editor, auto-complete, the REPL
> got better with every release.
>
> I'm probably unfair, as Enclojure will probably never get the financial
> backing as F# and VS has.
>
> Maybe I'll just try using Aquamacs again, and this time I'll try harder...
>
> Bests,
>
> Laszlo
>
> 2011/5/17 Alan <a...@malloys.org>
>
>
>
>
>
>
>
>
>
> > On May 17, 11:00 am, Sean Corfield <seancorfi...@gmail.com> wrote:
> > > On Tue, May 17, 2011 at 5:34 AM, Timothy Washington <twash...@gmail.com>
> > wrote:
> > > > I'm a former java developer, whose tried scala, ruby, etc. And with
> > clojure,
> > > > I haven't been this intellectually excited since I designed my first
> > DSL :)
>
> > > My commercial background is primarily (in historical order): C, C++,
> > > Java, CFML - then later Groovy, Scala and now Clojure. Back at
> > > university, I worked with Lisp a fair bit (and Prolog) and spent three
> > > years doing research on functional language design and implementation
> > > - then OO came along (with C++) and steamrollered everything else :)
> > > I'm very pleased to see functional programming being taken seriously
> > > again these days and attracting people from mainstream / OO
> > > backgrounds!
>
> > Me! I used Java and C for years before my abortive attempt to learn
> > CL, followed by a more enthusiastic leap towards Clojure.
>
> > > As Chas and others have hinted, tooling support is fairly immature for
> > > Clojure and there's quite a split between the "old school Lispers"
> > > with Emacs / Slime / Swank / etc (not intended as a knock but it seems
> > > the folks who favor this stuff are long time Emacs and/or Lisp users?)
> > > and the "former Java devs" with Eclipse / IntelliJ / NetBeans and
> > > their plugins.
>
> > For what it's worth, a year ago I had never touched Emacs and was
> > terrified by it, partly because of the attitude of superiority Emacs
> > users tend to have. But I was learning lisp, and Emacs was reported to
> > be the best tool for lisp, so by God I learned Emacs. A year later: I
> > still use Eclipse for Java, and occasionally for its "Team" SVN
> > features, but I use Emacs for everything else. I try to hide my new-
> > found attitude of superiority :).
> > --
> > 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
> It's not really the Emacs tools that are a problem, but the huge
> amount of web pages trying - with good intentions - to help you
> installing the Emacs-Clojure stack, but usually lacking some important
> detail. It feels like playing a jig-saw puzzle without being able to
> look at the picture on the box. Being new to Clojure and Emacs, you
> really have to be devoted and have a lot of spare time.
In my experience, this is common to a) anything to do with Emacs, b)
anything to do with Linux that isn't a big distro's own website-based
help, and c) pretty much every other large, low-budget open source
project, unfortunately.
Hackers hate writing documentation aimed at n00bs, so they rush the
job more often than not or else write only documentation that only
hackers can understand, or both.
At least when the tools are programming language tools the audience
consists almost purely of hackers, but even then hackers that are
n00bs to the particular thing, especially when it comes with a massive
paradigm shift, may have problems. And emacs, in particular, comes
with a massive paradigm shift. So does Clojure, if you're not *both* a
Lisper *and* familiar with functionally-oriented languages along the
lines of ML, Haskell, Scala, and Clojure. (I expect Schemers to have a
significant leg up on everybody else. I use "functionally oriented"
here to distinguish from languages that, while sometimes described as
"functional", have easy imperative/mutating use patterns as well --
Common Lisp, I'm looking at you.) So emacs PLUS Clojure ... Three
paradigm shifts for the price of one. Fun. :)
Lee Spector
On May 19, 2011, at 7:42 PM, Korny Sietsma wrote:
> Experienced developers (who are likely to grok clojure) probably already use one of ant / rake / maven / sbt etc.
"Experienced with what?" is the question. Those coming from the Lisp world, who are likely both to grok and to be ready to love Clojure, won't necessarily know anything about those tools.
> Even the IDE users probably understand the need to dip into the command-line for things like building deployable artifacts.
The need for the dip isn't the issue, IMHO, it's what you fall into when you dip -- that is, it's the complexity of what you have to dip into, how easy it is to figure out if it's all new to you, how much guidance is provided, etc.
-Lee
m...@mired.org
>
>On May 19, 2011, at 7:42 PM, Korny Sietsma wrote:
>
>> Experienced developers (who are likely to grok clojure) probably
>already use one of ant / rake / maven / sbt etc.
>
>"Experienced with what?" is the question. Those coming from the Lisp
>world, who are likely both to grok and to be ready to love Clojure,
>won't necessarily know anything about those tools.
Ditto for experience platform developers where the platform in question isn't the JVM.
>> Even the IDE users probably understand the need to dip into the
>command-line for things like building deployable artifacts.
>
>The need for the dip isn't the issue, IMHO, it's what you fall into
>when you dip -- that is, it's the complexity of what you have to dip
>into, how easy it is to figure out if it's all new to you, how much
>guidance is provided, etc.
This all actually ties back to my complaint that "Simple things aren't simple." Working on a web problem set is a "simple thing". Getting to a point where you can do that with Clojure isn't.
Lee Spector
On May 19, 2011, at 7:43 PM, mike.w...@gmail.com wrote:
>
> The "download the massive IDE" path seems to presume that a newcomer actually needs something more than "a simple REPL" in order to get started. I'd claim that's wrong - at least in a world where any computer you'd run clojure on can multitask and display multiple windows. Yes, a system where the editor and REPL are tightly coupled is much more productive, but that's at a micro scale. Running a simple editor in one window and a REPL in a shell/console window in another will do for starters - it'll still be a lot faster than a typical edit/compile/run cycle, and should be sufficient to get a feel for how Clojure is a win at the macro scale.
>
I agree that there's a sweet spot for newcomers here, where one uses a simple REPL (possibly invoked with lein) and an editor that's not tightly coupled, which should make it easier to provide a unified and idiot-proof download/install procedure. But I do think that you need an editor with a few essential features, at very least bracket matching and Clojure-aware auto-indenting. Last I checked JEdit (which you mentioned later in your message) does not have Clojure-aware auto-indenting, but I agree that if it did then this would be an attractive package for many newcomers.
I think there are a couple of other "95% of the way there" approaches out there for hitting this sweet spot (with different, small but significant flaws in each, as of the last time I checked).
-Lee
David Nolen
I agree that there's a sweet spot for newcomers here, where one uses a simple REPL (possibly invoked with lein) and an editor that's not tightly coupled, which should make it easier to provide a unified and idiot-proof download/install procedure. But I do think that you need an editor with a few essential features, at very least bracket matching and Clojure-aware auto-indenting. Last I checked JEdit (which you mentioned later in your message) does not have Clojure-aware auto-indenting, but I agree that if it did then this would be an attractive package for many newcomers.
Lee Spector
On May 20, 2011, at 9:48 AM, David Nolen wrote:
>
> The JEdit mode for Clojure has auto-indenting and bracket matching and it works just fine for me. If you weren't able to get that to work did you try contacting the maintainer of the mode?
>
Not that I recall but I did mention it in a discussion on this list back in March. Yes, bracket matching works in JEdit but at least as far as I can see (and I just tried the latest development build) it doesn't have what I consider to be Clojure-aware automatic indenting -- that is, where it indents according to standard Lisp conventions, as emacs lisp modes do, and Counterclockwise does (almost :-), and MCLIDE and TextMate clojure modes do, etc. Am I just missing something? I've tried Edit > Indent > Indent lines, and also the Tab key and various other things I could think of.
-Lee
David Nolen
Phil Hagelberg
> > It's not really the Emacs tools that are a problem, but the huge
> > amount of web pages trying - with good intentions - to help you
> > installing the Emacs-Clojure stack, but usually lacking some important
> > detail.
>
> anything to do with Linux that isn't a big distro's own website-based
> help, and c) pretty much every other large, low-budget open source
> project, unfortunately.
swank because the docs are actually pretty good; (I think; if they are
lacking in some way please speak up!) it's just that they are often
ranked by google below out-of-date blog posts.
Additionally, it's very easy to improve the official docs, but for
some reason people don't bother to try. I do not understand why.
-Phil
Lee Spector
To clarify, David, when you say "it just worked" you mean that when you select Edit > Indent > Indent lines then the line containing the insertion point is moved (left or right, as appropriate) to conform to standard Lisp indentation conventions with respect to the code above it (e.g. with respect to the position that you are within an s-expression, etc.)?
I note that there is some variation in what is the "standard" Lisp indentation convention in some cases, e.g. in certain special forms as opposed to ordinary s-expressions, but mainly I want to know what it is that you do to make "it" work and roughly what "it" is that then happens. I've had similar conversations with people in the Bluefish community and it turned out that for at least one person "auto-indenting" just meant lining up with the first non-blank line of the preceding line, without regard to the Lisp syntax. I kept saying that "it" wasn't working but it turned out that "it" was -- it's just that "it" wasn't what I meant by Clojure-aware auto-indenting.
Assuming that I understand what you mean by auto-indenting, and that you invoke it with Edit > Indent > Indent lines, does this also work for you for all lines of a highlighted selection?
In other words, I'm not yet sure if I'm actually experiencing a problem or if I'm just looking for a feature that isn't there. It would help me to know a little more about what you do and what you see when "it just works," so that I'll have a better idea of what I should ask/tell the maintainer.
Thanks,
-Lee
David Nolen
To clarify, David, when you say "it just worked" you mean that when you select Edit > Indent > Indent lines then the line containing the insertion point is moved (left or right, as appropriate) to conform to standard Lisp indentation conventions with respect to the code above it (e.g. with respect to the position that you are within an s-expression, etc.)?
Lee Spector
On May 20, 2011, at 3:30 PM, David Nolen wrote:
> Ah I thought you were talking about proper automatic indentation as you enter in code not selective *re-indentation*. As far as I can tell in the existing Clojure tools there are only varying degrees of interpretation as to what constitutes proper Lisp formatting.
>
> But I've found this to be the case regardless of what combination of programming language + editing tool I use.
>
> David
Ah -- okay, so in your terminology I guess I mean that it's Clojure-aware "re-indenting" that I think is a base-line requirement for a Clojure editor in the "sweet spot" of functionality that's necessary for non-trivial work but nonetheless simple enough, I hope, to be a target for a straightforward and relatively foolproof download/install process. Leiningen plus a simple-to-download editor with Clojure-aware RE-indenting and bracket matching would, I think, land in this sweet spot, providing a REPL and an editor and even easy project management via lein. It wouldn't provide other nice IDE features, but I think it wold be very helpful to have something like this.
The reason that I think that this re-indenting feature is so important is that I've found that it's often the most effective way to spot simple coding errors: ask the editor to indent things appropriately and if something looks odd it's because the syntax isn't what you thought it was. The helps me quite a bit even after decades of Lisp programming, and I've found it to be really valuable in a teaching context. FWIW reasonable versions of this feature are available for Clojure in (at least) emacs, Eclipse/Counterclockwise, MCLIDE, NetBeans/Enclojure, TextMate, ..., but in my experience all of these are somewhat outside of the sweet spot for other reasons. And some version of this feature is available in most other Lisp/Scheme environments (all that I've worked in, I think -- I've come to think of it as completely standard and necessary for Lisp coding). The implementations that I listed don't all agree on what the "correct" indentation is, but they all have some version of this feature.
BTW from what I can tell JEdit doesn't even do reasonable automatic indentation as you enter code in the first place. If I type "(defn foo" and hit return the cursor ends up under the second "o" in "foo", and that seems pretty weird. If I type "(conj '(a b c)" and hit return it lines up under the "a" which is even odder -- some would say it should end up under the single quote (that'd be my vote in this situation), while some would put it under the "o" or the "n", but I don't see any rationale for it being under the "a".
BTW also I mentioned MCLIDE above and I have to say that that's looking really wonderful to me these days, providing the stuff I mentioned above in a package with trivial download/setup and also many nice IDE features (including my all-time favorite feature, arglist-on-space). Clojure support is now fully baked in. I *think* (but haven't yet had the time to verify) that it should be pretty easy to integrate MCLIDE work with leiningen based projects, just by using lein from the command line and using "lein classpath" to get the info to paste into MCLIDE's launch scripts so that code run within MCLIDE finds everything. (Actually I think this might take a little tweaking but that it'll be relatively easy to automate...). The one big downside is that this only runs in Mac OS X.
-Lee
Michael Wood
On 20 May 2011 21:04, Lee Spector <lspe...@hampshire.edu> wrote:
>
> To clarify, David, when you say "it just worked" you mean that when you select Edit > Indent > Indent lines then the line containing the insertion point is moved (left or right, as appropriate) to conform to standard Lisp indentation conventions with respect to the code above it (e.g. with respect to the position that you are within an s-expression, etc.)?
>
> I note that there is some variation in what is the "standard" Lisp indentation convention in some cases, e.g. in certain special forms as opposed to ordinary s-expressions, but mainly I want to know what it is that you do to make "it" work and roughly what "it" is that then happens.
I've just given it a try now.
I went here: http://clojure02.managed.contegix.com/display/doc/Getting+Started+with+JEdit
Then I installed jedit. I'm using Ubuntu, so I just typed "apt-get
install jedit" and it installed without complaint. Then I tried to
install the clojure and clojureshell plugins, but that failed because
the version of jedit was slightly too old. (It's an old version of
Ubuntu, so not too surprising.)
The syntax highlighting and indentation seems to be completely
separate from the repl support, so I disabled the broken plugins,
downloaded the clojure.xml file from
https://github.com/djspiewak/jedit-modes/raw/master/clojure.xml and
put it into my ~/.jedit/modes directory, after which I edited the
~/.jedit/modes/catalog file as mentioned on the getting started page.
After that I closed and reopened jEdit. Not sure if that was
necessary. Then I created a file called test.clj and opened it with
jEdit. At the bottom of the window I see "(clojure,none,UTF-8)".
If I type in some clojure code it seems to be indented OK when I press
Enter, although it seems to be a constant 2 space indent instead of
depending on the particular form.
Also, if I mangle the indentation on a bunch of code I can click on
Edit|Indent|Indent Lines to indent the line where the cursor is, or I
can e.g. select all and then Edit|Indent|Indent Lines to indent the
whole lot the same way it does while entering the code manually.
So maybe the problem you're having is that jEdit can't find the
clojure.xml mode file?
This is the first time I've ever tried jEdit, so if the above doesn't
help, sorry, I can help you :)
--
Michael Wood <esio...@gmail.com>
Lee Spector
On May 20, 2011, at 5:08 PM, Michael Wood wrote:
>
> So maybe the problem you're having is that jEdit can't find the
> clojure.xml mode file?
>
Not sure, but it does say I'm in Clojure mode... I'm using Mac OS X, BTW...
It sounds from your other descriptions of your own experience like this failed the simple download/install test as well as my (idiosyncratic, I guess) minimal features test... (& btw for me "constant 2 space indent" is not the language-aware indentation/reindentation that I'm looking for.)
> This is the first time I've ever tried jEdit, so if the above doesn't
> help, sorry, I can help you :)
>
Thanks for trying and contributing in any event!
-Lee
Michael Wood
[...]
> BTW from what I can tell JEdit doesn't even do reasonable automatic indentation as you enter code in the first place. If I type "(defn foo" and hit return the cursor ends up under the second "o" in "foo", and that seems pretty weird. If I type "(conj '(a b c)" and hit return it lines up under the "a" which is even odder -- some would say it should end up under the single quote (that'd be my vote in this situation), while some would put it under the "o" or the "n", but I don't see any rationale for it being under the "a".
Well, that seems to be a constant 8 space indentation. If I were to
guess I'd say jEdit is not detecting your files as Clojure files and
is indenting them incorrectly as a result.
--
Michael Wood <esio...@gmail.com>
Michael Wood
>
> On May 20, 2011, at 5:08 PM, Michael Wood wrote:
>>
>> So maybe the problem you're having is that jEdit can't find the
>> clojure.xml mode file?
>>
>
> Not sure, but it does say I'm in Clojure mode... I'm using Mac OS X, BTW...
>
> It sounds from your other descriptions of your own experience like this failed the simple download/install test
Well, that might be a bit unfair, because I'm using an old, no longer
supported version of Ubuntu and just installed the version of jEdit in
the repositories for that version of Ubuntu. I assume that
downloading jEdit from the home page or using a later version of
Ubuntu would allow me to install the Clojure plugins.
> as well as my (idiosyncratic, I guess) minimal features test... (& btw for me "constant 2 space indent" is not the language-aware indentation/reindentation that I'm looking for.)
Yes, I agree that a constant two space indent is not ideal, which is
why I mentioned it.
>> This is the first time I've ever tried jEdit, so if the above doesn't
>> help, sorry, I can help you :)
eh... that was supposed to say "sorry, I can't help you", but I think
you got the idea anyway.
> Thanks for trying and contributing in any event!
No problem.
--
Michael Wood <esio...@gmail.com>
m...@mired.org
>On May 20, 2011, at 3:30 PM, David Nolen wrote:
>> Ah I thought you were talking about proper automatic indentation as
>you enter in code not selective *re-indentation*. As far as I can tell
>in the existing Clojure tools there are only varying degrees of
>interpretation as to what constitutes proper Lisp formatting.
>>
>> But I've found this to be the case regardless of what combination of
>programming language + editing tool I use.
>>
>> David
>is that I've found that it's often the most effective way to spot
>simple coding errors: ask the editor to indent things appropriately and
>if something looks odd it's because the syntax isn't what you thought
>it was. The helps me quite a bit even after decades of Lisp
>programming, and I've found it to be really valuable in a teaching
>context. FWIW reasonable versions of this feature are available for
>Clojure in (at least) emacs, Eclipse/Counterclockwise, MCLIDE,
>NetBeans/Enclojure, TextMate, ..., but in my experience all of these
>are somewhat outside of the sweet spot for other reasons. And some
>version of this feature is available in most other Lisp/Scheme
>environments (all that I've worked in, I think -- I've come to think of
>it as completely standard and necessary for Lisp coding). The
>implementations that I listed don't all agree on what the "correct"
>indentation is, but they all have some version of this feature.
So, instead of having an editor command region/function reindent to show the actual structure of the code, maybe you need to switch to a repl and run (indent-code "myfile.clj") to see what the structure really is. Actually, I would argue that that functionality ought to be in clojure to to provide a "standard" of sorts that various IDE's/editors can follow for indenting clojure.
>BTW from what I can tell JEdit doesn't even do reasonable automatic
>indentation as you enter code in the first place. If I type "(defn foo"
>and hit return the cursor ends up under the second "o" in "foo", and
>that seems pretty weird. If I type "(conj '(a b c)" and hit return it
>lines up under the "a" which is even odder -- some would say it should
>end up under the single quote (that'd be my vote in this situation),
>while some would put it under the "o" or the "n", but I don't see any
>rationale for it being under the "a".
Also remember, the idea is that we *bundle* a properly-configured Jedit with the distribution. I chose Jedit because it was reasonably light-weight, written in Java (so it should run anywhere Clojure does) and has most of the right features. Problems experienced in getting it downloaded & configured should be circumvented by making sure everything works properly in what gets bundled, never mind if it's the latest, etc. I still consider it a stopgap until someone writes a lightweight IDE in clojure, ala Python's IDLE.
Lee Spector
On May 21, 2011, at 4:47 PM, mike.w...@gmail.com wrote:
> Lee Spector <lspe...@hampshire.edu> wrote:
> >The reason that I think that this re-indenting feature is so important [etc]
>
> This is an important feature, and I had overlooked it - but does it have to be available in the editor? Remember, the goal is a "single download to clojure" with enough support to work on simple problems and get a feel for clojure, not anything that anyone might consider an optimal clojure develpment environment.
Personally I consider this to be a threshold feature (like bracket matching): without it, I really wouldn't want to use it for more than a quick demo, while a system with the threshold features of bracket matching and auto-reindenting would be adequate even for mid-sized projects, fine for an intro programming course, etc. Not as good as an IDE that integrates the REPL and the editor and other fancy features like symbol-completion and integrated documentation and arglist-on-space, and if one of those can come with a trivial setup process then I'd be all for that (and there are some projects that may be getting close on that -- MCLIDE looks the closest to me right now, although it's Mac only). But people could do quite a bit in a system with the threshold features without going crazy.
> So, instead of having an editor command region/function reindent to show the actual structure of the code, maybe you need to switch to a repl and run (indent-code "myfile.clj") to see what the structure really is. Actually, I would argue that that functionality ought to be in clojure to to provide a "standard" of sorts that various IDE's/editors can follow for indenting clojure.
I see bits of pretty-printing functionality are already present, although I haven't played with them and I'm not sure if they do this or if they're intended to. I agree that it would be great to have this functionality to help tool builders, if it's not already there. But I don't think it's particularly helpful to require users to cut/paste from their editor to a REPL and then back again to see the structure of their code. It's certainly not beginner friendly.
> The goal isn't even as high as "reasonable" - it's "usable." So even the vi :ai feature - which indents to the first non-whitespace character of the previous line - would do. If we can get a more useable behavior with some smarts about adding more indentation (and I'd agree, an automatic 8-space indent doesn't qualify), so much the better.
We may just disagree about this. I agree that it's possible to write Lisp/Clojure code without auto-reindenting but then again it's also possible to write it on punch cards or by shorting pins on an I/O card :-). Auto-reindenting is so ubiquitously useful for writing Lisp code, and apparently so easy to provide (since it's been in most Lisp editors for decades), and so important for beginners to allow them to see the syntax of the code they're writing, that I just wouldn't recommend ever writing Lisp/Clojure code in an editor that doesn't provide this. Providing auto-reindenting (along with a couple of other things like bracket matching) makes such a big difference that it makes the editor "usable" in a different sense.
> Also remember, the idea is that we *bundle* a properly-configured Jedit with the distribution. I chose Jedit because it was reasonably light-weight, written in Java (so it should run anywhere Clojure does) and has most of the right features. Problems experienced in getting it downloaded & configured should be circumvented by making sure everything works properly in what gets bundled, never mind if it's the latest, etc. I still consider it a stopgap until someone writes a lightweight IDE in clojure, ala Python's IDLE.
But some stopgaps fill bigger gaps...
-Lee
m...@mired.org
>On May 21, 2011, at 4:47 PM, mike.w...@gmail.com wrote:
>> So, instead of having an editor command region/function reindent to
>show the actual structure of the code, maybe you need to switch to a
>repl and run (indent-code "myfile.clj") to see what the structure
>really is. Actually, I would argue that that functionality ought to be
>in clojure to to provide a "standard" of sorts that various
>IDE's/editors can follow for indenting clojure.
>
>I see bits of pretty-printing functionality are already present,
>although I haven't played with them and I'm not sure if they do this or
>if they're intended to. I agree that it would be great to have this
>functionality to help tool builders, if it's not already there. But I
>don't think it's particularly helpful to require users to cut/paste
>from their editor to a REPL and then back again to see the structure of
>their code. It's certainly not beginner friendly.
I agree that having to cut & paste code to get a pretty printed version isn't useable - which is why I didn't suggest that. I suggested a function that would take a file name and pretty print the contents as code, which is as useable as reloading code in an environment without REPL integration. If JEdit doesn't have REPL integration, then this will integrate well with what users have to do to run code. If JEdit does, then possibly that can be used to create an in-editor code reindention, which would also integrate well with what users are used to.
This won't help much with getting pretty-printed code into your editor - but that wasn't the goal. The goal was to show the user the LISP structure of the code to help them figure out what's wrong with it, and this is a minimal tool to achieve that goal. Given that code, a function to save a backup copy of a file and overwrite it's contents with pretty-printed code should be easy, would be useful for getting propelry printed code to share with others (not one of the core goals, but one worth adding a little code for) and falls into the range of useable for that goal.
Pointing out a problem/missing feature is great - it's how tools become better. Insisting that the solution has to be the one you are used to, without considering the goals of the project in question, just help keep the existing roadblocks in place.
Lee Spector
On May 21, 2011, at 5:43 PM, mike.w...@gmail.com wrote:
>
> I agree that having to cut & paste code to get a pretty printed version isn't useable - which is why I didn't suggest that. I suggested a function that would take a file name and pretty print the contents as code, which is as useable as reloading code in an environment without REPL integration. If JEdit doesn't have REPL integration, then this will integrate well with what users have to do to run code. If JEdit does, then possibly that can be used to create an in-editor code reindention, which would also integrate well with what users are used to.
>
> This won't help much with getting pretty-printed code into your editor - but that wasn't the goal. The goal was to show the user the LISP structure of the code to help them figure out what's wrong with it, and this is a minimal tool to achieve that goal. Given that code, a function to save a backup copy of a file and overwrite it's contents with pretty-printed code should be easy, would be useful for getting propelry printed code to share with others (not one of the core goals, but one worth adding a little code for) and falls into the range of useable for that goal.
>
> Pointing out a problem/missing feature is great - it's how tools become better. Insisting that the solution has to be the one you are used to, without considering the goals of the project in question, just help keep the existing roadblocks in place.
If I understand correctly you're suggesting that a user working with an editor and a REPL, which aren't connected, run something in the REPL to see the structure of the code. Not un-useful, but of course the user will probably want the code in the editor to reflect that structure, which will require either manual matching of what they see in the REPL, or cut/paste, or the kind of overwrite functionality that you describe (which might then confuse JEdit, if you're overwriting a file out from under it). I don't think I'm insisting that the solution has to be the one that I'm used to, but none of these sound like great options while the decades-old in-editor-reindentation approach seems to be viable and time-tested.
-Lee
m...@mired.org
>If I understand correctly you're suggesting that a user working with an
>editor and a REPL, which aren't connected
That being the mimimal configuration that I think of as "useabe".
> , run something in the REPL to see the structure of the code.
>Not un-useful, but of course the user
>will probably want the code in the editor to reflect that structure,
>which will require either manual matching of what they see in the REPL,
>or cut/paste, or the kind of overwrite functionality that you describe
This is a *different* problem than the one being solved, which is getting an accurate representation of the structure of the code. In particular, it's different enough that I don't think it makes the required list for a minimal "getting started with clojure" package. So it'd be nice to offer, but it being missing or a bit painfull isn't a show-stopper.
>(which might then confuse JEdit, if you're overwriting a file out from
>under it). I don't think I'm insisting that the solution has to be the
>one that I'm used to, but none of these sound like great options while
>the decades-old in-editor-reindentation approach seems to be viable and
>time-tested.
I'd be surprised if stand-alone code beautifiers weren't decades older than auto-indenting editors. So they are both viable and time-tested. More importantly, it should be a lot easier to write a Clojure function to pretty-print a file than to write a Jedit plugin to auto-indent one, or at least find someone willing to do so assuming it doesn't already exist. While I'd prefer an in-editor solution, I don't think it's important enough to delay things even a few minutes. That, of course, is the real issue - how quickly can we put up an acceptable "single-download to clojure" distribution? Which is why all this is academic until someone who can update clojure.org to point to the download steps up and says "these are my requirements to do that."
Lee Spector
On May 21, 2011, at 6:47 PM, mike.w...@gmail.com wrote:
> This is a *different* problem than the one being solved, which is getting an accurate representation of the structure of the code. In particular, it's different enough that I don't think it makes the required list for a minimal "getting started with clojure" package. So it'd be nice to offer, but it being missing or a bit painfull isn't a show-stopper.
We've really beaten this into the ground, but at least this makes our positions clear: if this feature is missing it does stop my show, and I understand that it doesn't stop yours. People can take that all for what it's worth.
Thanks, -Lee
Laurent PETIT
> Lee Spector <lspe...@hampshire.edu> wrote:
>>If I understand correctly you're suggesting that a user working with an
>>editor and a REPL, which aren't connected
>
> That being the mimimal configuration that I think of as "useabe".
>> , run something in the REPL to see the structure of the code.
>
>>Not un-useful, but of course the user
>>will probably want the code in the editor to reflect that structure,
>>which will require either manual matching of what they see in the REPL,
>>or cut/paste, or the kind of overwrite functionality that you describe
>
> This is a *different* problem than the one being solved, which is getting an accurate representation of the structure of the code. In particular, it's different enough that I don't think it makes the required list for a minimal "getting started with clojure" package. So it'd be nice to offer, but it being missing or a bit painfull isn't a show-stopper.
>
>>(which might then confuse JEdit, if you're overwriting a file out from
>>under it). I don't think I'm insisting that the solution has to be the
>>one that I'm used to, but none of these sound like great options while
>>the decades-old in-editor-reindentation approach seems to be viable and
>>time-tested.
>
> I'd be surprised if stand-alone code beautifiers weren't decades older than auto-indenting editors. So they are both viable and time-tested. More importantly, it should be a lot easier to write a Clojure function to pretty-print a file than to write a Jedit plugin to auto-indent one,
Don't forget that what you're calling "pretty-printing" is not what
clojure.pprint is currently offering : clojure.pprint will remove your
comments, transform or remove from view your metadatas, ignore your
#_(...) code, etc.
Your discussion has been slowly getting me into the mindstate that
I'll add this missing "reindent whole file/current selection" feature
in CCW, AH !
>or at least find someone willing to do so assuming it doesn't already exist. While I'd prefer an in-editor solution, I don't think it's important enough to delay things even a few minutes. That, of course, is the real issue - how quickly can we put up an acceptable "single-download to clojure" distribution? Which is why all this is academic until someone who can update clojure.org to point to the download steps up and says "these are my requirements to do that."
> --
> Sent from my Android tablet with K-9 Mail. Please excuse my brevity.
>
Daniel Werner
> Your discussion has been slowly getting me into the mindstate that
> I'll add this missing "reindent whole file/current selection" feature
> in CCW, AH !
feature in Emacs, VimClojure etc. as well? :-)