--
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
--
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)
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.
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.
--
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.
--
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
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 :(
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... :)
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.
The problem is that the entire contents of the clojure.org site is
written by an expert, for experts.
EXAMPLE 2: Cryptic code
single-character variables
> 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/
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.
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....
If ALL you want is a SIMPLE repl you can just go to the tryclojure site. :)
If ALL you want is a SIMPLE repl you can just go to the tryclojure site. :)
--
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
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.
> 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. :)
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...:)
I take it you mean something distinct from pmap and preduce by
"parallel collections" here.
Do you mean the JRE? And if so: for development, rather than just deployment?
--
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
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.
Talk about a heavyweight, intimidating experience. :)
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.
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. :)
> 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
>
>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.
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
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.
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
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
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.)?
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
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>
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
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>
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>
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
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
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."
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
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.
>