I was watching "Pleasantville" again and it reminded me of this whole
argument.
On Mon, Dec 21, 2009 at 6:39 PM, Joost wrote:
> On 21 dec, 15:38, kyle smith wrote:
> > Martin, you're trying to argue that some hypothetical 'unwashed
> > masses' of programmers won't like clojure because of parent
On 21 dec, 15:38, kyle smith wrote:
> Martin, you're trying to argue that some hypothetical 'unwashed
> masses' of programmers won't like clojure because of parenthesis. The
> problem is you're just assuming it's the parenthesis, and there is no
> way to know for sure (short of a peer-reviewed st
Martin, you're trying to argue that some hypothetical 'unwashed
masses' of programmers won't like clojure because of parenthesis. The
problem is you're just assuming it's the parenthesis, and there is no
way to know for sure (short of a peer-reviewed study). Maybe java
programmers don't know abou
On 20 Dec 2009, at 19:30, Luc Préfontaine wrote:
> That's a concise and clear way to summarize the issue.
>
> If you compare the IDE support required for different languages, the support
> required to write syntactically correct Clojure code is pretty small compared
> to others.
I like Clojur
I do have one but it still has some grey in it :)
On Sun, 2009-12-20 at 19:41 -0500, Wilson MacGyver wrote:
> John McCarthy the creator of lisp does have beard. :)
>
> http://www-formal.stanford.edu/jmc/personal.html
>
> On Sun, Dec 20, 2009 at 7:37 PM, David Nolen wrote:
> > On Sun, Dec 20,
Martin Coxall writes:
> For each line that is not within a vector, and does not have an
> opening parenthesis, infer an opening parenthesis at the start of the
> line. Remember the level of indentation, and infer a closing
> parenthesis at the end of the line *before* the next line whose
> indent
John McCarthy the creator of lisp does have beard. :)
http://www-formal.stanford.edu/jmc/personal.html
On Sun, Dec 20, 2009 at 7:37 PM, David Nolen wrote:
> On Sun, Dec 20, 2009 at 5:48 PM, Luc Préfontaine
> wrote:
>>
>> :))
>
> The Lisp Beard?
>
>>
>> Luc
>>
>> On Sun, 2009-12-
On Sun, Dec 20, 2009 at 5:48 PM, Luc Préfontaine <
lprefonta...@softaddicts.ca> wrote:
> :))
>
The Lisp Beard?
>
> Luc
>
>
> On Sun, 2009-12-20 at 15:00 -0800, David Brown wrote:
>
> On Sun, Dec 20, 2009 at 02:30:58PM -0500, Luc Préfontaine wrote:
>
> >People bought HP calculat
:))
Luc
On Sun, 2009-12-20 at 15:00 -0800, David Brown wrote:
> On Sun, Dec 20, 2009 at 02:30:58PM -0500, Luc Préfontaine wrote:
>
> >People bought HP calculators not for the Postfix notation but for all
> >the others things it offered at the time...
>
> Some of us _still_ only
On Sun, Dec 20, 2009 at 02:30:58PM -0500, Luc Préfontaine wrote:
>People bought HP calculators not for the Postfix notation but for all
>the others things it offered at the time...
Some of us _still_ only buy HP calculators because of the postfix
notation. Oh, the other things are nice, too.
Da
Seeing this is becoming such a popular thread I cannot help but chime
in with a little thought of my own: When you read code you are a human
compiler. Your brain needs to do the same job as a compiler to figure
out how the program works. The human compiler must identify structure
to be able to unde
2009/12/20 Alex Osborne
> Phil Hagelberg writes:
> > "Alex Osborne" writes:
>
> >> But this is the same "great idea" that everyone who's ever used a lisp
> >> since the dawn of programming has come up with and despite numerous
> >> attempts, to my knowledge not a single one of them has ever tak
Peace, brother.
And btw, who are you to tell others what they ought to do or not to do ?
Regards,
--
Laurent
2009/12/20 Charras
> can't believe, you guys, WAIST! your time discussing about
> parentheses. There are far more interesting things to discuss. Please
> don't waist time (time is li
That's a concise and clear way to summarize the issue.
If you compare the IDE support required for different languages, the
support required to write syntactically correct Clojure code is pretty
small compared to others.
I do not get it, it's longer and much more painful to write Java code
with a
At 12:09 PM 12/20/2009, Richard Newman wrote:
>[...]
>I think most of the active Clojure community ranges from not caring to
>genuinely liking s-expression notation,
And all the way to disliking the replacement of many parens
with square brackets in the syntax. That's why I, a pendant
who prio
> can't you understand the reactions? The Lisp-people have been through
> this discussion for what? 20 years, 30 years, 40 years? And it comes
> up in intervalls which feel like once a month (don't nail me down on
> the numbers). Go to comp.lang.lisp and do a search for it. Really.
> There is n
Hi,
On 20 Dez., 18:41, Martin Coxall wrote:
> On 20/12/2009 5:39 PM, Richard Newman wrote:
>
> >> It's better if we can support both. It's never one size fits all.
>
> > Who is "we"?
>
> > If you're talking about something *you* want, you can go build it
>
> I see Clojure is well on the way to bu
Martin,
> I see Clojure is well on the way to building a community at least as
> repellingly exclusionary as all the other Lisps nobody uses.
Thanks for the thinly veiled jab.
I've worked on a bunch of libraries, answered a bunch of questions on
the mailing list, and attended a few meetups. I
On 20/12/2009 5:39 PM, Richard Newman wrote:
>> It's better if we can support both. It's never one size fits all.
>
> Who is "we"?
>
> If you're talking about something *you* want, you can go build it…
>
I see Clojure is well on the way to building a community at least as
repellingly exclusionary
> It's better if we can support both. It's never one size fits all.
Who is "we"?
If you're talking about something *you* want, you can go build it…
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegr
It's better if we can support both. It's never one size fits all.
On Sun, Dec 20, 2009 at 11:49 AM, Sean Devlin wrote:
> Alex,
>
> I just thought of something. I think we're all forgetting the amount
> of hacking done at the REPL.
>
> ;This is easy to type
> user=>(from (too (many (parens
>
Alex,
I just thought of something. I think we're all forgetting the amount
of hacking done at the REPL.
;This is easy to type
user=>(from (too (many (parens
;Uh-oh
user=>to
too
many
nesting
levels?
This might be an area where the parens are a win.
Sean
On Dec 20, 10:0
I have been studying Clojure for 3 months. My experience:
* After knowing about Lisp coding style and indents: parens
disappeared
* After knowing about reading from inside to outside: Clojure code is
more understandable (http://groups.google.com/group/clojure/
browse_thread/thread/144142dcb5586292/
Martin Coxall writes:
> I might try to knock up "optional parens inference for Clojure" and
> add in some manner of curly infix as an exercise. It doesn't look like
> it will be too hard. Since {} is taken for literal maps, I'd need
> something else for curly infix. [|...|], %...%, $...$?
Let's
On 20 Dec 2009, at 06:51, ajay gopalakrishnan wrote:
> Yes, Martin, please give it a try. Only then can we know if the parenthesis
> is real issue or not. There is no point arguing about it. The only
> disadvantage is that, over time, people will forget that it is actually a
> list. But, hey,
On 20 Dec 2009, at 07:27, ajay gopalakrishnan wrote:
> Precedence is an overrated thing. You dont run into that issue every day.
Yeah, only every time you write a simple mathematical expression. And how often
does that happen when you're programming?!
Martin
--
You received this message bec
>
>
>
> As for Ten parentheses, i do not see a single one. Noone notices
> starting parens because they are markers saying "this is a function".
> And of course noone notices ending parens because they are for your
> IDE, not for the human.
This is I like, I'd never thought about S-exprs this
I may be way off here and if I am feel free to flame!
isn't it true that lisp being an AST transfers the overhead of parsing to
humans ?
Let me restate that: lisp manages to skip a step that other languages do,
i.e. parsing the language to AST ?
I understand that it gives you great power but at th
Precedence is an overrated thing. You dont run into that issue every day.
When we do we have the support of (). So, a developer must have the option
to disambiguate it when necessary, but otherwise should not have to type the
otherwise redundant () all the time. (All this talk is about arithmetic
e
ajay gopalakrishnan writes:
> If possible, I would also want to see a macro that allows me to write (x < y)
> instead of (< x y).
Here's Chouser's infix function, which he apparently has never used
since writing it:
http://paste.lisp.org/display/75230
> (+ x y) can be read literally as "add
> (< x y) how do you read this literally left-to-right?
I've been writing Common Lisp and Clojure for about 6 years now, and I
read that "less-than x y" without any confusion.
I have almost no problems with prefix notation; even arithmetic (which
I was taught in infix for years) rarely trips
Yes, Martin, please give it a try. Only then can we know if the parenthesis
is real issue or not. There is no point arguing about it. The only
disadvantage is that, over time, people will forget that it is actually a
list. But, hey, if it does not prevent us from writing efficient and correct
code
> Is it possible that people are confusing their inability to comprehend
> deeply nested function calls (no offense intended by that - I hit this
> often myself) with the strangeness of the perens? I think what others
> have said about having to think more about each line of Clojure is
> true. It
Give it a shot. Hack up a prototype. Let's see what happens.
On Dec 20, 12:07 am, "Alex Osborne" wrote:
> Phil Hagelberg writes:
> > "Alex Osborne" writes:
> >> But this is the same "great idea" that everyone who's ever used a lisp
> >> since the dawn of programming has come up with and despi
Phil Hagelberg writes:
> "Alex Osborne" writes:
>> But this is the same "great idea" that everyone who's ever used a lisp
>> since the dawn of programming has come up with and despite numerous
>> attempts, to my knowledge not a single one of them has ever taken off.
>
> You're forgetting about D
Is it possible that people are confusing their inability to comprehend
deeply nested function calls (no offense intended by that - I hit this
often myself) with the strangeness of the perens? I think what others
have said about having to think more about each line of Clojure is
true. It is more e
On Sat, 19 Dec 2009 14:22:22 +
Martin Coxall wrote:
> On 19 Dec 2009, at 13:50, Stefan Kamphausen wrote:
> > * Reason. They could have been taken away in more than 50 years of
> > history. Guess what, they are still there.
> Guess what? NOBODY uses Lisp. Because of those parens.
You've over
I think this discussion is getting too long, but anyway ..
Coming from an imperative background, especially Java which is a lot
bloated, when I tried to read Lisp code, I start to get the feeling that I
am staring at the same place for a long time. In an imperative setting, it
definitely means tha
can't believe, you guys, WAIST! your time discussing about
parentheses. There are far more interesting things to discuss. Please
don't waist time (time is life, is all we have) in that, and
specially, this is a public group, where knowledge should be share,
not nonsense discussions.
If somebody l
"Alex Osborne" writes:
>> But I'm trying to think of it from the point of view of Joe Q. Coder,
>> who will take one look at our beloved elegant, expressive Clojure, see
>> all the parens and run screaming.
> But this is the same "great idea" that everyone who's ever used a lisp
> since the dawn
Martin Coxall writes:
> I trust the many, many more people that have rejected Lisp for its
> hostile syntax and delusions of importance than the statistically
> insignificant minority who have actually stuck with it.
Sometimes people are just looking for excuse to criticize. Before it
was cons
On 19 dec, 15:25, Martin Coxall wrote:
> > I guess it's mostly a matter of judging a language by its long-term
> > merits instead of initial appearance -- just like with so many other
> > things in life.
>
> That - right there - is a tacit admission that the Clojure community will
> find it activ
Well, good thing you repented of your evil ways
On Dec 19, 3:37 pm, Stuart Sierra wrote:
> On Dec 18, 9:28 pm, Sean Devlin wrote:
>
> > It is proudly a Lisp for people that want to get things done. Any
> > Java/.NET/Python/Brainfuck/Ruby/Basic/C/C++ (No Perlmongers :))
>
> I was a Perlmonge
On Dec 18, 9:28 pm, Sean Devlin wrote:
> It is proudly a Lisp for people that want to get things done. Any
> Java/.NET/Python/Brainfuck/Ruby/Basic/C/C++ (No Perlmongers :))
I was a Perlmonger back in the day. :)
-SS
--
You received this message because you are subscribed to the Google
Groups
On Sat, Dec 19, 2009 at 9:21 AM, David Nolen wrote:
> I don't think anybody in the Clojure community wants to Clojure to be a
> fringe language.
Actually, I don't mind if Clojure retains a certain degree of "fringe" status.
To clarify, I think the ideal size for a language community is
somewhere
The intended audience are Software Engineers. Not the people who hide
behind "this-is-not-intuitive" their lack of willing to learn the most
effective way to spend their professional life.
Why is it that you believe them to be mutually exclusive events? You portray
Software engineers as if they ar
Oops.. left two parentheses out in my Java code. Guess that just furthers my
point. :)
> List newObjects = ArrayList();
On Dec 19, 2009, at 12:04 PM, Joseph Smith wrote:
> Very abstract java example (as concise as possible):
>
> List processList(List oldObjects)
> {
>List newObjects
Very abstract java example (as concise as possible):
List processList(List oldObjects)
{
List newObjects = ArrayList;
for(Object object : oldObjects)
{
newObjects.add(manipulate(object));
}
return newObjects;
}
Clojure equivalent:
(defn processList [#^Object list]
Martin,
I was short with you yesterday. I'm sorry about that. Please let me
try again.
I'm all for providing better documentation, eliminating bad design,
and holding hands as people get up to speed. As a community, we
constantly need to do more work to make it accessible. That's the
point of
On Sat, Dec 19, 2009 at 8:25 AM, Martin Coxall wrote:
> >
> > I guess it's mostly a matter of judging a language by its long-term
> > merits instead of initial appearance -- just like with so many other
> > things in life.
> >
>
> That - right there - is a tacit admission that the Clojure communi
>
> I guess it's mostly a matter of judging a language by its long-term
> merits instead of initial appearance -- just like with so many other
> things in life.
>
That - right there - is a tacit admission that the Clojure community will find
it actively desirable that it remain a minority langu
On 19 Dec 2009, at 13:50, Stefan Kamphausen wrote:
> Hi,
>
> On 18 Dez., 20:07, Martin Coxall wrote:
>> One of the things that always puts people off of Lisp, as we all know, are
>> the parentheses.
>
> one of the things that always put Lispers off is this same question.
>
> I have three arg
>
>
> It is proudly a Lisp for people that want to get things done. Any
> Java/.NET/Python/Brainfuck/Ruby/Basic/C/C++ (No Perlmongers :)) that
> want to get better are welcome. However, there is a way things are
> done in the language, driven by the underlying problems reality
> imposes on deve
pply merge-with +
> pmap count-lines
> partition-all *batch-size*
> line-seq (reader filename)
>
>
> With a startling two parentheses and Rich's corrected version into:
>
> ->>
> line-seq (reader filename)
> par
gt; With a startling two parentheses and Rich's corrected version into:
>
> ->>
> line-seq (reader filename)
> partition-all *batch-size*
> pmap count-lines
> apply merge-with +
>
> Also with two. That last example in particular looks splendidly readab
Hi,
On 18 Dez., 20:07, Martin Coxall wrote:
> One of the things that always puts people off of Lisp, as we all know, are
> the parentheses.
one of the things that always put Lispers off is this same question.
I have three arguments to make. Love, reason and trust.
* Love. Parentheses are an
It's certainly something I would like to add to counterclockwise.
If only paredit's code was written in clojure, it could have been more
easily reused by enclojure, La Clojure and counterclockwise ! :-(
2009/12/19 Avital Oliver
> It seems that noone has brought up the amazing paredit mode for
It seems that noone has brought up the amazing paredit mode for emacs which
gives you keyboard commands for s-expression structure manipulation. It also
makes sure you never get your close parenthesis wrong. I use it and can't
imagine writing any medium+-complexity code without it.
On Dec 19, 2009
Hi,
I've a different take on the entire thing. Based on my experience I have
realized the following:
1. A lot of software engineers do not have a CS background. Out of them,
many joined this field for the fun of coding and are willing to learn new
things. I know many like that. However,
Anniepoo writes:
> What's hostile to most programmers is that Clojure demands a lot more
> thinking per line of code. I remember when OO came in, and then when
> design patterns came in - each decreased the amount of thinking about
> code and increased the amount of typing.
*shudder* Yes, this
Many/most of the best programmers I know have allergic reactions to
parens. I think this is a normal reaction based on the amount of
successful time they have spent with ; terminated languages. FWIW, I
certainly flinch when I see Objective-C code with [ ] in strange
places, although these other pro
Look, your IDE won't be a good clojure environment, because it will
encourage sloppy thinking. Write some more macros, and learn to
appreciate that you are building data structures. Really.
G
On Dec 18, 9:37 pm, Anniepoo wrote:
> I read this and think of Roedy Green's essay on source
Martin Coxall writes:
> My question is this: why can't we introduce a simple and importantly,
> optional 'off-side rule' (much simpler than Haskell's) that allows the
> reader to infer many of the parentheses?
If you haven't seen them before, check out sweet expressions. This guy
has put a lot
I read this and think of Roedy Green's essay on source code in
database, http://mindprod.com/project/scid.html and on Knuth's
'literate programming' - the idea that source code is inherently not
it's representation (it's the reader output that's homoiconic, not the
file representation on disk) a
Look, Clojure does a lot to make life easier. But if Joe Q. Coder
isn't willing to *try* to work with parens, he won't have a chance
picking up Clojure.
It is proudly a Lisp for people that want to get things done. Any
Java/.NET/Python/Brainfuck/Ruby/Basic/C/C++ (No Perlmongers :)) that
want to
On Dec 18, 4:59 pm, Martin Coxall wrote:
> But I'm trying to think of it from the point of view of Joe Q. Coder, who
> will take one look at our beloved elegant, expressive Clojure, see all the
> parens and run screaming.
Let James Gosling worry about Joe Q. Coder. He does a very good job at
th
On 19 Dec 2009, at 00:53, Sean Devlin wrote:
> What you're looking for is called "Python".
>
> The parens are your friend. Learn to love them. They are there to
> remind you that you're building a data structure, not just writing
> code.
>
> Sean
>
As it happens, I agree with you: I learned
On Fri, 18 Dec 2009 19:07:43 +
Martin Coxall wrote:
> For each line that is not within a vector, and does not have an opening
> parenthesis, infer an opening parenthesis at the start of the line. Remember
> the level of indentation, and infer a closing parenthesis at the end of the
> line
On 19 Dec 2009, at 00:29, Mark Engelberg wrote:
> The main downside of such an approach is that if you copy and paste
> your code to a new context in which it has a different level of
> indenting, it's very easy to screw things up. You then have no way to
> re-indent the code without fully analy
Welcome to the big club of people who in last 50 years came up with a
"brilliant" idea to "fix" lisp.
As for Ten parentheses, i do not see a single one. Noone notices
starting parens because they are markers saying "this is a function".
And of course noone notices ending parens because they are fo
In my personal experience, the fastest way to get accustomed to the
parenthesis is to learn how to read the indentation. That was the
biggest hurdle for me coming from reading C/Java code. Lisp
indentation is quite expressive and a little more subtle (unlike the
indent-two-spaces-for-a-loop scheme
> ->>
> line-seq (reader filename)
> partition-all *batch-size*
> pmap count-lines
> apply merge-with +
>
> Also with two. That last example in particular looks splendidly readable.
> Almost... monadic.
>
> The parenthesis inference here is very simple
The main downside of such an approach is that if you copy and paste
your code to a new context in which it has a different level of
indenting, it's very easy to screw things up. You then have no way to
re-indent the code without fully analyzing and understanding the
*semantics* of the code, becaus
line-seq (reader filename)
With a startling two parentheses and Rich's corrected version into:
->>
line-seq (reader filename)
partition-all *batch-size*
pmap count-lines
apply merge-with +
Also with two. That last example in particular looks splendidly readable.
Almost.
74 matches
Mail list logo
