Please stand firm against Steve Yegge's "yes language" push
James Keats
Hi all. I've been looking at Clojure for the past month, having had a
previous look at it a couple of years ago and then moved on to other
things only to return to it now.
Over the past decade I have looked at many languages and many ways of
doing things. People may say this language or that language is
"general purpose", but the fact remains that languages have their
niches in which they excel and beyond which it'd be foolish to
venture.
Clojure should not attempt be a "mass success" language or worry about
its Tiobe index ranking.
Clojure, the way I see it, is most suitable for the advanced
independent developer. It is a language in the image of its creator,
Rich Hickey. It's not a language for the factory hen. It won't become
the next Java. Java already fills that niche, and despite what some
may say, I don't see it going away anytime soon.
I don't feel Clojure needs to "grow" - in terms of size of language.
In fact it would worry me enormously if Clojure's path is to "grow" in
size. It is fundamentally unsuited for that. If anything I wish for it
to shrink even further and further.
A Rich Hickey's quote comes to mind:
• (paraphrased) "Most Clojure programmers go through an arc. First
they think “eww, Java” and try to hide all the Java. Then they think
“ooh, Java” and realize that Clojure is a powerful way to write Java
code"
and "As I've said in my talks, most Clojure users go from "eww, Java
libs" to "ooh, Java libs", leveraging the fact there there is already
a lib for almost anything they need to do. And using the lib is
completely transparent, idiomatic and wrapper free." - Google verbatim
for sources.
Whereas when Steve Yegge writes: "which means that everyone (including
me!) who is porting Java code to Clojure (which, by golly, is a good
way to get a lot of people using Clojure) is stuck having to rework
the code semantically rather than just doing the simplest possible
straight port. The more they have to do this, the more you're going
to shake users off the tree." all I could think on reading this is
"horror, horror, oh God, horror!!!; he really doesn't get it". First,
he shouldn't be porting Java code to clojure, Second, Clojure IS
fundamentally different from Java, and third, such said users who
don't want to touch Java should not touch Clojure.
Clojure shouldn't worry about growing; java already has innumerable
libs. Clojure, imho, should continue its - what I would dub -
"middleware begone!" path, in which it'd provide an end-to-end, down-
to-the-metal comprehensible system that an individual developer can
get his head round and know exactly what's happening with his code and
its environment here and everywhere.
I could write more, but I have to run. Regards.
J.
Gregg Reynolds
...
Whereas when Steve Yegge writes:
.Bill Smith
Whereas when Steve Yegge writes: "which means that everyone (including
me!) who is porting Java code to Clojure (which, by golly, is a good
way to get a lot of people using Clojure) is stuck having to rework
the code semantically rather than just doing the simplest possible
straight port. The more they have to do this, the more you're going
to shake users off the tree." all I could think on reading this is
"horror, horror, oh God, horror!!!; he really doesn't get it". First,
he shouldn't be porting Java code to clojure,
faenvie
a forseeable future.
IMO clojure is much more a Language for SystemProgrammers
(high demands, thinking in concurrency) than a Language for
ApplicationProgrammers (midsize demands, thinking singlethread)
it does not have to target general purpose use. But Very well could
clojure become a mainstream-language for SystemProgrammers.
other promising perspectives for clojure:
- as a base for true innovation (core.logic)
- for programming android (compile to dex)
László Török
If you care to code that way of course...
Las
--
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
--
James Keats
On Jul 2, 2:15 am, ".Bill Smith" <william.m.sm...@gmail.com> wrote:
> Whereas when Steve Yegge writes: "which means that everyone (including
>
> > me!) who is porting Java code to Clojure (which, by golly, is a good
> > way to get a lot of people using Clojure) is stuck having to rework
> > the code semantically rather than just doing the simplest possible
> > straight port. The more they have to do this, the more you're going
> > to shake users off the tree." all I could think on reading this is
> > "horror, horror, oh God, horror!!!; he really doesn't get it". First,
> > he shouldn't be porting Java code to clojure,
>
> Do you mean no one should port Java code to Clojure, or do you mean Steve
> Yegge in particular should not port Java code to Clojure? I can think of
> several good reasons why someone (including Steve Yegge) might choose to do
> that. Would you mind elaborating on that point?
appropriate use of clojure and its relationship to java.
I'll re-quote it: "• Most Clojure programmers go through an arc.
think “ooh, Java” and realize that Clojure is a powerful way to write
nothing but wrap a Java method. Calling the Java method directly is
faster and easier to look up in JavaDoc."
>
> Regardless, after reading all of Steve Yegge's comments in that thread, I do
> not get the impression he is asking for anyone to throw the kitchen sink
> into Clojure. Rather, he is asking for the Clojure community to be more
> receptive toward feedback and questions. Yes, he says, being more receptive
> may lead to additions to Clojure, but it may just as well lead to answering
> questions in a constructive way.
someone insisting that you modify a fork so he could use it to sip his
soup as "constructive" and yielding to such silliness as "receptive".
There are soup spoons for that purpose and other utensils for other
purposes.
I see this often and it irks me tremendously, it's in particular a
feature of so called "bloggers", in particular those who've had a
history of evangelizing ruby. They come to language communities on the
up like Erlang and Clojure and demand a bastardization of the original
purpose to suit their purposes, in this case it seems a validation of
Steve Yegge's concept of a "yes language". A what language?!?! Oh my
what a technical insight that is!
I am somewhat aghast that you say you read that original thread and,
apparently haven't found much to be horrified by in what he wrote; my
point is this:
People should spend an adequate amount of time actually understanding
what the original purpose of something is, how it came about, what
problem it addresses, what it's good at, and how it does things rather
than campaign outright and from the start to change it to be how
they're used to doing things or how they could make a name for
themselves for having "fixed" it.
For example, when Steve Yegge writes:
"The standard answer on the Clojure lists is (_______), to which the
standard newcomer will reply "how about go fuck yourselves; I'll use
another language."
My answer to such "newcomer" would be: "how about you fucking read a
book, or a dozen or two?!?! good riddance".
It irks me to no measure how people are eager to broadcast their
avowed ignorance throughout the so-called blogosphere. They want to
learn something in 10 minutes or so from a blog post here or there and
then start blogging about it already and submitting "patches" and
making a name for themselves (I'm not specifically referring to Steve
Yegge here, but to what he called a "standard newcomer").
What is actually there in his posts in that thread?! blatherings and
generalities about "community" and "attitude" and language "economics"
and "marketing" that any kid high on weed who'd read a post too many
on reddit's /r/programming could've wrote, and what little specific
technical detail shows a clear lack of knowledge about clojure and its
take on functional programming and java interop and unwillingness to
learn.
David Nolen
James Keats
On Jul 1, 10:50 pm, Gregg Reynolds <d...@mobileink.com> wrote:
>
> > ...
>
> > Whereas when Steve Yegge writes:
>
> Who?
but a fair and justified re-examination; if people are going to use
their heavyweight-sounding "name" to wield influence upon others, it's
fair and justified to ask what's behind that name.
I have been aware of Steve Yegge for many years; pseudo-literary and
pseudo-humorous "rants" that might be of interest to a programmer's
cabinet of curiosities, but that I've not had the luxury of time to
indulge in reading, preferring to devote mine to meatier topics.
I have not learned anything of note from Steve Yegge. His name seems
to be associated lately with Javascript, but whereas I've learnt a lot
from those folks, the likes of Stoyan Stefanov (perhaps my personal
favourite of those folks), Doug Crockford and John Resig, the one time
I felt compelled to read a Steve Yegge writing was when he was
referenced in the Joy of Clojure regarding his so-called "universal
design pattern". What a poorly written piece of crap that was, there
was nothing new in it (Javascript's literal syntax is well documented
in much better writings, and in Steve Yegge's article it was burried
in a bunch of mind-numbing nonsense). I believe it'd be better for the
Clojure core notables, whom I have a deep respect for, to suggest
Haskell and RDF/OWL as better resources for understanding Clojures
types/protocols.
Luc Prefontaine
I would add that having to rework the code semantically in a Java to Clojure port is normal.
Clojure offers new possibilites that Java will probably never integrate or it will take so long
that Clojure will have moved to version 4.
If you port from Java to Clojure keeping the same code structure/approach then why do it ?
What do you gain ? Except new bugs ? If there is no gain, leave it in Java and use it from Clojure.
I would even reuse old business logic blocks like this especially if there's no documentation about them.
You can still choose later what you would like to switch to Clojure over time if there's an
incentive to do so.
Redoing stuff that existed in Java for a decade in Clojure is a waste of time
and energy. Reuse the building blocks, don't rewrite them.
It would be a set back if each new generation had to reinvent fire.
Octopuses are not at the top of the food chain because each generation has to rediscover/reinvent
things. There is no knowledge transmission from older generations, parents die before their eggs hatch.
We, in the computer business, have been doing this for decades. Maybe it's time we stop this.
People have this obstinate mind about using a single tool for all purposes...
Luc
--
Luc P.
================
The rabid Muppet
Aaron Bedra
Rich, I am concerned about this message. There is no reason to stand
against somebody. Steve is welcome to his own opinions and is an
incredibly smart guy. He should be respected as a peer. His opinions
happen to be different from Clojure's core values, and that is ok.
Steve will either choose to use Clojure or go another path, and that is
alright.
The way for Clojure to grow is by embracing it's core values and showing
the world that careful choices do lead to the right outcome. Let's not
turn this into us against Steve. There's nothing productive there.
Focus your energy instead on writing great Clojure code and sharing it
with everyone else. Get people excited about Clojure who want something
more powerful, and show them what is truly possible.
Cheers,
Aaron Bedra
--
Clojure/core
http://clojure.com
On 07/01/2011 03:59 PM, James Keats wrote:
> Hi all. I've been looking at Clojure for the past month, having had a
> previous look at it a couple of years ago and then moved on to other
> things only to return to it now.
>
> Over the past decade I have looked at many languages and many ways of
> doing things. People may say this language or that language is
> "general purpose", but the fact remains that languages have their
> niches in which they excel and beyond which it'd be foolish to
> venture.
>
> Clojure should not attempt be a "mass success" language or worry about
> its Tiobe index ranking.
>
> Clojure, the way I see it, is most suitable for the advanced
> independent developer. It is a language in the image of its creator,
> Rich Hickey. It's not a language for the factory hen. It won't become
> the next Java. Java already fills that niche, and despite what some
> may say, I don't see it going away anytime soon.
>
> I don't feel Clojure needs to "grow" - in terms of size of language.
> In fact it would worry me enormously if Clojure's path is to "grow" in
> size. It is fundamentally unsuited for that. If anything I wish for it
> to shrink even further and further.
>
> A Rich Hickey's quote comes to mind:
> � (paraphrased) "Most Clojure programmers go through an arc. First
> they think �eww, Java� and try to hide all the Java. Then they think
> �ooh, Java� and realize that Clojure is a powerful way to write Java
László Török
Although I agree with the ideas here that have already been stated by Rich, I am concerned about this message. There is no reason to stand against somebody. Steve is welcome to his own opinions and is an incredibly smart guy. He should be respected as a peer. His opinions happen to be different from Clojure's core values, and that is ok. Steve will either choose to use Clojure or go another path, and that is alright.
The way for Clojure to grow is by embracing it's core values and showing the world that careful choices do lead to the right outcome. Let's not turn this into us against Steve. There's nothing productive there. Focus your energy instead on writing great Clojure code and sharing it with everyone else. Get people excited about Clojure who want something more powerful, and show them what is truly possible.
huge +1000
• (paraphrased) "Most Clojure programmers go through an arc. First
they think “eww, Java” and try to hide all the Java. Then they think
“ooh, Java” and realize that Clojure is a powerful way to write Java
code"
and "As I've said in my talks, most Clojure users go from "eww, Java
libs" to "ooh, Java libs", leveraging the fact there there is already
a lib for almost anything they need to do. And using the lib is
completely transparent, idiomatic and wrapper free." - Google verbatim
for sources.he shouldn't be porting Java code to clojure, Second, Clojure IS
Whereas when Steve Yegge writes: "which means that everyone (including
me!) who is porting Java code to Clojure (which, by golly, is a good
way to get a lot of people using Clojure) is stuck having to rework
the code semantically rather than just doing the simplest possible
straight port. The more they have to do this, the more you're going
to shake users off the tree." all I could think on reading this is
"horror, horror, oh God, horror!!!; he really doesn't get it". First,
fundamentally different from Java, and third, such said users who
don't want to touch Java should not touch Clojure.
Clojure shouldn't worry about growing; java already has innumerable
libs. Clojure, imho, should continue its - what I would dub -
"middleware begone!" path, in which it'd provide an end-to-end, down-
to-the-metal comprehensible system that an individual developer can
get his head round and know exactly what's happening with his code and
its environment here and everywhere.
I could write more, but I have to run. Regards.
J.
--
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
James Keats
On Jul 2, 4:16 pm, Aaron Bedra <aaron.be...@gmail.com> wrote:
> Although I agree with the ideas here that have already been stated by
> Rich, I am concerned about this message. There is no reason to stand
> against somebody. Steve is welcome to his own opinions and is an
> incredibly smart guy. He should be respected as a peer. His opinions
> happen to be different from Clojure's core values, and that is ok.
> Steve will either choose to use Clojure or go another path, and that is
> alright.
>
> The way for Clojure to grow is by embracing it's core values and showing
> the world that careful choices do lead to the right outcome. Let's not
> turn this into us against Steve. There's nothing productive there.
> Focus your energy instead on writing great Clojure code and sharing it
> with everyone else. Get people excited about Clojure who want something
> more powerful, and show them what is truly possible.
>
> Cheers,
>
> Aaron Bedra
> --
> On 07/01/2011 03:59 PM, James Keats wrote:
>
title of my post was "Please stand firm against Steve Yegge's "yes
language" push". I implore you as clojure core and clojure community
to stand firm against his "yes language" push. I did not intend the
message of my post to be personal/social issues, despite the
unfortunate fact that the thrust of his posts in that thread revolved
around his concept of social "attitude" of a language creator and
community and the evident implication that such social considerations
should take primacy over technical merits.
James Keats
On Jul 2, 3:54 pm, David Nolen <dnolen.li...@gmail.com> wrote:
systems programming is of the C variety; in fact even Java wouldn't be
suitable there. Actually I do believe Clojure to be an applications
language, and I would not constrain it to any one application area, I
believe it to be widely applicable.
Where I would advocate caution that'd restrict its use though, it
would not relate to the programming language itself, but to the
programmer. Twofold: 1) Clojure requires an advanced programmer;
there's no escaping that. Said programmer needs to know Java well, and
also functional programming of the haskell/ml sort, as well as lisp 2)
Clojure requires discipline and wisdom; those do not come about
easily, they require wide and long experience. It allows the
programmer much, not too much for the widely-read experienced
programmer, but perhaps too much for a large team constituted of
programmers of varied abilities.
I therefore see it most suited, as I said, for the advanced
independent programmer, or at most a small team of advanced enough
programmers.
David Nolen
I therefore see it most suited, as I said, for the advanced
independent programmer, or at most a small team of advanced enough
programmers.
Stefan Kamphausen
I've been enjoying the Yegge posts for years. I definitely like his kind of humor and there are posts which made me laughing til the tears were running (Settling the OS X focus-follows-mouse debate comes to mind). Some posts deliver some insight, which at times may be well hidden.
However, as Aaron pointed out, I'd rather a more tolerant, pleasant community.
Kind regards,
Stefan
PS: And I don't think Steve Yegge would be porting Java code to Clojure without good reason and benefit.
PPS: Regarding "thin" wrappers: take a look at the source code of e.g. dosync/sync, hash-map, to-array, find, keys ... There are situations where you just want to have a little less noise.
James Keats
On Jul 2, 6:39 pm, David Nolen <dnolen.li...@gmail.com> wrote:
>
> > I therefore see it most suited, as I said, for the advanced
> > independent programmer, or at most a small team of advanced enough
> > programmers.
>
> I think Clojure is great for programmers with all kinds of experience - from
> beginner to advanced. In fact I think people haven't been brain washed by
> too much experience in object oriented and imperative languages will have a
> much easier time picking it up.
>
> David
teaching lisp and functional programming as early as possible. I have
nothing against it whatsoever other than to note that it is an
educational argument, not an industrial one.
In fact, it is exactly how I came to programming; lisp through the
writings of those folks was my introduction to programming many years
ago. Had it not been for their inspiration I wouldn't have bothered.
However, once you're past the CS education stage then industrial
concerns are an inescapable reality. And once you encounter the
reality and frustration infamously characterized by likening the
managing of lispers to the herding of cats then you begin to admire
languages like python and java and see what they got right in imposing
restrictions.
A very recent quote by Abelson is relevant:
"One of the things I’m learning here (Google) is the experience of
working on these enormous programs. I just never experienced that
before. Previously a large program to me was a hundred pages or
something. Now that’s a tiny, little thing."
Kind regards,
J
David Nolen
And once you encounter the
reality and frustration infamously characterized by likening the
managing of lispers to the herding of cats then you begin to admire
languages like python and java and see what they got right in imposing
restrictions.
A very recent quote by Abelson is relevant:
"One of the things I’m learning here (Google) is the experience of
working on these enormous programs. I just never experienced that
before. Previously a large program to me was a hundred pages or
something. Now that’s a tiny, little thing."
James Keats
On Jul 2, 6:41 pm, Stefan Kamphausen <ska2...@googlemail.com> wrote:
> FWIW,
> However, as Aaron pointed out, I'd rather a more tolerant, pleasant
> community.
>
> Kind regards,
clicking "send" realized was utterly dumb. It reminds of an anecdote
about an (MIT?) professor who'd insist on whomever asks him a question
to explain in some detail what they understand and what they don't
understand, and oftentimes when people do so come to an "Oh!" moment
of sudden understanding before he'd even answered just out of
formulating the problem.
That utterly dumb question got many "tolerant, pleasant" answers. :-)
I would draw a thick line between the community's response to someone
who'd ask an utterly dumb question - I don't me specifically, but any
newcomer - and someone who'd insist upon the creator of a carefully
considered and crafted solution and its community to change their
"culture" outright. If I, and people like me who are willing to put
their nose to the grindstone, read the books and watch the videos
umpteen times over till they get it through and through, to become
invested in clojure and its future, then we need a firm reassurance
that ludicrous demands like those are firmly resisted, and believe
it's imperative to implore clojure core to do so.
Kind regards, :-)
J
octopusgrabbus
instances using 3rd party Windows based address verification
(SmartSoft USA's Accumail) while bills are being loaded (before
generating the print files) where a good multi-threaded language would
help. Python does well as single thread and is a great go-to language.
James Keats
On Jul 2, 8:33 pm, David Nolen <dnolen.li...@gmail.com> wrote:
> > And once you encounter the
> > reality and frustration infamously characterized by likening the
> > managing of lispers to the herding of cats then you begin to admire
> > languages like python and java and see what they got right in imposing
> > restrictions.
>
> I've yet to see any evidence anecdotal or otherwise that managing a team of
> good Lisp programmers is any more difficult than managing good programmers
> in any other language. Links?
>
key operative word here being *good*; where do you find those in large
enough numbers to fill industry positions? I would also like to be
specific about what "good" would entail: it has to entail some
knowledge of what would actually work in the large and be
maintainable, and a personal maturity that would prevent them from
becoming too excited and overly adventurous. Unfortunately the
industry is not made of "good lisp programmers".
> > A very recent quote by Abelson is relevant:
> > "One of the things I’m learning here (Google) is the experience of
> > working on these enormous programs. I just never experienced that
> > before. Previously a large program to me was a hundred pages or
> > something. Now that’s a tiny, little thing."
>
> One of the most popular text editors to this day is Emacs. It's near 3
> million lines of Lisp.
>
> David
David Nolen
Sure, "good lisp programmers", I have no argument against that, the
key operative word here being *good*; where do you find those in large
enough numbers to fill industry positions? I would also like to be
specific about what "good" would entail: it has to entail some
knowledge of what would actually work in the large and be
maintainable, and a personal maturity that would prevent them from
becoming too excited and overly adventurous. Unfortunately the
industry is not made of "good lisp programmers".
Versus the countless libraries and apps of Java and python?
Aaron Bedra
do so with actions. My point is simply that I would rather not spend
energy even talking about this, but rather demonstrating that we stand
by our decisions by continuing on in the fashion Rich started, and many
after have followed. I don't see how arguing about the merits of one
person or another helps in any situation, or their technical influence
or credibility. I would rather just put all that behind us.
As you asked, Clojure/core will continue in the fashion that it always
has. We welcome all ideas and opinions, though we will always think
carefully about which ones are accepted into the Clojure language. You
can rest easy knowing that the effort you put into building up your
Clojure knowledge will not go to waste :)
Cheers,
Aaron Bedra
--
Clojure/core
http://clojure.com
Stefan Kamphausen
On Saturday, July 2, 2011 9:59:12 PM UTC+2, James Keats wrote:
On Jul 2, 6:41 pm, Stefan Kamphausen <ska...@googlemail.com> wrote:
I would draw a thick line between the community's response to someone
who'd ask an utterly dumb question - I don't me specifically, but any
newcomer - and someone who'd insist upon the creator of a carefully
considered and crafted solution and its community to change their
"culture" outright.
obviously I don't live inside the head of Steve Yegge. However, I get the feeling, the fact that we are discussing things like we do on this thread may one of the things he tries to achieve. Yes, he seems to have a tendency to exaggeration. You probably have to exaggerate sometimes to drive a minor point home.
If I, and people like me who are willing to put
their nose to the grindstone, read the books
Ah books. That's good. ;-)
Cheers,
Stefan
Sean Corfield
> I find clojure suitable to pretty much every problem I've come across so
> far, since it allows me to write concise, low-ceremony code. The bottom-up
> approach helps raising the abstraction level, and soon the concepts of your
> domain will surface, so that the code starts reflecting the language you use
> in your problem domain.
I agree. I'm finding Clojure to be a very productive, concise way to
solve problems in the Model of a large MVC web application originally
built with other JVM-based technologies. We're finding a massive
compression of code by switching core processing to Clojure - and as a
nice side effect, we're taking the lessons of Clojure back to our
other language(s) and finding massive simplifications there which were
not obvious before.
Just today we started on the process of analyzing Power MTA log files
to deal with email bounces - an almost trivial process in Clojure,
compared to other languages, with HOF and lazy sequences available to
us.
To me, Clojure is a very general purpose language.
That said, I don't expect it to gain mainstream traction like Java
(and I think that would be a bit of a disaster, to be honest) but I
think it will gain a strong, productive community that will be large
enough to be healthy and self-sufficient, and will compare favorably
with other "popular" non-Java languages on the JVM.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
Sean Corfield
> I think Clojure is great for programmers with all kinds of experience - from
> beginner to advanced. In fact I think people haven't been brain washed by
> too much experience in object oriented and imperative languages will have a
> much easier time picking it up.
+1. I started out doing FP in the early/mid-80's and moved to OO in
the 90's. Coming back to FP I've had to unlearn some bad habits and
dust off some old habits that had laid dormant during my OO years. Of
the people I've tried to expose to Clojure over the last six months,
I've definitely found that those with less OO experience tend to pick
it up much quicker.
Stuart Sierra
Ken Wesson
> I'll re-quote it: "• Most Clojure programmers go through an arc.
> First they think “eww, Java” and try to hide all the Java. Then they
> think “ooh, Java” and realize that Clojure is a powerful way to write
> Java code. Rich frowns upon “wrapper” functions in Clojure that do
> nothing but wrap a Java method. Calling the Java method directly is
> faster and easier to look up in JavaDoc."
There's one obvious use case for such a wrapper function, though: if
you'll want to pass the Java method to HOFs from time to time. You
can't directly pass a Java method to a HOF, but you can pass such a
wrapper function.
--
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.
James Keats
On Jul 2, 9:31 pm, David Nolen <dnolen.li...@gmail.com> wrote:
> I was only talking about the scalability of Lisp with respect to code base
> size.
>
> David
simply do not have much trust in the average joe developer. The
average joe developer is a hack-billy of an instant-gratification
junkie who doesn't like to read books, and has a disparaging attitude
towards managerial/architectural concerns.
I'm not very familiar with the internals of emacs; this is a very
deliberate position; over the years I have restrained myself from
knowing too much about it. I always advocate that people adopt a
managerial/business-case approach. Say I had 50 developers, would I
pay for them to learn emacs? I probably wouldn't; the returns of emacs
for a large code base are not evident to me. In fact, I may even
disallow it. I can clearly see a point of diminishing returns and an
opportunity cost with emacs, and I would worry about my developers
getting sucked into that pit of endless tinkering. I also would not
want them to believe that an editor nirvana grants them a license to
ignore good code organization basics. (would I pay for them to learn a
java IDE? of course, I'd demand it, with the caveat though that I
would insist upon them to able at all times to build (test etc) their
probject without it, not in case the IDE goes bonkers on them, but so
they fully understand what's happening and be in line with continuous
integration/delivery practices, which I'm convinved are sensible)
That said, I know this much: the spat between jamie zawinsky and
richard stallman comes to mind. Richard Stallman was the maintainer of
emacs, a man whose discipline has been likened to an old testament
prophet, and jamie "just fucking ship it" zawinsky was i'd say what
Steve Yegge termed "the standard newcomer". It's interesting and
enlightening to read about it in Peter Siebel's Coders at Work book,
in which he interviewed jami zawinsky, and he gets an opportunity to
tell it from his side of the story, yet it hasn't changed my view -
only reaffirmed it - that I wouldn't want a "standard newcomer" let
loose on a large code base I'm invested in. I would note that the
average joe developer admires zawinski, and generally regards stallman
as crazy.
If I recall correctly, that spat concerned C code, and my point isn't
about who was right and who was wrong in that specific instance; my
point in citing it is that it demonstrated a general state of affairs
at the time: emacs had a disciplined founder and maintainer.
Again, to be absolutely clear, I do believe it's easily possible to
muck up a java or python code base, but I regard the foundational
design and community cultures of those languages to be conducive to
large, long-term software and healthy ecosystems, java even more so
than python. Perhaps they simply represent a litmus test for who get
attraced to them. Those languages are shaping well for the future
(multicore concerns aside); Paul Graham may have suggested that lisp
would be the 100 years language, and several years ago there was that
book, Beyond Java, that was, more or less, predicting the demise of
java and was unimpressed by python, whilst favouring ruby, yet since,
over those past years, they've only - java and python - gone from
strength to strength and remain on the ascendency whilst the ruby hype
machine has imploded and the feasibility of ruby has come apart at the
seams thanks to an ill-disciplined community culture.
Ironically for Steve Yegge, it is the "no Languages" that are proving
themselves increasingly popular thanks to a conservative enough
leadership that assures their being a reliable platform conducive to
code sharing and large scale, long term projects. Clojure has an
impressively sensible foundational vision, and I implore Rich Hickey
and clojure core to make it a "no language" if need be to maintain
that fidelity; given that assurance, I'm generally optimistic about
its future and intend to invest heavily in it.
Phil Hagelberg
In addition, completion on vars is usually much better than on methods. Plus using javadoc when you're used to docstrings feels a bit like using a card catalog when you're used to having Wikipedia in your pocket.
-Phil
Sean Corfield
> Again, to be absolutely clear, I do believe it's easily possible to
> muck up a java or python code base, but I regard the foundational
> design and community cultures of those languages to be conducive to
> large, long-term software and healthy ecosystems, java even more so
> than python.
Perhaps we move in different circles but I've seen as much "bad Java"
in the large as I ever used to see "bad FORTRAN" and "bad C / C++"
code over the years. I think large "enterprise" Java projects have
just as many "below average" developers working on them as any other
popular language projects. And by definition, half of all developers
are "below average" and the more popular a language is, the broader
that spread is likely to be.
I think the only way you can avoid the "joe developer" that you fear
is to have a language which requires a very high barrier to entry so
only "good" developers can even write "Hello World!" in it. I don't
think that actually benefits anyone (since such languages don't get
sufficient critical mass that people ever get the chance to use them
"at work" to solve "real problems").
> Beyond Java, that was, more or less, predicting the demise of
> java and was unimpressed by python, whilst favouring ruby, yet since,
> over those past years, they've only - java and python - gone from
> strength to strength and remain on the ascendency whilst the ruby hype
> machine has imploded and the feasibility of ruby has come apart at the
> seams thanks to an ill-disciplined community culture.
I find it interesting that you offer up a perceived demise of Ruby
when all I see is continued adoption of Ruby/Rails, far and away ahead
of Python. Again, possibly we move in different circles. On Java, I
was just at JAXconf where the overall theme was "Don't worry, Java's
not really dead!" - it was an almost desperate sense of trying to
rally the (enterprise) Java troops and head off the defections to
other languages, whilst all the time praising how much innovation was
occurring on the (JVM) platform, i.e., in those other languages.
Oracle talked about the big focus for Java EE 6 / 7 / 8 being
simplification - making Java easier to use and removing a lot of the
complexity and configuration that has grown up in that world (exactly
the problems that are causing Java developers to move to more
expressive languages and to adopt convention-based frameworks). The
big inspiration being held up to everyone at the conference was
Ruby/JRuby and the convention-based approach of Rails. I came away
with the sense that even its most stalwart supporters think Java is
very, very sick and needs to clean its act up if it is to avoid
becoming irrelevant as a language. The audience were told that Java
developers need to get used to the idea of learning new languages
frequently. I bumped into a handful of people there using Groovy and
one or two using Scala. I ran into a lot of people who really had no
idea what was going on in the world outside of Java and they seemed
very focused on data-centric "enterprise" business applications that
really didn't do anything particular complex but yet had grown into
gigantic codebases with a huge amount of complicated infrastructure...
So, overall, I don't share your belief that Java has a "foundational
design and community cultures [that is] conducive to large, long-term
software and healthy ecosystems".
James Keats
On Jul 3, 9:02 pm, Sean Corfield <seancorfi...@gmail.com> wrote:
>
> Perhaps we move in different circles but I've seen as much "bad Java"
> in the large as I ever used to see "bad FORTRAN" and "bad C / C++"
> code over the years. I think large "enterprise" Java projects have
> just as many "below average" developers working on them as any other
> popular language projects. And by definition, half of all developers
> are "below average" and the more popular a language is, the broader
> that spread is likely to be.
>
> I think the only way you can avoid the "joe developer" that you fear
> is to have a language which requires a very high barrier to entry so
> only "good" developers can even write "Hello World!" in it. I don't
> think that actually benefits anyone (since such languages don't get
> sufficient critical mass that people ever get the chance to use them
> "at work" to solve "real problems").
>
"Hello World!" taking too long, this is a business case analysis (if
you can't afford to do something right, should you be doing it at
all?!), though I do acknowledge that unfortunately "Hello World!" is
the measure many developers use to judge things. I do not worry about
that, what I worry about is what happens months or even years down the
line, after much had been invested. Business is business; unless your
motive is simply to scam someone else by passing it on (much of what
startups and VCs nowadays are about - a ponzi scheme of sorts), you do
not want to build on shaky foundations.
There is much "bad Java", no doubt, but no one if forcing you to fall
prey to that.
doing things I would not adopt or endorse. After all, there is a
reason why I'm here at clojure.
We need to differentiate between things; how you build your software
is up to you, but it is indisputable that Java has a lot of libraries,
some may be bad, but others are outstanding, and no one is forcing you
to choose the bad ones. I am a big believer that if there's a library
that already does what you do, made by experts and vetted by the
world, then you shouldn't do it yourself. I also believe that Java's
"thou shall not do this!" and Python's "though shall not do this,
unless you have to" go towards explaining that. Ruby may have a
tempting "Hello World!" proposition that makes it appeal to startup
developers, but sooner or later down the road you'll run into this
widely-documented problem http://www.benjamincoe.com/post/6234388028/why-i-hate-ruby
It remains to be seen how clojure will deal with this. I believe the
foundation set by Rich Hickey is sound. It's an interesting area, and
an area of debate nonetheless; how do you organize code, and how does
functional programming relate to OO (again, let's differentiate here
between building apps out of libraries, and the libraries themselves)?
For example I suggest you look at this video/transcript and pay
attention in particular to the point of debate between Joe Armstrong
of Erlang and Martin Odersky of Scala http://www.infoq.com/interviews/functional-langs
, in particular around the point where Odersky says "I’m not quite
sure I buy that...". (also of additional relevance to those two points
are http://erlang.org/pipermail/erlang-questions/2011-May/058769.html
and also http://www.scala-lang.org/node/1637), and if you're further
interested you may wish to read Eric Meyer's essay in the book
Beautiful Architecture regarding a previous Simon Peter Jones Haskell-
related publication, titled "Software Architecture: Object-Oriented
Versus Functional".
Regards.
Sean Corfield
> For example I suggest you look at this video/transcript and pay
> attention in particular to the point of debate between Joe Armstrong
> of Erlang and Martin Odersky of Scala http://www.infoq.com/interviews/functional-langs
> , in particular around the point where Odersky says "I’m not quite
> sure I buy that...". (also of additional relevance to those two points
> are http://erlang.org/pipermail/erlang-questions/2011-May/058769.html
> and also http://www.scala-lang.org/node/1637), and if you're further
> interested you may wish to read Eric Meyer's essay in the book
> Beautiful Architecture regarding a previous Simon Peter Jones Haskell-
> related publication, titled "Software Architecture: Object-Oriented
> Versus Functional".
I've read that book (a month or two ago) but I'll go back and re-read
that essay in light of this thread. I've marked those four links for
"View Later" (I love RockMelt!). I may come back to this topic after
I've consumed all that information...
James Keats
On Jul 3, 6:15 am, Ken Wesson <kwess...@gmail.com> wrote:
>
> There's one obvious use case for such a wrapper function, though: if
> you'll want to pass the Java method to HOFs from time to time. You
> can't directly pass a Java method to a HOF, but you can pass such a
> wrapper function.
>
those places where you'd need to pass it to a HOF and continue to use
it directly elsewhere? That would probably be how I'd prefer it, as
it'd mean less functions to keep track of, and less indirection
(decoupling api concerns aside).
Mark Rathwell
--
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
Ken Wesson
>
> A function is a function, whether it is bound to a Var or not. I think that
> was Ken's point, that you need to wrap a Java method in a function
> (anonymous or named) in order to pass to an HOF, as Java methods are not
> first class. So, that is one instance where a function whose sole purpose
> is to wrap a Java method may make sense.
Exactly.
A related case may be when you're not making just a straight wrapper,
but adding something -- your own pre/post checks, or argument
transformations, or etc.
As for binding to a Var, that makes sense if the result is not as
trivial as #(.meth %) and is going to be used many times. Otherwise
#(.meth %) is not much longer than a reasonably clear Var name for it
and is crystal clear as to what it does, so I'd just use that.
Tassilo Horn
Hi Ken,
> A related case may be when you're not making just a straight wrapper,
> but adding something -- your own pre/post checks, or argument
> transformations, or etc.
>
> As for binding to a Var, that makes sense if the result is not as
> trivial as #(.meth %) and is going to be used many times. Otherwise
> #(.meth %) is not much longer than a reasonably clear Var name for it
> and is crystal clear as to what it does, so I'd just use that.
Another consideration I take into account is if a functionality is
exposed to users.
For example, I have a clojure graph querying and transformation library
that is built upon our java graph library. The functionality is
hopefully implemented in idiomatic clojure, like iterating nodes and
edges using lazy seqs. However, there are two or three functions that
basically wrap only java methods. I decided to put them in although
it's idiomatic clojure to call java, because then the user gets a
complete, consistent clojure API and doesn't have to know anything about
the java side.
For example, you can write
--8<---------------cut here---------------start------------->8---
(reduce + (map #(value %1 :inhabitants)
(vseq (rg) 'localities.Locality)))
--8<---------------cut here---------------end--------------->8---
instead of the slightly alien
--8<---------------cut here---------------start------------->8---
(reduce + (map #(.getAttribute %1 "inhabitants")
(vseq (rg) 'localities.Locality)))
--8<---------------cut here---------------end--------------->8---
That's a bit shorter (and allows for giving the attribute name as
keyword, symbol, or string), and most importantly it is documented. If
that wrapper wasn't there, users that just want to use the clojure
library have to study the javadocs, too.
Bye,
Tassilo
Ken Wesson
layer boundary and the Java method is two (or more) layers lower than
the caller, basically.
This suggests a generalization as well: that there's a form of "Law of
Demeter" applied to layers (and libraries) where one should tend to
talk directly to the levels adjacent but not to a level two steps
down, for instance. The layer two steps down is an implementation
detail of the layer one step down and therefore shouldn't be exposed
to that layer's clients, including your current layer. This would be
more broadly applicable than just when the layer boundary is a
client/library boundary -- then again, maybe in a sense it's the
reverse, and all layer boundaries can be thought of as client/library
boundaries, i.e. every layer of an application but the top should
basically be a library (or set of libraries) that is (or are) used to
implement the next layer up.
faenvie
>>I've definitely found that those with less OO experience tend to pick
>>it up much quicker.
since 1995.
it takes me one year now to reach a highlevel quality in programming
clojure. i maybe
near but still have the feeling that i am not there ...
the IMO main-reasons for this are:
- i am so deeply entrenched in OO-thinking
- no chance to apply clojure in the job so it's kind of a hobby
- 40+ years -> brain is full of stuff -> more difficult to learn
IMO one thing that could help OO-people a lot would be a
detailed guide for implementing classical design-patterns using
clojure (see: head first desing patterns which is a fantastic book) .
'the joy of clojure' touches this subject but not in detail.
Btw. it's not true IMO, that clojure eleminates the benefit of
thinking in design-patterns.
and finally to correct myself: clojure IS a general purpose language.
no doubt about it. -> high-level skills in clojure enable programmers
to
do both: system-programming and application-programming.
Sean Corfield
> that's exactly true for me: 40+ years old and OO-centric-Programmer
> since 1995.
> it takes me one year now to reach a highlevel quality in programming
> clojure.
I sympathize! I turn 49 this week (Thursday) and have been doing OO
since '92. Fortunately I did quite a bit of FP before that so I think
I can still be "saved" :)
> IMO one thing that could help OO-people a lot would be a
> detailed guide for implementing classical design-patterns using
> clojure (see: head first desing patterns which is a fantastic book) .
That's an interesting point. Since the Gang of Four book is subtitled
"Elements of Reusabled _Object-Oriented_ Software", I wonder whether
it's really the right starting point tho'? Several of those patterns
exist to address problems people run into with OO, much like the Core
J2EE Patterns book contains patterns that exist solely to workaround
problems / deficiencies with J2EE constructs (such as EJBs).
It might be an interesting community exercise to examine the 23 GoF
patterns and discuss whether they are applicable in an FP world and,
if a pattern _is_ still applicable, what it would look like?
For example, Command would probably just be a function or closure, as
would Strategy I suspect? Template Method might be a multi-method or
protocol / extend-type combo, as might Decorator? Facade would be a
new API implemented in a namespace that uses / requires the various
namespaces to which it is a facade? Proxy is relatively
straightforward in the absence of a static type system. Flyweight is
probably not applicable. Singleton could be delay / deref? Iterator is
not needed in Clojure due to the seq abstraction. Just throwing some
ideas out there - I haven't given any of that much thought...
Sean Corfield
> On Sun, Jul 3, 2011 at 3:34 PM, James Keats <james....@gmail.com> wrote:
>> For example I suggest you look at this video/transcript and pay
>> attention in particular to the point of debate between Joe Armstrong
>> of Erlang and Martin Odersky of Scala http://www.infoq.com/interviews/functional-langs
>> , in particular around the point where Odersky says "I’m not quite
>> sure I buy that...". (also of additional relevance to those two points
>> are http://erlang.org/pipermail/erlang-questions/2011-May/058769.html
>> and also http://www.scala-lang.org/node/1637), and if you're further
>> interested you may wish to read Eric Meyer's essay in the book
>> Beautiful Architecture regarding a previous Simon Peter Jones Haskell-
>> related publication, titled "Software Architecture: Object-Oriented
>> Versus Functional".
>
> I've read that book (a month or two ago) but I'll go back and re-read
> that essay in light of this thread.
I think you mean Bertrand Meyer's piece, extolling the virtues of OO
in general (and Eiffel in particular)? I thought it was a terribly
self-serving piece. Meyer has a strong bias and quite a bit of disdain
for anything that isn't Eiffel - which shines right thru that essay to
the point of making it fairly worthless, IMO. It has no objectivity :)
I read the interview transcript for Syme, Armstrong and Odersky and I
have to be honest that I found Armstrong almost incoherent and half
the time couldn't figure out what he was trying to argue at all - so
I'm not sure what point you're trying to make by referring to that
interview, sorry. Similarly Armstrong's musings on the Erlang list
about the entire world being a single flat "namespace" full of
functions that are globally unique seems rather incoherent too. He
talks about the problems with using modules to organize functions
(and, yes, modularity can be hard) but then proposes something that
would be no different (functions made unique by either having nearly
random names or a structured set of metadata that would really be
indistinguishable from modules in the first place - see
http://erlang.org/pipermail/erlang-questions/2011-May/058773.html).
The Scala forum discussion is more useful and relevant: TL;DR -
objects are occasionally the most natural model for solving a problem.
And in Clojure, mutable (shared) state is "occasionally" the most
natural model for solving a problem. That doesn't seem newsworthy to
me, just that a pure functional approach might not always lead to the
cleanest solution. That's kind of a "duh!" because otherwise why would
we need STM...
And then there's the Ruby rant. Yeah, I'd be pretty ticked off that I
got shot in the foot by combining two or three libraries that
otherwise ought to behave reasonably together. Global method injection
is pretty nasty. When I first read about multi-methods and protocols
in Clojure I was a bit worried that library code might cause a similar
problem by redefining functions out from under me, by virtue of more
specific "overloading" but it hasn't been a problem yet and when I
look at how those features are used in various libraries, I'm no
longer so worried.
I have other reasons for not liking Ruby so it's ability to shoot you
in the foot like that doesn't change my opinion of the language (nor
does it change its widespread popularity for a certain class of
programmers / companies).
Overall then, modularity is hard and sometimes a shared / mutable
state solution is cleaner... And I agree with both points. Am I
missing something in your concerns?
faenvie
> First, he shouldn't be porting Java code to clojure, Second, Clojure IS
> fundamentally different from Java, and third, such said users who
> don't want to touch Java should not touch Clojure.
to port java-code to clojure-code is certainly not the
right thing to do in most cases ... but
the fact that clojure is not determined to use the jvm as its
hosting-language could certainly be a driver for the reimplementation
of popular components.
even memory-management (gc), io-functions and process-management
may be candidates for a (re)implementation in clojure some day.
B Smith-Mannschott
It is?
Looks like about 1.4M lines of Lisp and less than 0.4 M lines of C.
[bsmith@pepper:~/w/emacs]
$ for x in h c el ; do printf ".%-2s: %7d lines in %5d files\n" $x
$(find * -name "*.$x" | xargs cat | wc -l) $(find * -name "*.$x" | wc
-l) ; done
.h : 37093 lines in 165 files
.c : 337489 lines in 199 files
.el: 1412477 lines in 1551 files
Not that 1.4M isn't large, but it's not 3M.
// Ben
James Keats
Fogus: Different target hosts would naturally support different
subsets of Clojure’s functionality. How do you plan to unify the
ports?
Hickey: I don’t. It has not been, and will not be, the objective of
Clojure to allow porting of large programs from one host to another.
That is simply a waste of time, and needed by almost no one.
Currently, you often have to change languages when you change hosts—
from Java to C# or Javascript. This is better than that, while short
of some full portability layer. The idea is to be able to take one’s
knowledge of Clojure and its core libraries, and of the host du jour,
and get something done. Certainly, non-IO libraries, like Clojure’s
core, can move between hosts. The JVM and CLR have rough capability
parity. We’ll have to see how restrictive a Javascript host might be.
octopusgrabbus
people use it -- it seems to me this community has been helpful,
respectful, and tolerant towards questions. At least I feel encouraged
to learn and explore the language, and that is one of the major
success points for Python IMHO.
On Jul 2, 10:30 am, James Keats <james.w.ke...@gmail.com> wrote:
> On Jul 2, 2:15 am, ".Bill Smith" <william.m.sm...@gmail.com> wrote:
>
> > Whereas when Steve Yegge writes: "which means that everyone (including
>
> > > me!) who is porting Java code to Clojure (which, by golly, is a good
> > > way to get a lot of people using Clojure) is stuck having to rework
> > > the code semantically rather than just doing the simplest possible
> > > straight port. The more they have to do this, the more you're going
> > > to shake users off the tree." all I could think on reading this is
> > > "horror, horror, oh God, horror!!!; he really doesn't get it". First,
>
> > Yegge in particular should not port Java code to Clojure? I can think of
> > several good reasons why someone (including Steve Yegge) might choose to do
> > that. Would you mind elaborating on that point?
>
> The Rich Hickey quote sums up the point better than I could about the
> appropriate use of clojure and its relationship to java.
> I'll re-quote it: "• Most Clojure programmers go through an arc.
> First they think “eww, Java” and try to hide all the Java. Then they
> think “ooh, Java” and realize that Clojure is a powerful way to write
> Java code. Rich frowns upon “wrapper” functions in Clojure that do
> nothing but wrap a Java method. Calling the Java method directly is
> faster and easier to look up in JavaDoc."
>
>
>
> > not get the impression he is asking for anyone to throw the kitchen sink
> > into Clojure. Rather, he is asking for the Clojure community to be more
> > receptive toward feedback and questions. Yes, he says, being more receptive
> > may lead to additions to Clojure, but it may just as well lead to answering
> > questions in a constructive way.
>
> What is "receptive" and what is "constructive"? I do not regard
> someone insisting that you modify a fork so he could use it to sip his
> soup as "constructive" and yielding to such silliness as "receptive".
> There are soup spoons for that purpose and other utensils for other
> purposes.
>
> I see this often and it irks me tremendously, it's in particular a
> feature of so called "bloggers", in particular those who've had a
> history of evangelizing ruby. They come to language communities on the
> up like Erlang and Clojure and demand a bastardization of the original
> purpose to suit their purposes, in this case it seems a validation of
> Steve Yegge's concept of a "yes language". A what language?!?! Oh my
> what a technical insight that is!
>
> I am somewhat aghast that you say you read that original thread and,
> apparently haven't found much to be horrified by in what he wrote; my
> point is this:
>
> People should spend an adequate amount of time actually understanding
> what the original purpose of something is, how it came about, what
> problem it addresses, what it's good at, and how it does things rather
> than campaign outright and from the start to change it to be how
> they're used to doing things or how they could make a name for
> themselves for having "fixed" it.
>
> For example, when Steve Yegge writes:
>
> "The standard answer on the Clojure lists is (_______), to which the
> standard newcomer will reply "how about go fuck yourselves; I'll use
> another language."
>
> My answer to such "newcomer" would be: "how about you fucking read a
> book, or a dozen or two?!?! good riddance".
>
> It irks me to no measure how people are eager to broadcast their
> avowed ignorance throughout the so-called blogosphere. They want to
> learn something in 10 minutes or so from a blog post here or there and
> then start blogging about it already and submitting "patches" and
> making a name for themselves (I'm not specifically referring to Steve
> Yegge here, but to what he called a "standard newcomer").
>
> What is actually there in his posts in that thread?! blatherings and
> generalities about "community" and "attitude" and language "economics"
> and "marketing" that any kid high on weed who'd read a post too many
> on reddit's /r/programming could've wrote, and what little specific
> technical detail shows a clear lack of knowledge about clojure and its
> take on functional programming and java interop and unwillingness to
> learn.
Carlos Ungil
It might be an interesting community exercise to examine the 23 GoF
patterns and discuss whether they are applicable in an FP world and,
if a pattern _is_ still applicable, what it would look like?
nchubrich
though not because of the language itself. The thread now seems to
have moved in a different direction, but I have to say (looking at the
Seajure and Y Combinator threads) that Steve Yegge has some good
points. And ending up here with a thread titled "stand firm
against..." seems to be exactly the sort of community problem that he
is worried about.
I wish that we did not have to deal with a fundamental disagreement
about what a language is \for. If a programming language is something
like Hermann Hesse's Glass Bead Game----an intellectual diversion for
superior intellects----then spending time contemning "Joe Developer"
and "deploring" people who want to suggest different directions for
the language is a worthwhile activity. But ultimately programming
languages are about getting things \done, just as cars are about
\going places.
It is still possible (though increasingly difficult) to tinker with
your own car before driving it. In the beginning, it was obligatory.
You had to choose a third-party auto-body manufacturer. You had to
crank the engine yourself. You even had to manually set the ignition
timing while you were driving. There was a lot of cruft you had to
deal with that had nothing to do with getting from point A to point
B. The first users of cars had to be willing to work with them as a
kind of \hobby----you had to give over a certain amount of time out of
your day just to just keeping the things running. At some point, a
transition happened. They became mass-market devices. The tinkerers
never went away, but their increased numbers, and the increased
numbers of people simply \using cars, led to an increase in simplicity
and reliability. Every time there was an issue to deal with, there
were that many more people with a stake in fixing it. Some people may
miss the old hobbyist culture around cars, but I don't think anyone
really wants to go back to Model T days. The remarkable thing
nowadays is that a \huge number of people become good drivers
(although admittedly there are quite a few that shouldn't be on the
roads)----and driving is a fairly demanding and crucial activity.
Sadly, we cannot say the same thing for computer users.
Clojure is still in the Model T days (though it is continuously
improving). Getting a non-broken Emacs setup is not always easy (I
attended a Clojure class a few weeks ago where we spent the first
couple of hours just trying to get Clojure and Emacs working). There
is no built-in command-line REPL or interpreter. Debugging is cryptic
and not particularly helpful, and occasionally outright misleading
(see what someone posted to the Seajure and Y Combinator threads on
his roundabout way of discovering that Clojure needed advance
declarations). The documentation is not quite as consolidated and
organized as the Java or Python documentation (though it has also
gotten better), and people really wanting to get things done must deal
with two independent sets of documentation, Java and Clojure, the
latter of which is simply organized alphabetically. Supposing that
they do get over this hump and now wish to develop a practical
project, they are immediately faced with more choices. There is no
standard, immediate path for developing web apps, GUIs, or even shell
scripts----you have to use your sixth sense of what libraries may or
may not actually work (which on the Internet can be quite difficult,
as something that doesn't really work rarely \tells you so itself).
You can jump into Python as a complete noob in the morning, and have a
useful program by the afternoon. This is much less likely to happen
with Clojure. There are plenty of smart people who lack both the time
and the system administration chops to deal with getting into
Clojure. This is very sad, because once you get into it, Clojure is
very easy and very sensible. There are surely many great programs
that are not being written----some of them would be programs that help
smoothe the way for everyone else. Many people who would help spread
the functional programming gospel are getting their brains fried in
Python and Java----and teaching them will be that much harder when
they eventually come around (as people have pointed out here).
Now all of the rough edges are perfectly understandable for a new
language, and they continue to get better----and the more you are
willing to Google around and read blogs and so forth, the more
solutions you find. But what bothers Steve Yegge and many other
people, I suspect, is that fixing this fragmented user experience and
the gaps in the language doesn't really seem to be a priority----when
in fact it should be a prime mission. People actually make the
argument that these difficulties are good "weed outs" for the "joe
developers" who would (presumably) get in here and muck everything
up. I have actually heard people say here that people who don't have
the wherewithal to configure emacs and classpaths will never learn
functional programming, and therefore good riddance to them. This is
nonsense. There are different skill sets, and system administration
is a somewhat different one from programming. Functional programming
is a timeless skill, whereas learning the intricacies of Emacs and
Classpaths only gives you knowledge of a very particular insanity
(even though the patience to deal with it is of course a good
attribute). And some people who might become great Clojurians simply
don't have the \time to deal with all of these things when doing them
does not yield an immediate payoff, as I said. Moreover this time-
cost is spent by \everyone, to one extent or another. It's the result
of a slightly disconnected attitude. A few people could spend a few
tens of hours making things easier for everyone else, thereby saving
thousands of man-hours (isn't this supposed to be what programming is
about in the first place?), and yet it doesn't happen.
One might speculate why this is so. Returning to the car example, it
might be that it's much more rewarding to spend your time rebuilding
the engine and making it that much more performant. But the number of
people who will benefit from this zippy engine is greatly reduced when
you still require hand-cranking, manual ignition timing, and after-
market auto bodies. At some point, you will have to roll up your
sleeves and admit that although making automatic starters is not
terribly interesting, the time has come to do the job----and it is
going to make things a lot better.
Programming languages at some point have to face that kind of
transition. Clojure has already faced one such transtition: Rich
Hickey decided to release it. On that day, it became more than his
personal project. Other people by their investment of time developed
a stake in it----what Steve Yegge is saying, I think, is that this
stake has to be recognized; and the culture of the language has to
evolve towards respecting and integrating these stakeholders as a
reflex response, rather than the reflex response being "that's the way
the cookie crumbles...."
Now people will say: There are problems, and people who see these
problems should try to create a library or a contrib. But this only
goes so far. You can't reorganize the documentation that way, and you
cannot provide a smoothe, approved path to building real-world
applications---in fact, initially, by releasing a library you are only
creating more noise. Meanwhile, although this list \does seem
genuinely open to answering people's questions, when it comes to
accepting more substantive contributions, there seems to be a barrier.
For instance, a little while ago I was corresponding with someone who
had released a patch to Clojure. (This was Alyssa Kwan, in case you
want to look up the thread.) Her patch made refs persistent to
disk----something that seemed very much in the spirit of Clojure.
Dealing with disk persistence in a production-ready way may be its own
discipline, but in a language that wishes to "reduce ceremony", there
is no reason that you should have to worry about which database to use
when you merely want to write a program that remembers data when you
re-start it. The interface needed to do this is \almost there.... It
seemed an eminently useful thing, but it got posted to this list and
sank without a trace. Nobody from Core ever contacted her. (She
admitted it was a "hack", but isn't that how all patches start out?)
Clojure patches are not released every day. How much trouble would it
be to make it a custom for one of the core developers to at least
\look at patches and acknowledge their existence? I'm not sure of why
she didn't submit the patch through official channels as shown on the
website----she probably thought that someone from the team would be
following this group enough to contact her, and she wanted to see if
this would happen before getting too deep into the process. It
doesn't seem like too much to ask for some proactive outreach from the
core contributors. It would help develop a culture that welcomes
contributions and suggestions for improvements, rather than appears to
reflexively reject them.
At any rate, this particular contributor has been lost to Clojure----
after seeing the lack of interest, and seeing certain deficiencies in
the language for her purposes (I am not sure which ones), she moved on
to Erlang. This is but a single example, but there are surely others
if one took the time to look; and moreover it's an example of
precisely what happens when a language fails to grow----I mean to say,
that when it fails to grow, it must be that there will be many little
stories like this one. A user sees deficiencies. The user happens to
be one of those rare ones who is capable of fixing things. After
trying to fix a little thing within the community, he decides it isn't
going to work and moves on to a language that either has the feature
in question, or is one that has better prospects for him developing it
and actually getting it accepted.
I am not sure I am saying Clojure should therefore become a "yes"
language in the sense that one would expect if one were setting up a
straw-man argument----a kitchen sink language without any core or
soul. But I'm not sure that is what Yegge means (you might have to
read behind the lines of his brash style), and there are possibilities
of somewhat more open languages that still have a core and a soul.
Especially when the language is well-documented, adding convenience
features for newer users who are not fully into the gospel doesn't
really hurt things for everyone else.
Clojure is a Lisp. Lisp is not really a language, it is a maker of
languages. It therefore doesn't make sense to run it in the spirit of
a prescriptive grammarian. Everyone has the ability to add features
anyway (and to an even greater extent once safe reader macros are
figured out----which I hope they will be), so rejecting simple and
basic features such as loops is ultimately counterproductive, since it
will only lead to a lot of different incompatible third-party versions
being made. (I really don't think the sky would fall in if they were
added----with a general transient feature, such as will probably be
added, they would be perfectly harmless; they could come with as many
warning labels as necessary that they are Not the Clojure Way. New
Lispers have to get used to prefix syntax anyway, and it may be that
one paradigm shift at a time is enough for most people, even many
smart ones; getting them hooked into the language starting by writing
awful programs is, I think, still better than not having them here at
all.)
Making analogies to natural language is always a little dangerous,
because nobody would program in natural language even if the option
were available. Nevertheless: imagine how frustrating it would be if
in learning to speak English, it became at some point along the way
\impossible to speak bad English----especially if you came from
another dialect or language. Suppose you are newly arrived in an
England or America; you want to get around and start living life in
this new country from day one; but people tell you: Wait. I have five
books here that you should read. There are many screencasts, and
myriad blog posts, that need to be read. You can only speak this
language if you are a really, really smart person. Go away and read
all these, and \\don't talk to me until you are through\\.
Nobody manages to learn English this way. They only manage to learn
it because even in its most bastardized form, it is still useful. You
can look at a phrasebook and get useful information for day one, even
when your accent and grammar are horrible. What happens is that you
start talking. If you are a socially apt person, \and you happen to
have friends who are a little indulgent, you start to pick it up. At
some point you may indeed want to sequester yourself and read some of
the great authors and even read a few textbooks to get a feel for
proper English style, but if you are constantly worried about making a
bad impression, even doing this will not make you able to learn----you
will stay in your room and talk to no-one.
The greatest killer to ad-hoc learning would be if you inhabited
circles where one-upsmanship was common; where you constantly felt you
were being judged by what came out of your mouth, rather than by what
you really meant; where there was a kind of xenophobia that considered
new entrants a threat rather than an opportunity. Some of the
dismissive things that are being said about Steve Yegge and Joe
Programmer here have quite a similar tenor.
Mr. Yegge is right: this kind of etiquette is not helpful. He is also
right that it only takes a few people to make the environment
unpleasant. We need to develop an etiquette that is helpful and
welcoming, and (though people do come in many levels of abilities)
does not disparage people for having at a given time \less ability
than you do.
As you have no doubt found, people really do learn programming
languages in an ad-hoc way. They learn to build programs by making
useful programs from day one, in any way they know how; they will
never acquire the art if they are required to stay in an ivory
tower.
If Clojure ends up becoming yet another Lisp that nobody uses, then I
really don't see the point of it. There are already plenty of Lisps
that nobody uses; why go to the trouble of making another? If the
cost of having extra users ends up being spending a few more seconds
filtering out "noise" in the group or on the IRC channel, then this
cost is well worth it. If the cost is a little more humility, then
humility is a good thing anyway. And all those extra users are going
to bring improvements (and if you don't like a particular
'improvement' they bring, then you are welcome to ignore it; but many
of these improvements will be things that \you use, too). They have
bosses who won't use the language if it can't be set up in a few
minutes, but who have the ability to direct vast resources towards
helping any language they \can get to like; they have friends who are
well-skilled but wedded to an existing paradigm, and aren't quite
adventurous enough to try something new unless it gives them some
immediate traction. All of these people, taken in aggregate, are
going to bring beneficial changes. It still requires a strong hand at
the helm----but that hand is now going to be able to steer many more
people in the right direction.
At some point this language is going to have to fix up its ecosystem;
the only question in my mind is whether it is ready to do so \now----I
don't see why not. Meanwhile, the idea that Clojure should aim to
stay small, or that it is simply too difficult for most people to pick
up, is a counsel of despair and arrogance. You don't know this. As
Steve Yegge wrote in an earlier essay, there \was no acceptable
Lisp----the road petered out to a dirt track and led to the same
godawful swamp we've been mucking around in all these years. Lisp
never really had a chance. Clojure may in fact give Lisp a chance,
but it is going to have to be a little more responsive.
I think you are going to end up being surprised at how smart people
really are when they are given the right tools. There were many more
smart people in existence than were willing to program machine code;
there are still more smart people in existence that will not program
Java. I was drawn to Clojure because I felt it was another
evolutionary step in programming. I hope I am not wrong.
I think Mr. Yegge is trying to help us. He hasn't written his blog
post yet, after all----though if he reads this thread, I am afraid it
is simply going to confirm his worries.
.
I once had an English teacher----a prescriptive grammarian par
excellence----who posted a bumper sticker in his room: "Hopefully is
an adverb". He may have been right that the usage of "hopefully" he
deplored was a little tacky-sounding, but that it was totally
useless----this I could not accept. I later learned (shoutout to J.C.
Smith, in case you are listening!) that this "hopefully" is in fact a
\sentential adverb. Sadly, some people have problems using sentential
adverbs. I have no such qualms:
Hopefully Clojure will turn out to help large numbers of people write
useful, comprehensible programs. Hopefully it will change the
mainstream and actually make programming a more joyful and endurable
activity for all. At this it may or may not fail, but we won't really
know without trying to step beyond a niche. I think making a
welcoming culture that can nurture and build such a language is a
noble goal, and well worth pursuing.
On Jul 6, 9:42 am, Carlos Ungil <carlos.un...@gmail.com> wrote:
> On Tuesday, July 5, 2011 8:08:51 PM UTC+2, Sean Corfield wrote:
>
> > It might be an interesting community exercise to examine the 23 GoF
>
> patterns and discuss whether they are applicable in an FP world and,
>
> if a pattern _is_ still applicable, what it would look like?
>
>
>
> Hi Sean,
>
James Keats
On Jul 5, 7:30 pm, Sean Corfield <seancorfi...@gmail.com> wrote:
> On Sun, Jul 3, 2011 at 8:04 PM, Sean Corfield <seancorfi...@gmail.com> wrote:
> >> For example I suggest you look at this video/transcript and pay
> >> attention in particular to the point of debate between Joe Armstrong
> >> sure I buy that...". (also of additional relevance to those two points
> >> arehttp://erlang.org/pipermail/erlang-questions/2011-May/058769.html
> >> Beautiful Architecture regarding a previous Simon Peter Jones Haskell-
> >> related publication, titled "Software Architecture: Object-Oriented
> >> Versus Functional".
>
> > I've read that book (a month or two ago) but I'll go back and re-read
> > that essay in light of this thread.
>
> I think you mean Bertrand Meyer's piece, extolling the virtues of OO
> in general (and Eiffel in particular)? I thought it was a terribly
> self-serving piece. Meyer has a strong bias and quite a bit of disdain
> for anything that isn't Eiffel - which shines right thru that essay to
> the point of making it fairly worthless, IMO. It has no objectivity :)
>
fan of Meyer!), but it needs to be considered within a long... what to
call it... well, debate or dispute that I've long observed between the
Haskell and Eiffel communities; both are concerned with correct
software, but come at it in different ways. I believe both are
relevant, Haskell's statelessness and Meyer's design by contract.
> I read the interview transcript for Syme, Armstrong and Odersky and I
> have to be honest that I found Armstrong almost incoherent and half
> the time couldn't figure out what he was trying to argue at all - so
> I'm not sure what point you're trying to make by referring to that
> interview, sorry. Similarly Armstrong's musings on the Erlang list
> about the entire world being a single flat "namespace" full of
> functions that are globally unique seems rather incoherent too. He
> talks about the problems with using modules to organize functions
> (and, yes, modularity can be hard) but then proposes something that
> would be no different (functions made unique by either having nearly
> random names or a structured set of metadata that would really be
> indistinguishable from modules in the first place - seehttp://erlang.org/pipermail/erlang-questions/2011-May/058773.html).
>
again and again I find more and more and more in what he says. In any
case, what he's suggesting there reminds me of something I read years
ago by Dr Richard Hipp of Sqlite and Tcl core, where he suggests
instead of putting your program in files you put it in a database
http://www.tcl.tk/community/tcl2004/Papers/D.RichardHipp/drh.html
> The Scala forum discussion is more useful and relevant: TL;DR -
> objects are occasionally the most natural model for solving a problem.
> And in Clojure, mutable (shared) state is "occasionally" the most
> natural model for solving a problem. That doesn't seem newsworthy to
> me, just that a pure functional approach might not always lead to the
> cleanest solution. That's kind of a "duh!" because otherwise why would
> we need STM...
allows you to defer implementation and there's value in that.
>
> And then there's the Ruby rant. Yeah, I'd be pretty ticked off that I
> got shot in the foot by combining two or three libraries that
> otherwise ought to behave reasonably together. Global method injection
> is pretty nasty. When I first read about multi-methods and protocols
> in Clojure I was a bit worried that library code might cause a similar
> problem by redefining functions out from under me, by virtue of more
> specific "overloading" but it hasn't been a problem yet and when I
> look at how those features are used in various libraries, I'm no
> longer so worried.
>
> I have other reasons for not liking Ruby so it's ability to shoot you
> in the foot like that doesn't change my opinion of the language (nor
> does it change its widespread popularity for a certain class of
> programmers / companies).
>
> Overall then, modularity is hard and sometimes a shared / mutable
> state solution is cleaner... And I agree with both points. Am I
> missing something in your concerns?
merely suggesting that some of the finest minds in the industry do
still find this a hard problem and can disagree on to how best to deal
with it. :-)
I personally don't feel that much of a schism between functional and
OO, but perhaps that's because I actually quite like both (yeah, hate
me, I actually quite like Java!!). :-D
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View --http://corfield.org/
> World Singles, LLC. --http://worldsingles.com/
Phil Hagelberg
> A few people could spend a few tens of hours making things easier for
> everyone else, thereby saving thousands of man-hours (isn't this
> supposed to be what programming is about in the first place?), and yet
> it doesn't happen.
Really? It doesn't happen?
http://groups.google.com/group/clojure/browse_thread/thread/b87468adeffcd899
http://groups.google.com/group/clojure/browse_thread/thread/bdf5e874f5367b7e
http://groups.google.com/group/clojure/browse_thread/thread/b86a60e252031e74
http://groups.google.com/group/clojure/browse_thread/thread/eb259e999d381d5d
http://groups.google.com/group/clojure/browse_thread/thread/20d314bc0a23b574
http://groups.google.com/group/clojure/browse_thread/thread/48b8fcb3e9b30474
Maybe the twenty minutes spent drafting this voluminous post could have
been better spent doing something a bit more tangible to make things better.
-Phil
Mark Rathwell
> against..." seems to be exactly the sort of community problem that he
> is worried about.
> the gaps in the language doesn't really seem to be a priority----when
> in fact it should be a prime mission.
nchubrich
Leiningen, Swank, etc. I appreciate them and use them----they have
already made things vastly easier for people, and the problems with
setting up Emacs, certainly, are probably more to do with Emacs
itself. I am just pointing out that there is still a long way to go
with the overall user experience, documentation, etc.; and as long as
this remains, Steve Yegge will have a point, and it is not fair to
simply dismiss what he says. The original poster in this thread was
arguing that Clojure has no need to grow to a larger community. He
also was arguing essentially that barriers to new users were a \good
thing. I just wanted to argue against this, and indeed it ended up
being at some length. If I have offended anyone in doing so, that was
not my intent.
When the transition to a more broad-based language happens, then there
will end up being a lot more users than there are people with the
ability to make fundamental changes in the language. They may make
small improvements that don't get much attention, or they may simply
be users with suggestions. There is nothing wrong with either of
these things. I don't think their experience is any less important
than people who "pull their weight". Telling them always to "fix it
yourself" is not necessarily going to improve things----I think we are
all well aware that we should make contributions if we are able. What
fraction of Python users end up making any contribution at all? Are
they a bad thing for Python?
As to making contributions, I just pointed out an example of someone
who made a contribution and was ignored. And as to improving
documentation, how is one to go about doing it? This would be an
excellent area to have some community effort on, especially from
relative beginners, and that is an itch I would not mind scratching.
It isn't my intention to disparage the community. It is a very good
and active community; but this doesn't mean it isn't capable of
improving, even based on suggestions from outsiders like Steve Yegge.
Mark has a good point that the original poster is a fairly new member,
and he is also right that there have been a lot of balanced
responses. I felt however that nobody had really spoken directly and
fully against his basic premise----if someone had, I would not have
said anything.
It is also correct to say that fixing many issues with user experience
is a lot of hard work. I don't dispute that (and I was certainly
exagerrating to say it would only take tens of hours). But there also
seem to be things that might make a very big difference in initial
impression, and would also not be too much trouble. I don't really
know much about packaging, but is it really necessary (for 3+ years)
to tell users under 'getting started' to type "java -cp
jline-0_9_5.jar:clojure.jar jline.ConsoleRunner clojure.main" as their
first introduction to Clojure? (This is what I was talking about with
respect to difficulties in shell scripting.) The fact that it has
remained under "getting started" for all this time (in a place where
virtually every new user is going to visit within his first five
minutes)----this sets the tone to a certain extent, and it makes
impressions about where the priorities of the community might be. It
also gives a mistaken impression that the language is not ready yet----
which is entirely untrue. When Yegge talks about "marketing" a
language, this is exactly the kind of thing he is talking about.
There may be points of disagreement as to how exactly the user
experience should improve, but I hope that the goal of getting new
users up to speed and writing useful code quickly is not really a
controversial one.
Needless to say, I have gone on long enough----
--Nick.
>
> read more »
Ken Wesson
> As to making contributions, I just pointed out an example of someone
> who made a contribution and was ignored.
Does the term "tl;dr" mean anything to you? I doubt very many people
got that far in the wall of text you posted earlier, especially in
just the few hours it's been since you posted it.
nchubrich
see I am not being wholly unreasonable.....
On Jul 6, 7:21 pm, Ken Wesson <kwess...@gmail.com> wrote:
Luc Prefontaine
Luc P.
--
Luc P.
================
The rabid Muppet
Sean Corfield
> Does the term "tl;dr" mean anything to you?
I'll remember this date - I find myself really liking / agreeing with
one of Ken's posts :)
Sorry nchubrich but that really was far too long - I started reading
but couldn't find any meat in the first few paragraphs and just tuned
out... I may try again later but if you can _summarize_ more ppl will
read what you're trying to say.
--
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/
nchubrich
but my main points can be extracted here. Feel free to read as many
or as few of them as you are inclined:
* Clojure still ends up turning off new users more than it needs to.
This may be partly an issue of priorities (see the Getting Started
section on clojure.org). Many good efforts are going into libraries,
but this doesn't necessarily lead to a smoothe starting path. That
would require choices from the top.
* It also can do a better job of attracting and retaining core
contributors. I cited an example of someone who posted a patch to
make refs persistent. She ended up being ignored, and left for
Erlang. But Clojure needs people like her.
* Putting up barriers to entry is \not a good thing. The benefits of
getting new users outweigh the drawbacks, because they will bring more
functionality and maturity with them. It only takes a small effort to
filter out 'noise' in the group (even mine!).
* Since Lisp is highly extensible, in the long run being
'prescriptive' is a losing battle. It is better to eventually add
standard 'bad' features to the language than to tempt third parties to
do it in even worse and incompatible ways.
* Clojure is already enough of a new way of thinking, and it may be
simply too much at once for many people. If a gentle path gets more
people into the ecosystem, it's worth it----once they are in Clojure
they can be steered towards better, more functional ways of doing
things. In any case, experienced users are always free to ignore
extra features.
* It's meant to be a pragmatic language. This means that a prime goal
should be to get people writing useful (web, GUI, shell) code in it
right away. Having choices is good, but being forced to make all
these choices your first day of writing Clojure, when you don't have a
"sixth sense" about the community and What Really Works, is needlessly
discouraging.
* The attitude that Smart People are precisely the ones who will want
to deal with Clojure's existing drawbacks ends up excluding many great
future Clojurians. (A lot of smart people are busy.) The attitude
itself is off-putting and self-defeating. Moreover, dealing with
these issues takes \everyone's time.
* Final (added) point: while it might have made sense to be
'prescriptive' initially in order to establish the identity, core, and
soul of the language, this has been done sufficiently. Newcomers are
not going to be confused about what the main points of Clojure are
now. There is therefore less risk in making it broadly useful to
different paradigms.
If you want to read the arguments behind all that, you can wade into
the post----or add your own.
On Jul 6, 9:37 pm, Sean Corfield <seancorfi...@gmail.com> wrote:
> > Does the term "tl;dr" mean anything to you?
>
> I'll remember this date - I find myself really liking / agreeing with
> one of Ken's posts :)
>
> Sorry nchubrich but that really was far too long - I started reading
> but couldn't find any meat in the first few paragraphs and just tuned
> out... I may try again later but if you can _summarize_ more ppl will
> read what you're trying to say.
> --
> Sean A Corfield -- (904) 302-SEAN
Sean Corfield
On Wed, Jul 6, 2011 at 10:42 PM, nchubrich <nchu...@gmail.com> wrote:
> * Clojure still ends up turning off new users more than it needs to.
I think we need to nail the intro / setup experience and I'm nailing
my colors to Leiningen. I think that needs to be adopted as the
default, standard way to get up and running on Clojure and all the
official tutorials need to be updated to reflect that. It's the
biggest, single roadblock IMO and all that nonsense about downloading
ZIP files and running some specific Java command is a huge barrier to
entry. So far everyone I've introduced to Clojure has struggled with
the Java infrastructure stuff but has "got" Leiningen instantly.
> * It also can do a better job of attracting and retaining core
> contributors. I cited an example of someone who posted a patch to
> make refs persistent. She ended up being ignored, and left for
> Erlang. But Clojure needs people like her.
Unfortunate but all open source projects have a bar to entry and lots
of potential contributors get left by the wayside. I think Clojure
actually has a pretty good ecosystem around contribution. Could it be
better? Maybe. Could it maintain the high level of quality and still
be more inclusive? Hard to say...
> * Putting up barriers to entry is \not a good thing.
I think most people agree with that but the disagreement is on whether
Clojure really is putting up such barriers. I think that's debatable.
> * Since Lisp is highly extensible, in the long run being
> 'prescriptive' is a losing battle.
Again, I think this is a debatable point. I don't believe there is any
direct correlation between the prescriptiveness of a language /
framework and its success.
> * Clojure is already enough of a new way of thinking, and it may be
> simply too much at once for many people.
Aye, maybe. I don't think there's a gentle path tho'. FP is something
you just have to "grok". In some ways, if you want a middle ground,
there's Scala - a hybrid OO/FP language. I have to be honest and say
that after attending Scala Days recently at Stanford, I was even more
convinced Clojure was the right choice for World Singles (we tried
Scala first). I don't think that FP being "hard" is an issue tho' - OO
was "hard" for people back in the day.
> * It's meant to be a pragmatic language.
And I think it succeeds admirably here. We have an incredible
diversity of applications. With Heroku supporting Clojure - and some
great step-by-step tutorials for web applications (with databases) - I
don't think anyone can accuse Clojure of not being pragmatic. I'm
using Clojure for DB work, text file analysis, and all sorts of very
pragmatic, real-world stuff. It's a great language for general purpose
stuff.
> * The attitude that Smart People are precisely the ones who will want
> to deal with Clojure's existing drawbacks ends up excluding many great
> future Clojurians.
I flat out don't agree with this on any level. Clojure is pragmatic
and a wide variety of developers from all sorts of backgrounds are
picking it up and building real world stuff with it. It's not just
about "Smart People" nor about any subset of "Smart People".
> * Final (added) point: while it might have made sense to be
> 'prescriptive' initially in order to establish the identity, core, and
> soul of the language, this has been done sufficiently. Newcomers are
> not going to be confused about what the main points of Clojure are
> now. There is therefore less risk in making it broadly useful to
> different paradigms.
And I think the new process for moving contrib libraries forward
addresses that. I'm late to the game but folks I trust tell me that
contributing to the new contrib libraries is much easier and much more
open that the process around the old contrib libraries.
clojure.core.unify and clojure.core.logic are testament to serious
innovation within the core Clojure context.
--
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/
faenvie
> It did go on too long. I hope when someone \does read it, they will
> see I am not being wholly unreasonable.....
>>I was drawn to Clojure because I felt it was another
>>evolutionary step in programming. I hope I am not wrong.
nchubrich
> my colors to Leiningen. I think that needs to be adopted as the
> default, standard way to get up and running on Clojure and all the
> official tutorials need to be updated to reflect that.
any (hopefully fixed) logorrhea! If people can agree to that one
point, I'm really not going to worry about \any of the others (hence I
put it first).
I think it's an important time to be making it (so let's forget about
the other stuff for now). Clojure was \just put on Heroku----and for
the first time in a while, it showed up under Google news. Steve
Yegge is also (threatening? promising?) to blog about it (after
writing an intro to the Joy of Clojure), and he happens to be one of
the 2 or 3 most-read language bloggers. That means that a lot of
attention is going to be coming Clojure's way soon. It would be very
much a travesty if large portions of these people were put off by out-
of-date stuff on the website. Once they are put off once, it is going
to be much harder to get them in a second time.
Speaking to people who I think would not mind being paid to program
Clojure----we all have a stake in making the language popular and
useful.
(As for Steve Yegge----is he reading all this?----if he's totally
wrong, then of course people should feel free to disagree with him,
and forget about the consequences. But if he happens to be \right,
and I do think he mostly is, then making basically dismissive "firm
stands" against him is not going to do anybody any good. This isn't a
political party, thank God.)
It may be that I am really talking about the website (clojure.org, not
any of the auxiliary ones, which are a bit of a mess in themselves)
more than the language itself. If people receive the \right
instructions, setting up Emacs/Leiningen/Web servers etc. is actually
not so hard. The trouble is that all of this information is currently
scattered to the four winds (I include things like the Paredit cheat
sheet, Slime commands, which Emacs to use, etc.), and I don't think we
should rely on users to pull this information together themselves----
and at any rate, why should they?
Mainstream languages (Java, Python) provide good resources drawn
together onto their websites, painless documentation systems for
contributed packages (where is the Contrib documentation these days?),
and they have a pretty standard option for getting started. I think
Clojure should fully aspire to that, and provide ways for users to
help with developing it. That is a long-term project, but in the
meantime, there seem to be some really simple things that can be done
now.
That's not my whole point by any means, but it's more than enough. I
wish that someone of the stature of Phil Hagelberg would have brought
it up on this thread; but as I have made (enough of) my point, I'll
get off my hobby-horse now. See (some of) you at the Bay Area meetup
tomorrow!
Nick.
On Jul 6, 11:37 pm, Sean Corfield <seancorfi...@gmail.com> wrote:
> Much better. Now I can read it and see your points... and respond...
>
Jonathan Fischer Friberg
* Since Lisp is highly extensible, in the long run being
'prescriptive' is a losing battle. It is better to eventually add
standard 'bad' features to the language than to tempt third parties to
do it in even worse and incompatible ways.
Maybe, but I don't think that the core should change much or at all. Besides, most of those features are probably already in java.
* Clojure is already enough of a new way of thinking, and it may be
simply too much at once for many people. If a gentle path gets more
people into the ecosystem, it's worth it----once they are in Clojure
they can be steered towards better, more functional ways of doing
things. In any case, experienced users are always free to ignore
extra features.
I don't agree, It's like postponing your homework. You have to learn sometime, and I don't think it's going to be easier later on.
* It's meant to be a pragmatic language. This means that a prime goal
should be to get people writing useful (web, GUI, shell) code in it
right away. Having choices is good, but being forced to make all
these choices your first day of writing Clojure, when you don't have a
"sixth sense" about the community and What Really Works, is needlessly
discouraging.
This is dangerous. One of the main points of clojure (in my opinion), is that it's written for the actual users, and not the potential users.
* Final (added) point: while it might have made sense to be
'prescriptive' initially in order to establish the identity, core, and
soul of the language, this has been done sufficiently. Newcomers are
not going to be confused about what the main points of Clojure are
now. There is therefore less risk in making it broadly useful to
different paradigms.
Run for the hills!
I don't quite know what to say about this point, but an earlier mail comes to mind. In that mail someone pointed out that it doesn't really matter how many features a language supports, it will still be specifically good at doing one thing.
Otherwise, I agree with the documentation issue. clojure.org seldom gives me useful information.
Jonathan
Stuart Halloway
It may be that I am really talking about the website (clojure.org, not
any of the auxiliary ones, which are a bit of a mess in themselves)
more than the language itself. If people receive the \right
instructions, setting up Emacs/Leiningen/Web servers etc. is actually
not so hard. The trouble is that all of this information is currently
scattered to the four winds (I include things like the Paredit cheat
sheet, Slime commands, which Emacs to use, etc.), and I don't think we
should rely on users to pull this information together themselves----
and at any rate, why should they?
Timothy Washington
* It also can do a better job of attracting and retaining core
contributors. I cited an example of someone who posted a patch to
make refs persistent. She ended up being ignored, and left for
Erlang. But Clojure needs people like her.
...
James Keats
On Jul 7, 6:42 am, nchubrich <nchubr...@gmail.com> wrote:
> I'll try :) It was really a polemical post for a polemical thread,
> but my main points can be extracted here. Feel free to read as many
> or as few of them as you are inclined
for not having the time to read your points of summary.
To be clear, I do *not* reflect in any way on the clojure community.
As has been pointed out, I've only been around this group for ~3
weeks.
Given though that I've only been around for ~3 weeks, it irked me to
no measure that I saw things in those Steve Yegge's posts in that
thread (here and on hackernews) that could've only indicated that had
he only bothered to read what books had been published and what
screencasts had been put out and what interviews and posts Rich Hickey
and others had made he would've come to an understanding of the
technical reasons why things with the core language are the way they
are - I did - and had answers to his complaints and wouldn't have had
to rant about them. Yup, it irked me that - evidently - he didn't even
bother to learn the language properly and instead ranted vehemently
against things right to its core (compiler etc), demanding they
change.
Those videos that Rich Hickey put out on blip.tv are outstanding. The
guy is a natural teacher, technically brilliant and a joy to listen
to. I think humility should go both ways. People should be humble
enough to realize that no matter how "smart" they are that they always
have to be willing and eager to learn. Yes, sorry, it's a fact of this
trade that you should always be willing and eager to learn, and not a
particular situation to this language community. You can never get too
smart for these shifting sands of industry. Sorry, there's no excuse
here.
With regard to emacs, I've pointed out that I wasn't a fan and that I
regarded it as too tinkerish for my taste, especially so in a thread
in which I invited others to convince me to use it instead of
netbeans. In any case, if you do want to use emacs and wish for an out
of the box good user experience, then you may wish to have a look at
this post by Sam Aaron in this group. I found it very useful and I
must admit it made me play with emacs a bit. There really is nothing
much to emacs, just knowing the shortcut keystrokes and doing them
until they become finger/muscle memory:
http://groups.google.com/group/clojure/browse_thread/thread/c3c4febb5b0f0208
Again, to be clear, and I believe I pointed this out in my original
post, I was *not* against the language growing in terms of users. I've
emphasized that what I was against was that being seen as more
important a goal than having a technically sound language.
I could reply to more of your points, but not wishing this post to get
too long, I'll stop here. :-)
James Keats
On Jul 7, 8:09 am, nchubrich <nchubr...@gmail.com> wrote
> (As for Steve Yegge----is he reading all this?----if he's totally
> wrong, then of course people should feel free to disagree with him,
> and forget about the consequences. But if he happens to be \right,
> and I do think he mostly is, then making basically dismissive "firm
> stands" against him is not going to do anybody any good. This isn't a
> political party, thank God.)
>
It's a technical forum. Technical soundness, rather than social
expansion, should, imho, be the utmost concern. :-)
I empathize with your point regarding how hard it is to deal with
Java. Unfortunately, it is. But I believe it has to be done. Python is
no better in that regard; you still need to understand Unix/C
otherwise you'd be too limited and lost too soon. The other issues you
cited are tangential to the programming language itself, they are
issues of IDE, build system, documentation, etc etc. They do not
affect my original post argument for the language core to be
conservative and technically sound, Python's is. :-)
Stuart Halloway
For instance, a little while ago I was corresponding with someone who
had released a patch to Clojure. (This was Alyssa Kwan, in case you
want to look up the thread.) Her patch made refs persistent to
disk----something that seemed very much in the spirit of Clojure.
Dealing with disk persistence in a production-ready way may be its own
discipline, but in a language that wishes to "reduce ceremony", there
is no reason that you should have to worry about which database to use
when you merely want to write a program that remembers data when you
re-start it. The interface needed to do this is \almost there.... It
seemed an eminently useful thing, but it got posted to this list and
sank without a trace. Nobody from Core ever contacted her. (She
admitted it was a "hack", but isn't that how all patches start out?)
Steve Miner
On Jul 6, 2011, at 10:06 PM, nchubrich wrote:
> And as to improving
> documentation, how is one to go about doing it? This would be an
> excellent area to have some community effort on, especially from
> relative beginners, and that is an itch I would not mind scratching.
Stuart Halloway responded about how to contribute to the "Getting Started" documentation.
If you want another place for language documentation, take a look at ClojureDocs.org. Anyone can sign up and contribute examples and usage notes.
Steve Miner
logan
to say was "say yes to USERS", not "say yes to FEATURES", but in his
typical off-the-cuff ranty writing style, he had accidentally
conflated the two.
As far as saying yes to every feature, I think that is obviously not a
great idea. It is easy to make the argument that one of the reasons
Java became successful are the features that it said no to: No to
pointers, no to multiple inheritance, no to operator overloading.
As far as saying yes to USERS. I think Yegge brings up a really
important point about a critical problem that plagues not just clojure
but all open source communities in general. Basically the blowhard who
thinks he is smarter than the average person and who enjoys letting
other people know it. We all have some element of self-interest in our
hearts. When you get paid to write software the reward is obvious.
When you are contributing to open source what is the motivation? If
you have the soul of an artist maybe you just want to create something
beautiful. But there are a lot of others for whom contributing to open
source is an ego trip. They haven't gotten the recognition that they
feel they deserve in other parts of their life, so they decided that
by writing something cool and putting it on the internet then they
will be cool too.
When you are getting paid for software you have a direct incentive to
make your software as user friendly as possible. If it "just works"
for the users and they like it and they can happily use it without
ever looking at a manual, then you get more users and more money.
People in open source want more users too but they don't necessarily
want it to be user friendly. In fact often I feel there is this huge
incentive to NOT be user friendly. It is like hazing. You get to say
things like "That is not the functional way, I know the right way but
you don't, I am better than you." or "Why would anyone want to do
that? The problem you are stumped on has such an obvious solution to
me that I can't even understand why you have a problem, I am better
than you." There is this attitude of "I figured how to write my
own .emacs all by myself, from reading the forums and the
documentation, because I was too socially maladjusted to ask anyone
for help. Why can't you?"
This poisonous attitude is perfectly exemplified in this thread by
James Keats. I think it's important to recognize that we are all human
beings, which means that we are herd animals, which means that we all
have genetically hardwired responses to desire to be part of a
hierarchy and we desire to place ourselves higher up on that
hierarchy. This is why we have bullies in kindergarten. But just
because you were bullied in kindergarten does not make it okay for you
to bully newbies over the internet now. Back then it was not okay for
the bigger kids to pick on the smaller kids and right now just because
you are smarter than someone does not make you a better person. We are
herd animals but we are also civilized human beings, we can rise above
our base animal desires to put other people down, we don't have to
give in to our desire to feel like we are part of a special club.
I think the clojure community has in general been much better about
this than some other open source communities, but as clojure gets more
popular, the ego trippers are starting to join the party, the guys who
want to say "I use clojure, clojure is the best language of all, I am
better than you!" The guys who don't care about the pragmatic beauty
of clojure and just want to be a big man in a new tribe. I think it
would be good to not pay too much attention to such people and say yes
to the users. Say yes to the newbies, yes to the object oriented
people not by making clojure more object oriented, but by not shutting
them out of the discourse and laughing them off as just "object
oriented people". As someone whose name I can't remember right now
once said, "There are no bad students, only bad teachers."
nchubrich
can be an inherent instinct against user-friendliness in open-source
software, as well as a kind of hierarchy----and you've identified the
source and nature of it, I think. The response to this is not to try
to become commercial. The response is to realize that it's a piece of
sociology and human nature that we all have to make an extra effort to
rise above. It's not such a different issue from table manners----
good food tends to make people act like pigs unless they are careful,
so people actually have to explicitly learn to eat politely. It
doesn't happen by instinct, it requires leadership and guidance.
For the present circumstance, I think it means that open source
projects have to make user-friendliness (both on the forums, in the
software, and in the documentation) a core value whether they have any
deep animalistic drive to do so or not. It needs to become ingrained
in the culture, and examples need to be set. I think Clojure is not
too far behind the head of the pack on some of these matters. As Sean
Corfield pointed out, Lein is a big part of making Clojure user-
friendly; unfortunately, its central role isn't really reflected on
Clojure.org. The documentation meanwhile could stand to be improved
(many people seem to agree on that point), and that I think will go a
long way towards shaping the culture in the right direction. I need
to reply to Stu's post on that.
(And yes, I intend to help. But I do want to say that talking about
things is \also useful. I admit the wrongth of my prolixity in the
first post, but I \don't think it's wrong to talk about cultures and
processes. Every group of people has to do this at some point, and it
may not always fit under the 140 character limit. And not all
problems in a programming language community can be solved by
programming.)
Logan's economic explanation makes sense, but there is still an irony
in the way programmers spend their day jobs making life easier for
users, but don't always bring the same ethic to bear on their own
environment. If I may make yet another homely analogy, it's like a
family that keeps one room in pristine condition for guests, but lets
the rest of their house accumulate cruft. It's a common but odd
situation. And (as anyone who has dealt with Makefiles would know) it
can be amazingly durable. We're already vastly better off than
Makefiles, but this is no reason for complacency.
Sean Corfield
<stuart....@gmail.com> wrote:
> (1) Edit and improve the official
> docs: http://dev.clojure.org/display/doc/Getting+Started
I think one sticking point here is that there are (so far) seven
IDEs/editors listed and five build tools. For a n00b, that's too much
choice. There have been discussions about
http://clojure.org/getting_started in the past but it's still showing
the (fairly horrible) instructions that start with talk of a source
code repository, a ZIP file and bytecode generation(!).
There needs to be a decision by the core team on a single,
recommended, _simple_ getting started process and update that page to
show that (please: lein). Beyond that simple process, it can point to
the dev wiki with the list of IDEs and build tools.
The problem here is there needs to be more proscription around Getting
Started so n00bs aren't completely confused by either the primitive
instructions (clojure.org) or overwhelmed by choice (dev.clojure.org).
> (2) Link to the official docs, and help us do the same. clojure.org has a
> slower update process than the dev site (by design!) but if there is
> something wrong, or a place where it needs to link out, please let us know!
See above. Suggestions have been made about making
clojure.org/getting_started better :)
> (3) Encourage people who wrote a blog post 18 months ago that is now filled
> with misinformation (as things have moved on) to go back and add a link to
> the official docs.
Definitely a good point. I'll go back over my blog posts for Clojure
and update anything that's wrong (I think I already updated some of my
Getting Started stuff but I'll double-check).
--
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/
James Keats
On Jul 7, 8:03 pm, logan <duskli...@gmail.com> wrote:
>
> This poisonous attitude is perfectly exemplified in this thread by
> James Keats.
read again what I had maintained:
- I had implored that technical arguments alone should decide
technical issues, not "who's who".
- I made clear that I had asked dumb questions, and that I don't
consider myself too smart to read what'd been put out already. I made
a clear distinction between a newbie who'd ask dumb questions (and
explicitly included myself in that category), and a "who's who" from
elsewhere demanding major changes outright.
- If this is going to turn into a who's against whom (I made it clear
time and again I wasn't against Steve Yegge personally but against his
"yes language" *features* push, had it come from a Mr firstName
lastName I would've still voiced the same technical concern and titled
it accordingly), I regret that I do not have the time for that.
Regards.
J
nchubrich
Thanks for the links. I took a look at clojure dev and signed up. I
don't see any way to edit----does that happen after I mail in the
Contributor agreement? It does seem a little medieval to have to mail
it in.
Clojure dev though doesn't seem like such a direct way of improving
clojure.org, which is what people see and try to use. (Steve,
ClojureDocs.org is also another outside site.) The fact that people
are posting tutorials in blog posts that need to be corrected as the
language changes strikes me as an indication that there isn't enough
of a way for them to write these things under Clojure's aegis.
Why not eventually make a "beta" version of Clojure.org (with the
exact same formatting), that can then be migrated piece-by-piece to
the main site as things get approved----and let anyone edit this, wiki-
style? What's there on clojure.org is already quite good (with the
exception of Getting Started, which still tells people to do "java -
cp ...."). There could also be someone responsible overall for each
section, so it doesn't get too messy a la the Emacs Wiki. I'm happy
to put some time into organizing the API a little better, but I don't
see any way of doing this at the moment. (I see no API section on
Clojure dev.)
I'd love to see the API reference not only organized into good
groupings with cross-references from a given function (one area where
OOP actually \is a good thing----the only one, so far as I can tell),
but have these groupings include references to related Contribs and
even Java functions with their Clojure call syntax. So long as there
is a way for users to add these sorts of things, it can grow over
time. There is probably a way of automatically snarfing things from
JavaDocs as well. Again, I'm happy to undertake this sort of project,
but I need to see if it's a good idea, and I obviously need guidance.
Why not have clojure.org also include tutorials (the equivalent of
Java trails, perhaps) to get a given thing done: shell scripting; web
server; system programming; Swing; etc. The best of what people put
on blogs could go straight on the main site, and then be kept up to
date right there. Once this is done, you might actually get people up
to speed on Clojure fairly quickly.
Best,
Nick.
James Keats
On Jul 7, 8:35 pm, nchubrich <nchubr...@gmail.com> wrote
> > someone whose name I can't remember right now
> > once said, "There are no bad students, only bad teachers."
to Clojure in Action later this month), there are excellent videos on
blip.tv (Rich Hickey's are some of the best programming talks I've
ever seen), there are tons and tons and tons of books on Java, and
there's ample, ample lisp literature.
I don't buy the "user-friendliness" argument or "bad teachers". This
is a technical trade, not an end user application for grampa. What's
more, people are not in the business of education; they're gracious
enough to share their code. I also don't understand why people are in
such a rush to get hacking clojure code right away; Peter Norvig has
argued that it takes a long time to learn to program, and I would
suggest to anyone considering a new language to learn to allow
themselves an adequate amount of time well ahead to do the homework
required. I think for those who come to clojure having had some Java
experience, some lisp experience, some functional programming
experience o the ML/Haskell family, then the language is actually such
a leap in simplification.
For people's sense of sanity, it's not wise to try to run before you
walk. Am I being a "blowhard" by saying this?! I don't believe so,
this is a reality. I have expressed an opinion that clojure is for the
advanced programmer (Java/lisp/ML-Haskell), and there are perhaps some
simpler language (eg. python, which is quite capable and I'm actually
quite fond of). But fine, people are free to be impatient and get
frustrated and depressed if they so insist.
Meikel Brandmeyer
Am 07.07.2011 um 21:54 schrieb Sean Corfield:
> I think one sticking point here is that there are (so far) seven
> IDEs/editors listed and five build tools. For a n00b, that's too much
> choice.
I'm always bewildered by this argument. What has a newbie to choose here? Of course he uses what he's used to. Many Java devs probably want one of the IDEs they already know. Old-time Lispers use emacs.
I don't read this information as “Look, newbie, there is emacs, or eclipse, or vim, which you can use to edit Clojure code. And you can build clojure stuff with leiningen, or with gradle, or with maven.” I see this list as: “I'm used to maven and eclipse, let's see how I get this running with the tools I know already.” Isn't that the most natural thing someone would try to do?
Sincerely
Meikel
nchubrich
(which is why it would help to have a single person in charge of each
section). For one thing, the information is really in the wrong
place----it should be on Clojure.org. Even where it is, there's
something aesthetically wrong about having to wade through all of
those choices right at the outset. (I say this even as an admitted
long-poster....)
Having text describing emacs and lein setup, followed by links to all
the other options for those who know about them, seems like a good
compromise. The information is still there, and people who need it
will know to click on it. Everyone else can have setup instructions
that are simple and concise (and Emacs and Lein really do seem to be
emerging standards).
Sean Corfield
> I'm always bewildered by this argument. What has a newbie to choose here? Of course he uses what he's used to. Many Java devs probably want one of the IDEs they already know. Old-time Lispers use emacs.
And yet the #1 "FAQ" we see on lists and reflected in blog posts is
about getting Clojure up and running... We see Java developers,
committed to their favorite IDE, still asking "Should I install /
learn Emacs?" We see old-time Lispers, happy with Emacs, struggle with
the Java infrastructure. A lot of n00bs want to be told the "One True
Way" to set up their development environment - they don't want to be
confronted with choices.
Like you, I don't entirely understand why this is an issue - but I
accept that it clearly _is_ an issue...
Lee Spector
On Jul 7, 2011, at 7:29 PM, Sean Corfield wrote:
> And yet the #1 "FAQ" we see on lists and reflected in blog posts is
> about getting Clojure up and running... We see Java developers,
> committed to their favorite IDE, still asking "Should I install /
> learn Emacs?" We see old-time Lispers, happy with Emacs, struggle with
> the Java infrastructure. A lot of n00bs want to be told the "One True
> Way" to set up their development environment - they don't want to be
> confronted with choices.
>
> Like you, I don't entirely understand why this is an issue - but I
> accept that it clearly _is_ an issue...
For me at least the issue isn't that there should be a single blessed setup, but rather that there should be at least one setup (and documentation for that setup) that's a little more newbie-friendly than any of them currently are.
The available options are definitely getting better (and by "the options" I mean not only the software packages but also the installation recipes etc., although a lot of this is scattered) but in my experience and for my purposes, which include teaching, they all still have some rough spots.
On the emacs/lein option I think the main problem is the messiness of the installation and configuration process. If code/instructions were available that reliably produced a full and reasonably configured emacs/slime/lein setup, on most common platforms, with a single download and double click (or something not much more complicated), then this would be a more attractive option.
-Lee
Ken Wesson
>
> On Jul 7, 2011, at 7:29 PM, Sean Corfield wrote:
>> And yet the #1 "FAQ" we see on lists and reflected in blog posts is
>> about getting Clojure up and running... We see Java developers,
>> committed to their favorite IDE, still asking "Should I install /
>> learn Emacs?" We see old-time Lispers, happy with Emacs, struggle with
>> the Java infrastructure. A lot of n00bs want to be told the "One True
>> Way" to set up their development environment - they don't want to be
>> confronted with choices.
>>
>> Like you, I don't entirely understand why this is an issue - but I
>> accept that it clearly _is_ an issue...
>
> For me at least the issue isn't that there should be a single blessed setup, but rather that there should be at least one setup (and documentation for that setup) that's a little more newbie-friendly than any of them currently are.
How about:
GETTING STARTED
If you're coming from a Lisp background, or at least are familiar with
emacs _here is how to set up with emacs and leiningen_.
If you're coming from a Java background, _download Eclipse and CCW_ or
_download NetBeans and Enclojure_.
If your programming experience lies elsewhere, or you're new to
programming altogether, _insert something here_.
The last one is maybe the trickiest. Best might be a good text editor
for programming that isn't Emacs, combined with leiningen. Someone had
been working on a lightweight Clojure IDE/editor here recently but I
don't know the current status of that. Notepad won't cut it and it
should follow normal GUI text editor conventions. All of the
programmers' editors I know of are either the one built into NetBeans,
the one built into Enclojure, emacs, vi, something that imitates
emacs, something that imitates vi, abandoned, or non-free, though.
> On the emacs/lein option I think the main problem is the messiness of the installation and configuration process. If code/instructions were available that reliably produced a full and reasonably configured emacs/slime/lein setup, on most common platforms, with a single download and double click (or something not much more complicated), then this would be a more attractive option.
I'm not so sure. For newbs to it, emacs has a steep learning curve
even if you avoid any installation hiccups. On the other hand, for
emacs old hands the current rocky road to configuring
emacs/slime/swank-clojure/lein/etc. to play nice with one another is
the sort of thing they've been coping with for years and in some cases
even decades; one might argue "they can take it". Of course, emacs
setup for Clojure that works painlessly out of the box wouldn't be a
bad thing, but I'm not sure it's a priority compared to getting a
truly newbie-friendly installation option up there and documented for
people that would be intimidated by Eclipse and Netbeans and would
have kittens if suddenly confronted with emacs. :)
Lee Spector
On Jul 8, 2011, at 1:19 AM, Ken Wesson wrote:
>
> If your programming experience lies elsewhere, or you're new to
> programming altogether, _insert something here_.
>
> The last one is maybe the trickiest. Best might be a good text editor
> for programming that isn't Emacs, combined with leiningen. Someone had
> been working on a lightweight Clojure IDE/editor here recently but I
> don't know the current status of that.
I'd like to hear more about this IDE/editor if it's still a going concern.
I tried to find an editor for a setup like this but was unable to find one that really fit the bill, with a major sticking point being what I consider minimal Lisp editing features: bracket matching and language-aware auto-re-indenting (and syntax coloring wouldn't hurt).
> I'm not so sure. For newbs to it, emacs has a steep learning curve
> even if you avoid any installation hiccups.
Certainly true, and this is one of the other reasons that I taught with Eclipse/CCW rather than an emacs setup last year. But with a well-configured modern emacs some of this can be ameliorated; e.g. there are Mac versions in which you can use multiple windows for different buffers in an OS native way, and use OS native navigation techniques, and find commands in menus, etc. My dream installer would produce as friendly a setup as possible, with versions for most common platforms, and if this existed then I think that students could go from zero to knowing what they need to know for an edit/run cycle on this setup in one session. Yes they could spend years mastering it, but they could do real work without mastering it or knowing anything about how to tinker with it.
I agree that the emacs interface learning curve would be the roughest spot in this particular setup, but I think it would be manageable and worth it to get the positives.
> Of course, emacs
> setup for Clojure that works painlessly out of the box wouldn't be a
> bad thing, but I'm not sure it's a priority compared to getting a
> truly newbie-friendly installation option up there and documented for
> people that would be intimidated by Eclipse and Netbeans and would
> have kittens if suddenly confronted with emacs. :)
A lot of the bad complexity of Eclipse (and I guess Netbeans, though I have less experience there) has to do with things that will be handled elegantly by leiningen from the command line in an emacs/lein setup.
I guess I would rank the emacs/slime/lein installation/configuration problem as a high priority because I think that solving it would produce a good way for newbies to get started with just one step (with the downside of the emacs interface learning curve, to whatever extent that can't be addressed via configuration) while also providing an environment that works well for advanced users. At least in my own case I'm pretty sure that if the emacs/slime/lein installation/configuration problem was really solved well then I would switch to that as my teaching environment (and also as my research coding environment).
BTW I'm an old lisper who has lived a lot in emacs but I've mostly avoided having to tinker with it, so the hoops that I had to jump through to set things up for Clojure didn't come naturally to me. Part of this is probably because I spent a fair amount of time using Lisp machines and then a long stretch using MCL which had the wonderful FRED (FRED Resembles Emacs Deliberately) editor that combined all of the power of Emacs with single-drag installation and a thoroughly OS (Mac) native interface. FRED still lives on in some forms, including MCLIDE, which has Clojure support (but it's Mac only and has some other issues).
-Lee
Ken Wesson
> Certainly true, and this is one of the other reasons that I taught with Eclipse/CCW rather than an emacs setup last year. But with a well-configured modern emacs some of this can be ameliorated; e.g. there are Mac versions in which you can use multiple windows for different buffers in an OS native way, and use OS native navigation techniques, and find commands in menus, etc.
There are people that would kill for a Windows port of emacs that let
you navigate, find capabilities, and find out about shortcut keys in
an OS native way. Especially if it came with OS native help you could
use the OS native help browser to browse. :)
Well, at the very least, there are people that might actually try
emacs (or try emacs again) if such a thing existed, but not
otherwise...
> My dream installer would produce as friendly a setup as possible, with versions for most common platforms, and if this existed then I think that students could go from zero to knowing what they need to know for an edit/run cycle on this setup in one session. Yes they could spend years mastering it, but they could do real work without mastering it or knowing anything about how to tinker with it.
Yes, a problem with emacs is that it doesn't follow either of the
usual patterns. Some apps have a learning curve that's gentle, then
plateaus -- simple things like Notepad. Others have one that starts
out gentle and then takes off like an exponential function graph --
it's easy to become productive at simple tasks with these, but you can
also do more wizardly things with time and practice. The easy part
also gives you a "beachhead" in its territory; no matter how complex
the advanced features are, at least such basic things as locating and
searching the documentation, changing the advanced feature's settings,
the general navigation mechanics, etc. are familiar, giving you a
starting point.
The emacs learning curve, by contrast, is like a sheer cliff of solid
ice without hand or foothold. :)
> A lot of the bad complexity of Eclipse (and I guess Netbeans, though I have less experience there) has to do with things that will be handled elegantly by leiningen from the command line in an emacs/lein setup.
Yes, possibly. Would that the Eclipse/CCW modern graphical editor,
namespace browser, REPL, and other features could be used with lein
instead of Eclipse's own build configurators.
> I guess I would rank the emacs/slime/lein installation/configuration problem as a high priority because I think that solving it would produce a good way for newbies to get started with just one step (with the downside of the emacs interface learning curve, to whatever extent that can't be addressed via configuration)
That's not a "downside", that's a pit full of sharks with lasers on
their heads, at least from your hypothetical newb's perspective,
unless it was really REALLY tamed. That Mac version MIGHT do it, but
only for Mac users and only if OS-native shortcut keys for common
tasks (save, save as, change to mru nonfocused window, cut, copy,
paste, undo, redo) are supported or an installer can easily configure
that. Nothing will annoy a new user of the app that isn't new to the
OS more than being tripped up if they try to use keyboard shortcuts
instead of the mouse to get a task like that accomplished. Oh, and I
do hope clicking, click-drag-selecting, and so on in the editor
windows would not violate Least Surprise either. With ports of
nonnative software you often can't even count on that. That and
command-X not being bound to "format filesystem" instead of "cut" are
the most crucial I'd think there.
Windows users, OTOH, will apparently be SOL for the foreseeable unless
you have an alternative Windows editor that'll do and is sufficiently
native in its UI behavior.
> BTW I'm an old lisper who has lived a lot in emacs but I've mostly avoided having to tinker with it, so the hoops that I had to jump through to set things up for Clojure didn't come naturally to me. Part of this is probably because I spent a fair amount of time using Lisp machines and then a long stretch using MCL which had the wonderful FRED (FRED Resembles Emacs Deliberately) editor
Ah, the familiar hacker GRAT (GRAT Recursive Acronym Trick). Gotta
watch out for that. :)
> that combined all of the power of Emacs with single-drag installation and a thoroughly OS (Mac) native interface. FRED still lives on in some forms, including MCLIDE, which has Clojure support (but it's Mac only and has some other issues).
Why are the poor Windows users left out?
For that matter, why are the poor Gnome/KDE users, many of them
Windows refugees that want a GUI and applications that act Windowslike
(minus all the crashing and viruses), left out?
David Miller
How about:
GETTING STARTED
snip
If you're coming from a Lisp background, or at least are familiar with
emacs _here is how to set up with emacs and leiningen_.
> On the emacs/lein option I think the main problem is the messiness of the installation and configuration process. If code/instructions were available that reliably produced a full and reasonably configured emacs/slime/lein setup, on most common platforms, with a single download and double click (or something not much more complicated), then this would be a more attractive option.
On the other hand, for emacs old hands the current rocky road to configuringemacs/slime/swank-clojure/lein/etc. to play nice with one another is
the sort of thing they've been coping with for years and in some cases
even decades; one might argue "they can take it".
Love regards etc
David Miller
http://www.deadpansincerity.com
07854 880 883
Lee Spector
On Jul 8, 2011, at 2:39 AM, Ken Wesson wrote:
>
>> (with the downside of the emacs interface learning curve, to whatever extent that can't be addressed via configuration)
>
> That's not a "downside", that's a pit full of sharks with lasers on
> their heads, at least from your hypothetical newb's perspective,
> unless it was really REALLY tamed.
Yeah, but there are a lot of sharks in these waters, and FWIW an improvement on the emacs/slime/lein installation/configuration front would make that the clear winner for me, lasers and all. I'm currently leaning this way anyway for the fall semester, inspired in part by Sam Aaron's setup and video (http://vimeo.com/25190186). Also FWIW our classroom/lab is mac based, although students have a mix of platforms and they'll have to set things up on their own machines too.
-Lee
James Keats
On Jul 8, 6:19 am, Ken Wesson <kwess...@gmail.com> wrote:
>
> > On Jul 7, 2011, at 7:29 PM, Sean Corfield wrote:
> >> And yet the #1 "FAQ" we see on lists and reflected in blog posts is
> >> about getting Clojure up and running... We see Java developers,
> >> committed to their favorite IDE, still asking "Should I install /
> >> learn Emacs?" We see old-time Lispers, happy with Emacs, struggle with
> >> the Java infrastructure. A lot of n00bs want to be told the "One True
> >> Way" to set up their development environment - they don't want to be
> >> confronted with choices.
>
> >> Like you, I don't entirely understand why this is an issue - but I
> >> accept that it clearly _is_ an issue...
>
> > For me at least the issue isn't that there should be a single blessed setup, but rather that there should be at least one setup (and documentation for that setup) that's a little more newbie-friendly than any of them currently are.
>
> How about:
>
> GETTING STARTED
>
> If you're coming from a Lisp background, or at least are familiar with
> emacs _here is how to set up with emacs and leiningen_.
>
> If you're coming from a Java background, _download Eclipse and CCW_ or
> _download NetBeans and Enclojure_.
>
> If your programming experience lies elsewhere, or you're new to
> programming altogether, _insert something here_.
>
> The last one is maybe the trickiest
- If you're new to programming, clojure will overwhelm you. Start with
something like python.
- If you come from python/ruby and have no java background, do not
expect to start "hacking" clojure in the morning and be "productive"
and accomplishing work in the afternoon of that same day; go learn
java for a while first (a few months at least). Also, continue using
whatever it is you use now till you're confident you know enough to
jump ship.
- we can't teach you java, please go learn java for a while if you
have no java experience, there are tons and tons of tutorials and
books on teaching you java.
- if all you need is a "hello world" program, there are simpler
languages for this purpose (python etc). Consider clojure if you have
need for java apis or concurrency needs (concurrency is an advanced,
low level topic and not something most programmers should concern
themselves with).
- and so on... I think it's important to have such caveat emptors, it
seems many of the complaints relate to expectations mismatched to
reality
Regards
J
faenvie
>>expect to start "hacking" clojure in the morning and be "productive"
>>and accomplishing work in the afternoon of that same day
but fair ... isn't it ?
Lee Spector
On Jul 8, 2011, at 10:29 AM, James Keats wrote:
> May I also add the following caveat emptors:
> - If you're new to programming, clojure will overwhelm you. Start with
> something like python.
I disagree. This is a subject of religious debates that I don't want to get into in detail, but FWIW this educator thinks that Lisp is a perfectly defensible first language and that Clojure can serve the purpose quite well as long as installation and tooling doesn't make it unnecessarily difficult to write and run code.
> - If you come from python/ruby and have no java background, do not
> expect to start "hacking" clojure in the morning and be "productive"
> and accomplishing work in the afternoon of that same day; go learn
> java for a while first (a few months at least). Also, continue using
> whatever it is you use now till you're confident you know enough to
> jump ship.
> - we can't teach you java, please go learn java for a while if you
> have no java experience, there are tons and tons of tutorials and
> books on teaching you java.
Disagree and disagree. One can do a lot in Clojure with almost no knowledge of the Java language or the Java ecosystem. At least for the kinds of things that I do. Yes, I occasionally need to use an interop form for something for which there's no Clojure version, but for me that's rare and easy to pick up on a case by case basis without being a Java programmer.
> - if all you need is a "hello world" program, there are simpler
> languages for this purpose (python etc). Consider clojure if you have
> need for java apis or concurrency needs (concurrency is an advanced,
> low level topic and not something most programmers should concern
> themselves with).
Disagree. Nobody *just* wants to write "hello world," of course, but Clojure can be a great language for many people who have zero need for Java APIs or concurrency. I use/teach it because of all of the great features of Lisps more generally, and because Clojure is the best Lisp going (IMHO).
> - and so on... I think it's important to have such caveat emptors, it
> seems many of the complaints relate to expectations mismatched to
> reality
Maybe, but since I disagree with every one of your caveats I wouldn't advocate making them :-0.
-Lee
Jonathan Fischer Friberg
May I also add the following caveat emptors:
- If you're new to programming, clojure will overwhelm you. Start with
something like python.
I think most programming languages overwhelm you if you don't have any prior experience. I started with C++ and when pointers & references where introduced to me, my head almost blew out.
- If you come from python/ruby and have no java background, do not
expect to start "hacking" clojure in the morning and be "productive"
and accomplishing work in the afternoon of that same day; go learn
java for a while first (a few months at least). Also, continue using
whatever it is you use now till you're confident you know enough to
jump ship.
I'm learning java through clojure. Since clojure and java is so tight, it works fine.
- if all you need is a "hello world" program, there are simpler
languages for this purpose (python etc). Consider clojure if you have
need for java apis or concurrency needs (concurrency is an advanced,
low level topic and not something most programmers should concern
themselves with).
You probably don't mean an actual "hello world" program, but let's compare them anyway.
python:
print "hello world"
clojure:
(print "hello world")
Not that much harder, is it?
Jonathan
Timothy Baldridge
And this is the crux of the issue. It's the installation and tooling
that's killing Clojure, ATM. Okay, killing is a strong word..but
perhaps killing it for the newbies. Let's say I want to install some
OpenGL libs for Python...I go and install Python. On Windows this is a
simple .exe installer. This puts python into a location on my drive
that makes sense (c:\Python27), and in there I see
(c:\Python27\python.exe). If I run that program, HEY!, I get a REPL.
Now I want to install opengl...so I find pygame...download the .exe,
and run it. The installer finds my Python directory, and after install
I just have to re-load my REPL.
Now compare that to Clojure. I know Clojure does what it does for a
reason, but let's be honest. First I have to download the JDK (and I
have to know what that is), then I have to download something like
lein, and add it to my command path. From there I have to figure out
what on earth a project.clj file is, and what the contents mean. Then
I can do lein deps, and then lein repl. Yay! I have a repl. Now I want
to install OpenGL. That involves some interesting magic with clojars,
lein and other such tools.
As a quick compare...
Python:
python->pygame
Clojure:
JDK->lein->clojure->penumbra
So over all yes, I think Clojure is just fine as a "first language",
but it's horrible as a "first installed language".
Timothy
Phil Hagelberg
> On Jul 8, 2011, at 2:39 AM, Ken Wesson wrote:
>>
>>> (with the downside of the emacs interface learning curve, to whatever extent that can't be addressed via configuration)
>>
>> That's not a "downside", that's a pit full of sharks with lasers on
>> their heads, at least from your hypothetical newb's perspective,
>> unless it was really REALLY tamed.
>
> Yeah, but there are a lot of sharks in these waters, and FWIW an
> improvement on the emacs/slime/lein installation/configuration front
> would make that the clear winner for me, lasers and all.
Have you tried the Vagrant approach? It's a one-button
Emacs/Clojure/Leiningen hacking VM setup[1]:
https://github.com/Seajure/emacs-clojure-vagrant
-Phil
[1] - provided you have virtualbox.
Lee Spector
On Jul 8, 2011, at 12:17 PM, Phil Hagelberg wrote:
>
> Have you tried the Vagrant approach? It's a one-button
> Emacs/Clojure/Leiningen hacking VM setup[1]:
I haven't, although I've been watching the list traffic on this. Now I see that I must. I will!
Thanks,
-Lee
Vivek Khurana
>
> Have you tried the Vagrant approach? It's a one-button
> Emacs/Clojure/Leiningen hacking VM setup[1]:
>
> https://github.com/Seajure/emacs-clojure-vagrant
>
> -Phil
>
> [1] - provided you have virtualbox.
That is still not as easy as python. Running VM is a bigger overhead...
regards
Vivek
--
The hidden harmony is better than the obvious!!
Lee Spector
On Jul 8, 2011, at 12:38 PM, Vivek Khurana wrote:
> That is still not as easy as python. Running VM is a bigger overhead...
There are different kinds of overhead. If the installation and setup of the VM is simple and bullet proof then this is acceptable overhead for me.
On the other hand I just tried it and while the first two steps were fine (installing virtualbox and the extension pack) I then got:
lee-spectors-macbook-pro:Seajure-emacs-clojure-vagrant-9a47c23 leespector$ gem install vagrant
WARNING: Installing to ~/.gem since /Library/Ruby/Gems/1.8 and
/usr/bin aren't both writable.
WARNING: You don't have /Users/leespector/.gem/ruby/1.8/bin in your PATH,
gem executables will not run.
Building native extensions. This could take a while...
ERROR: Error installing vagrant:
thor requires RubyGems version >= 1.3.6
This is on a macbook pro running os x 10.8.7.
-Lee
Jonathan Fischer Friberg
Jonathan
--
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
Lee Spector
On Jul 8, 2011, at 1:02 PM, Jonathan Fischer Friberg wrote:
> It looks like you haven't got enough privileges, try "sudo gem install vagrant"
Thanks. That solved some of the problems (and I would suggest that sudo be added to the vagrant readme instructions) but I still get:
ERROR: Error installing vagrant:
thor requires RubyGems version >= 1.3.6
So I guess I need to track that down...
-Lee
Michael Klishin
ERROR: Error installing vagrant:So I guess I need to track that down...
thor requires RubyGems version >= 1.3.6
To upgrade rubygems, use
[sudo] gem update --system
--
MK
http://github.com/michaelklishin
http://twitter.com/michaelklishin
Colin Yates
and Clojure. Sure, they run on the JVM, but that is their *only*
relationship (from a consumer's point of view) as far as I can see.
For me, after a decade+ of developing Enterprise Java (primarily web)
applications I am sick and tired of all the hoops and ceremony
involved in building Java applications. More and more I am coming
(from reading other people's work - not my own discovery!) to realise
that most established "best-practice" is only required to answer an
insufficiency in the language itself.
The thing that most sold me on Clojure (rather than Scala, the main
other contender) was the simplicity of the language itself and the low
ceremony build-process. To this end, I am absolutely *not* interested
in having to live inside a huge complex bit of machinery in order to
productively write programs. Eclipse and IntelliJ (and ilk) are
necessary for serious Java development mainly because they take the
implicit weight of Java applications. I would see it as a failing
(maybe too strong) if Clojure required either that much machinery.
So, for me, and I appreciate this is maybe unique, I want to go back
and basics and learn Clojure "properly". Getting Clojure installed in
my nice familiar Java IDE _might_ send the wrong, and very dangerous
message that Clojure is on a migration path from Java, when, to my
mind, it isn't. It is a completely different language, right down to
the fundamental build-deploy cycle.
I guess I am saying how much of IDE _whatever_'s functionality is
actually helpful in building Clojure applications? As I understand
it, large, deep nested packages (a sign of a nicely decomposed Java
system) probably isn't the right thing in Clojure. Refactoring
support probably isn't required as much because Clojure *seems* easier
to write the right thing first time.... I am being naive and
simplistic, but hopefully you get my point.
I absolutely get that saying "forget IDE _whatever_ and use Emacs"
isn't the right thing either, but I do think there is something good
about a message of "Clojure is a LISP, which have certain behaviours
of development, Emacs is designed for that very purpose and whilst you
can use IDE X, maybe you are trying to fit a square peg into a
ridiculously heavy and complex hole".
I too was pretty disillusioned when, after reading about the "purity"
of development with the REPL and the bliss that is LISP development in
emacs it turned out that after hours trying to get it all configured,
I still couldn't get it working.... A downloaded VM, or a vagrant/
puppet/chef/one line batch/sh script file orr windows (or statically
compiled tar.gz) executable would have made life much much simpler.
P.S> To be transparent, although I have written millions of LOC of
Java on trivial and large enterprise systems, I have written 3 lines
of Clojure code, along the lines of (+ 1 2 3). I have spent many
hours thinking about what solutions look like in a functional language
and have read 4 books on Clojure, so I am viewing this from afar.
James Keats
wouldn't mind teaching a lisp curriculum based on clojure that
wouldn't veer from the set path, and which test of learning are a set
of specific and circumscribed exercises. For people who come to learn
clojure though from the internet, they tend to be people who self-
teach, and who'll actually want to use it to do actual work. I am
skeptical about its ease for those. Either that, or all those
experienced programmers who still struggle with it despite their long
experience (I included) are just a bunch of pansies.
Sean Corfield
> - If you're new to programming, clojure will overwhelm you. Start with
> something like python.
Totally disagree. Lisps have been many people's first introduction to
programming over several decades and it works extremely well as an
introductory language. Very simple syntax, simply data structures,
consistent semantics. If you're new to programming, Lisps are just
about the simplest languages you can pick up.
Now, Clojure does require that a JVM is installed. So do any/all of
the JVM-based languages so I think that's really neither here nor
there. Installing a JVM is not a big deal.
All of the "ceremony" around the JVM is completely hidden by Leiningen
- no need to understand classpaths or Java runtime commands / options
and no need to deal with dependencies, other than adding them to
project.clj. So one simple download (the 'lein' script), one setup
command ('lein self-install' - ok, maybe you need to make lein
executable). Now you can hack Clojure with almost no ceremony: lein
repl and off you go. Want code in files? lein new scratch; cd scratch;
edit src/scratch/core.clj and off you go.
Read my blog post (written a year ago; updated several times to ensure
it works with newer versions of Clojure and Leiningen):
http://corfield.org/blog/post.cfm/getting-started-with-clojure
Now replace clojure.org/getting_started with something like that and I
think most of the complaints would go away. No one needs a fancy
editor / IDE setup to use Clojure - the key is just getting it
installed and then a REPL to experiment and a way to run Clojure
scripts easily from the command line.
That blog post has gotten a lot of people up and running - with
varying degrees of programming skills and varying degrees of Java/JVM
knowledge (from zero to expert in both areas).
nchubrich
> doesn't make it unnecessarily difficult to write and run code.
language, and it works great. It's better to teach people the right
way first, and the right way is Lisp. I'm really happy to hear you're
teaching Clojure. I hope everyone teaches Clojure soon. And (not to
sound like a broken record...) people learn programming by
programming----not by reading books while they try to configure their
environments.
As for an OS-Native Emacs, on Mac at least you have Aquamacs. All the
copy/paste/save/tab stuff works exactly as you would expect (and the
control-k control-a are OS-native anyway). I don't see much of a
learning curve there, although unfortunately the menu options are
still more Stallmanesque than Jobsian.
However, Aquamacs is difficult to get working with Clojure, Slime,
Swank, etc. I've managed to do it exactly once. (Some people have no
problems----they must be lucky.) I've finally concluded (taking Phil
Hagelberg's advice) that it's not really worth the trouble.
But Aquamacs might make a nice base for a packaged Mac Clojure
distribution. If someone could convince Aquamacs to put .emacs.d in
some non-home directory (beyond my emacs-fu at the moment) where it
doesn't interfere with any other Emacs and bundle it up with Lein and
all the good stuff, it might make a perfectly good Clojure IDE. As
for Windows and Linux, that's a whole other ball of wax....
It might be too heavyweight, but you could always also have people
create a "Clojure" user account----Mac makes switching those pretty
easy. There you would at least get a complete clean slate.
Jonathan Fischer Friberg
When it comes to IDEs, I agree. I write all code in vim (for editing only), and do the rest from the command line (meaning mostly leiningen). It felt a bit clunky at first, but I have grown to become very confident in that environment.
Jonathan
nchubrich
> it works with newer versions of Clojure and Leiningen):
> http://corfield.org/blog/post.cfm/getting-started-with-clojure
> Now replace clojure.org/getting_started with something like that and I
> think most of the complaints would go away.
be Lein and lein repl. If that one section on the Clojure.org website
were changed (it's been there for what----two years?) it would look so
much better to newcomers. Lein can at least get people up and
running, and give them time to play with Clojure while they figure out
IDEs.
Lee Spector
On Jul 8, 2011, at 1:24 PM, Michael Klishin wrote:
>
> what does gem --version output?
It was 1.3.5.
>
> To upgrade rubygems, use
>
> [sudo] gem update --system
Thanks so much. I've now successfully upgraded rubygems and completed the "sudo gem install vagrant" step without error.
I will take the next steps shortly.
Is this an okay place to make suggestions about the vagrant readme? In addition to adding "sudo" I would suggest adding an explicit step with links/instructions for installing or upgrading rubygems.
-Lee
Colin Yates
belly isn't McDonalds ;) I jest (obviously!), but I do think this is
a fundamental point. I (like a lot of others I expect) found Clojure
and Scala whilst looking for Java.next. I read a bit about Scala, and
part of its marketing is that there is no learning curve to start
writing Scala applications, due to Scala being a hybrid OO and
functional language.
On the other hand, the very first thing I started doing when thinking
"how do I wield this Clojure tool" was trying to see how I can use it
to make OO solutions. And the answer was painfully - *because I was
asking the wrong question*.
Clojure != Java - different paradigms, different mindsets, different
beasts. Trying to "write Java in Clojure" seems to be entirely the
wrong thing to do. "Write Java in Scala" is a recommended on-ramp to
integrating Scala in your organisation.
Clarifications:
I use "Java" to mean more than the language, I use it to mean the
typical shape of implemented solutions using the Java programming
language, i.e. OO with anaemic domain models and a fair chunk of XML
and/or annotations.
I keep mentioning Scala because this whole thread seems to be about
"newbie experience" (where newbie is in reference only to Clojure) and
I suspect most newbies will be thinking about Scala as well.
On Jul 8, 7:15 pm, Jonathan Fischer Friberg <odysso...@gmail.com>
wrote:
> different than java. If it weren't for java, clojure wouldn't have much use
> at all.
> > and Clojure. Sure, they run on the JVM, but that is their *only*
> > relationship (from a consumer's point of view) as far as I can see.
>
> > For me, after a decade+ of developing Enterprise Java (primarily web)
> > applications I am sick and tired of all the hoops and ceremony
> > involved in building Java applications. More and more I am coming
> > (from reading other people's work - not my own discovery!) to realise
> > that most established "best-practice" is only required to answer an
> > insufficiency in the language itself.