I had this thought at work, when I should have been working, so please bear with me if it's nonsense.
One of the things that always puts people off of Lisp, as we all know, are the parentheses. Now, many ways have been suggested of doing this in other Lisps, but have never taken off, mainly due to inertia and a fear of sacrificing homoiconicity.
However, I love Clojure, and want to see it really take off. And so I want to see all barriers to that removed. Also, I think the language is young enough that seemingly-but-not-really radical proposals can still be sneaked in.
Let's take this example, since I note that Rich Hickey weighed in in the comments:
This little snippet has ten parentheses. And is potentially very unnerving to a non-lisper. Ten parentheses in four lines seems a lot to most programmers.
Rich, in the comments, suggests a pipelined style to make the code more readable:
I accept that this is more readable because it has less nesting. But it now has *12* parentheses, more than the original, potentially just as alarming to the Lispophobes.
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?
A very simple offside rule could turn the original into:
Also with two. That last example in particular looks splendidly readable. Almost... monadic.
The parenthesis inference here is very simple, and could be stated in two sentences:
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 indentation is the same as or less than the remembered one.
My question is: why would such a scheme work/not work, and why would/would not it be desirable?
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, because the only syntactic cues (the whitespace) is now invalid and can't be trusted.
Lispers tend to like the fact that the parentheses can be used by the computer to auto-format and auto-indent your code, and parens help ensure that everything is grouped correctly (e.g., when you put your cursor over a paren, it shows you the other paren that goes with it) -- then once it is formatted, they use the indenting levels to understand their code and ignore the parentheses. But it's comforting to know the parentheses are there should the code ever get moved around or edited.
On Fri, Dec 18, 2009 at 11:07 AM, Martin Coxall <pseudo.m...@me.com> wrote: > My question is: why would such a scheme work/not work, and why would/would not it be desirable?
> I had this thought at work, when I should have been working, so please bear with me if it's nonsense.
> One of the things that always puts people off of Lisp, as we all know, are the parentheses. Now, many ways have been suggested of doing this in other Lisps, but have never taken off, mainly due to inertia and a fear of sacrificing homoiconicity.
> However, I love Clojure, and want to see it really take off. And so I want to see all barriers to that removed. Also, I think the language is young enough that seemingly-but-not-really radical proposals can still be sneaked in.
> Let's take this example, since I note that Rich Hickey weighed in in the comments:
> This little snippet has ten parentheses. And is potentially very unnerving to a non-lisper. Ten parentheses in four lines seems a lot to most programmers.
> Rich, in the comments, suggests a pipelined style to make the code more readable:
> I accept that this is more readable because it has less nesting. But it now has *12* parentheses, more than the original, potentially just as alarming to the Lispophobes.
> 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?
> A very simple offside rule could turn the original into:
> Also with two. That last example in particular looks splendidly readable. Almost... monadic.
> The parenthesis inference here is very simple, and could be stated in two sentences:
> 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 indentation is the same as or less than the remembered one.
> My question is: why would such a scheme work/not work, and why would/would not it be desirable?
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 in C/Java). I think this point is maybe not stressed enough. No one can actually read lisp code by counting parentheses in their head. -Patrick
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 for your IDE, not for the human.
> 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, because the only syntactic cues (the > whitespace) is now invalid and can't be trusted.
My general feeling is that it's bad form to make sensitive whitespace the *only* option (I'm looking at you, Python).
What I'm wondering is whether there's any harm in making it available as an option, and whether it makes sense as a default. Haskell answered yes to both these questions, and what it gains Haskell in readability is well worth the tradeoff.
However, I agree that fully-parenthesized syntax should always be available to those that want it. But I assume that it's Rich's plan that Clojure should be more accessible than to just Lisp-heads, and a less parenthesized syntax might go a long way to easing their jitters.
Martin Coxall <pseudo.m...@me.com> 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 *before* the next line whose indentation is the same as or less than the remembered one.
> My question is: why would such a scheme work/not work, and why would/would not it be desirable?
Congratulations, you've just (re-invented) ABC & Python.
It can work. It's very comfortable to write, as it cuts down on a lot of the syntactic noise in a program.
Downsides:
- Breaking the formatting of code beaks the meaning. - Cutting and pasting inside a program becomes more interesting. It can be done - emacs can rigidly indent a region that's been pasted to the right place - but you can't really fix it "by hand" later. - The size of tabs suddenly *matters*.
And the biggie:
- A lot of people find this significant whitespace as off-putting as the parenthesis in LISP. Not as many, but still a significant number.
> 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 to stop noticing the parens a long time ago, and think that Clojure's rather pragmatic approach to parens-reduction (lambda/vector literals) and other syntactic conveniences (object invocation syntax, comma whitespace) strikes a good balance.
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.
Many people find would Clojure's comparative lack of syntax very human-hostile. Who is the intended audience of Clojure? Is it other Lispers? Or other Java programmers?
On Dec 18, 4:59 pm, Martin Coxall <pseudo.m...@me.com> 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 that. Do you think HP worries that soccer moms will not use their Engineering Calculators ?
> Who is the intended audience of Clojure? Is it other Lispers? Or other Java programmers?
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.
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 get better are welcome. However, there is a way things are done in the language, driven by the underlying problems reality imposes on developers. A prospective Clojure developer must accept that the language does this to help you, not hurt you, and they need to be open to the ideas.
That is the intended audience.
Sean
On Dec 18, 7:59 pm, Martin Coxall <pseudo.m...@me.com> wrote:
> > 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 to stop noticing the parens a long time ago, and think that Clojure's rather pragmatic approach to parens-reduction (lambda/vector literals) and other syntactic conveniences (object invocation syntax, comma whitespace) strikes a good balance.
> 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.
> Many people find would Clojure's comparative lack of syntax very human-hostile. Who is the intended audience of Clojure? Is it other Lispers? Or other Java programmers?
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) and that there might be several representations. Reading Roedy Green's essay I think of how obsolete it sounds after refactoring IDE's came around. Let me suggest that this is a great idea, but one that should be part of some clojure-centric IDE, not a part of the language.
It seems barking up the wrong tree to think that clojure will find more acceptance if we find some method of reducing the number of parens involved. 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. After all, the same java programmers who are frightened by Clojure are happily reading nested structures in XML all the time.
Martin Coxall <pseudo.m...@me.com> 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 of thought and experimentation into it.
Coming from a background in Python and Ruby, I found S-expressions initially very hard to read and would probably have loved something like this. However I pretty soon got used to the Lisp syntax and now I actually prefer it. If I did use something like sweet-expressions as "training wheels", I'd probably have stuck with them and then never have learned to read other people's code and never discovered the joy of paredit and SLIME.
It's possible to use paredit with other languages, but it doesn't seem to work as well due to the lack of consistency. Similarly, I have tried a couple of SLIME-like things for Ruby and Python but they never worked quite as well as you have to resort to manually selecting everything you want to eval, instead of just being able to say "eval last expression". I guess in theory it should be possible to make this work with an infix/whitespace-sensitive syntax but the amount of extra effort involved must discourage implementation efforts.
I agree with Anniepoo, if you really want to do something like this it's probably better done in the editor rather than the language itsel. By putting it in the editor, you're retaining the simplicity in the actual source-code, plus any file you open will be in your preferred syntax and when you give your code to other people it will be in their preferred syntax.
In fact it looks like there's already an Emacs mode for doing it on a read-only basis:
I have at some point seen a mode that makes them invisible for editing as well and uses whitespace and highlighting to indicate nesting, but I can't find it now.
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.
Grrrr....
On Dec 18, 9:37 pm, Anniepoo <annie6...@yahoo.com> wrote:
> I read this and think of Roedy Green's essay on source code in > database,http://mindprod.com/project/scid.htmland 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) and that there might be several > representations. > Reading Roedy Green's essay I think of how obsolete it sounds after > refactoring IDE's came around. Let me suggest that this is a great > idea, but one that should be part of some clojure-centric IDE, not a > part of the language.
> It seems barking up the wrong tree to think that clojure will find > more acceptance if we find some method of reducing the number of > parens involved. > 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. > After all, the same java programmers who are frightened by Clojure are > happily reading nested structures in XML all the time.
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 programmers do not.
I'd like to think that forgetting about operator precedence and enabling things like (< 1 2 3 4) are the first step to appreciating list oriented mental parsing.
I don't hope Clojure ever becomes a lowest common denominator language. There will always be a stream of competitors for that title, like VB and Java. But I do hope that Clojure becomes widely known enough to build a reputation for terse, fast, concurrency-friendly code with a fair amount of punctuation. Remember, the punctuation threshold for "hello, world" in Java is {([]){();}}
On Dec 18, 7:59 pm, Martin Coxall <pseudo.m...@me.com> wrote:
> > 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 to stop noticing the parens a long time ago, and think that Clojure's rather pragmatic approach to parens-reduction (lambda/vector literals) and other syntactic conveniences (object invocation syntax, comma whitespace) strikes a good balance.
> 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.
> Many people find would Clojure's comparative lack of syntax very human-hostile. Who is the intended audience of Clojure? Is it other Lispers? Or other Java programmers?
Anniepoo <annie6...@yahoo.com> 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 is a seriously disturbing trend in some languages. While each line is doing less there's an awful lot more of them. I guess this is another good example of "apparent simplicity" with "real complexity".
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, I feel a large majority of them are those for whom Java is probably what Software development basically is. (This has been a boon and bane of Computer Science. It reduces the barrier to entry, but also prevents them from appreciating the true beauty. Many can code a web application, thanks to Rails, Hibernate and the like without even having an idea of what B-tree is) Everything begins and ends with Java. They don't even know anything about C/C++. And I think it would be foolish to assume that Clojure acceptance will reach critical mass unless it is accepted by this group of people. 2. Second issue is Bosses (higher-ups) and convincing them is hard. Language features and the beauty of Lisp is not going to convince them. The biggest problem is I think when they realize that they will have to loose all the Imperative programming skills they have acquired all over these years and now they will be on equal footing with the rest when it comes to Functional programming experience. 3. Sad as it is, most of the work gets done by Copy-paste work and unless there is a online cookbook type thing, people will find it hard.
Unless Clojure (not just Clojure, any functional programming language) reduces this barrier to entry for both the non-core developers and the Bosses, I think any FP language will find it hard. Now, if we want Clojure to get accepted fast, I think we must be eager to reduce this barrier to entry. Just saying that "If you can program in LISP" then you can code Clojure is not a very smart answer. Similarly saying "get used to parenthesis" is not a smart answer either.
*It's really wrong to think that if they do not accept Clojure they are doomed. The users have a higher hand and if not Clojure, new languages will keep on being built until some language gets accepted by all. *
I think what needs to be done is the following:
1. In LISP like languages, Parenthesis is a non-issue as long as code is properly indented. And hence *strictly following indenting rules* while defining functions/Macros etc. is really really crucial. Hence my next point. 2. Excellent IDE indenting support for code Indentation. I have tried Enclojure and it is good. But what I find is difficult for the LISP newbie is deciding when to put code on the new line for function arguments and all that. I know that there are rules for that (most Scheme like), but frankly speaking, people have become very lazy and wouldn't waste time reading the indenting rules, especially when the other Haskell,F#, Scala camp boasts to address the same issues and say that we do it all without a lot of parenthesis. *So in short, Can we do something in the IDE to make Clojure code indentation a totally no-brainer?* Perhaps Enclojure must show some *placeholders* properly indented based on whether it is defmacro, defn or fn etc and the developer just fills it up. This would be an excellent aid in promoting LISP indenting standards. Overtime, once Clojure is widespread people will automatically start doing it correctly. 3. A nice and good article written by Clojure folks that highlights how to transition from the OOPS thinking to Functional thinking. 1. Just saying "Practice coding recursively" does not help at all. Even core CS people do not use recursion for every thing these days. Students have OS labs, Networking Labs and projects but everyone knows that it does not involve much of recursion and all - just a plain sequence of operations, that's all. At most 2-3 courses on Algorithms is where they use Recursion heavily. 2. I think the keyword "let" and the pipeline is very understated. "let" is the single most important thing that makes this transition easy. 4. Have an article that has some decent functions in it and each should have an explanation of how an experienced Clojurian/LISPian would read this code mentally. Just write it as a transcript. Or may be a Screen cast. 5. Have a cookbook like article for all common tasks. 6. Explain how idiomatic code looks like in Clojure. I feel experienced Lispers can help in this. It feels very scary when an experienced OOPS developer knowing all idiomatic code in OOPS does not know anything in LISP. I'm afraid to say that this feeling of shame must be prevented. After all, writing idiomatic LISP code is not rocket science. It is just lack of experience
*I personally feel that Clojure has enough of nice features.* All that is left to do is to make the transition easier. Although it may seem less technical and less interesting to the geeks, it is important to realize that all coders are not geeks and not everybody behaves rationally. Looks, presentation and ability to lure people also matters. After all, looks and ease in *every* way is an integral part of a Programming Language.
Finally, comments like "doing XYZ will encourage them to write sloppy code" is not good. Nobody likes to write sloppy code. They do it because writing good code is very hard in the language or the IDE does not support it.
A language need not be very good to be a success. A lot depends on the IDE support. It is known to everybody that most of the Java code is written in IDE like Eclipse only. And Eclipse goes a long way in reducing the boilerplate code, thus reducing a flaw in the Java language. Similarly Enclojure and Counterclockwise support be just splendid. Just saying "use Slime/Vimclojure" does not help again.
My 5 cents. it is too long for 2 cents.
Thanks, Ajay G
On Fri, Dec 18, 2009 at 9:28 PM, Sean Devlin <francoisdev...@gmail.com>wrote:
> 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 get better are welcome. However, there is a way things are > done in the language, driven by the underlying problems reality > imposes on developers. A prospective Clojure developer must accept > that the language does this to help you, not hurt you, and they need > to be open to the ideas.
> That is the intended audience.
> Sean
> On Dec 18, 7:59 pm, Martin Coxall <pseudo.m...@me.com> wrote: > > 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 to stop noticing the parens a > long time ago, and think that Clojure's rather pragmatic approach to > parens-reduction (lambda/vector literals) and other syntactic conveniences > (object invocation syntax, comma whitespace) strikes a good balance.
> > 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.
> > Many people find would Clojure's comparative lack of syntax very > human-hostile. Who is the intended audience of Clojure? Is it other Lispers? > Or other Java programmers?
> > Martin
> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@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+unsubscribe@googlegroups.com<clojure%2Bunsubscribe@googlegroups.com > > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
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 6:11 AM, "ajay gopalakrishnan" <ajgop...@gmail.com> wrote:
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, I feel a large majority of them are those for whom Java is probably what Software development basically is. (This has been a boon and bane of Computer Science. It reduces the barrier to entry, but also prevents them from appreciating the true beauty. Many can code a web application, thanks to Rails, Hibernate and the like without even having an idea of what B-tree is) Everything begins and ends with Java. They don't even know anything about C/C++. And I think it would be foolish to assume that Clojure acceptance will reach critical mass unless it is accepted by this group of people. 2. Second issue is Bosses (higher-ups) and convincing them is hard. Language features and the beauty of Lisp is not going to convince them. The biggest problem is I think when they realize that they will have to loose all the Imperative programming skills they have acquired all over these years and now they will be on equal footing with the rest when it comes to Functional programming experience. 3. Sad as it is, most of the work gets done by Copy-paste work and unless there is a online cookbook type thing, people will find it hard.
Unless Clojure (not just Clojure, any functional programming language) reduces this barrier to entry for both the non-core developers and the Bosses, I think any FP language will find it hard. Now, if we want Clojure to get accepted fast, I think we must be eager to reduce this barrier to entry. Just saying that "If you can program in LISP" then you can code Clojure is not a very smart answer. Similarly saying "get used to parenthesis" is not a smart answer either.
*It's really wrong to think that if they do not accept Clojure they are doomed. The users have a higher hand and if not Clojure, new languages will keep on being built until some language gets accepted by all. *
I think what needs to be done is the following:
1. In LISP like languages, Parenthesis is a non-issue as long as code is properly indented. And hence *strictly following indenting rules* while defining functions/Macros etc. is really really crucial. Hence my next point. 2. Excellent IDE indenting support for code Indentation. I have tried Enclojure and it is good. But what I find is difficult for the LISP newbie is deciding when to put code on the new line for function arguments and all that. I know that there are rules for that (most Scheme like), but frankly speaking, people have become very lazy and wouldn't waste time reading the indenting rules, especially when the other Haskell,F#, Scala camp boasts to address the same issues and say that we do it all without a lot of parenthesis. *So in short, Can we do something in the IDE to make Clojure code indentation a totally no-brainer?* Perhaps Enclojure must show some *placeholders* properly indented based on whether it is defmacro, defn or fn etc and the developer just fills it up. This would be an excellent aid in promoting LISP indenting standards. Overtime, once Clojure is widespread people will automatically start doing it correctly. 3. A nice and good article written by Clojure folks that highlights how to transition from the OOPS thinking to Functional thinking. 1. Just saying "Practice coding recursively" does not help at all. Even core CS people do not use recursion for every thing these days. Students have OS labs, Networking Labs and projects but everyone knows that it does not involve much of recursion and all - just a plain sequence of operations, that's all. At most 2-3 courses on Algorithms is where they use Recursion heavily. 2. I think the keyword "let" and the pipeline is very understated. "let" is the single most important thing that makes this transition easy. 4. Have an article that has some decent functions in it and each should have an explanation of how an experienced Clojurian/LISPian would read this code mentally. Just write it as a transcript. Or may be a Screen cast. 5. Have a cookbook like article for all common tasks. 6. Explain how idiomatic code looks like in Clojure. I feel experienced Lispers can help in this. It feels very scary when an experienced OOPS developer knowing all idiomatic code in OOPS does not know anything in LISP. I'm afraid to say that this feeling of shame must be prevented. After all, writing idiomatic LISP code is not rocket science. It is just lack of experience
*I personally feel that Clojure has enough of nice features.* All that is left to do is to make the transition easier. Although it may seem less technical and less interesting to the geeks, it is important to realize that all coders are not geeks and not everybody behaves rationally. Looks, presentation and ability to lure people also matters. After all, looks and ease in *every* way is an integral part of a Programming Language.
Finally, comments like "doing XYZ will encourage them to write sloppy code" is not good. Nobody likes to write sloppy code. They do it because writing good code is very hard in the language or the IDE does not support it.
A language need not be very good to be a success. A lot depends on the IDE support. It is known to everybody that most of the Java code is written in IDE like Eclipse only. And Eclipse goes a long way in reducing the boilerplate code, thus reducing a flaw in the Java language. Similarly Enclojure and Counterclockwise support be just splendid. Just saying "use Slime/Vimclojure" does not help again.
My 5 cents. it is too long for 2 cents.
Thanks, Ajay G
On Fri, Dec 18, 2009 at 9:28 PM, Sean Devlin <francoisdev...@gmail.com> wrote: > > Look, Clojure...
> 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 6:11 AM, "ajay gopalakrishnan" <ajgop...@gmail.com> wrote:
> 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, I feel a large majority of them > are those for whom Java is probably what Software development basically is. > (This has been a boon and bane of Computer Science. It reduces the barrier > to entry, but also prevents them from appreciating the true beauty. Many can > code a web application, thanks to Rails, Hibernate and the like without even > having an idea of what B-tree is) Everything begins and ends with Java. They > don't even know anything about C/C++. > And I think it would be foolish to assume that Clojure acceptance will > reach critical mass unless it is accepted by this group of people. > 2. Second issue is Bosses (higher-ups) and convincing them is hard. > Language features and the beauty of Lisp is not going to convince them. The > biggest problem is I think when they realize that they will have to loose > all the Imperative programming skills they have acquired all over these > years and now they will be on equal footing with the rest when it comes to > Functional programming experience. > 3. Sad as it is, most of the work gets done by Copy-paste work and > unless there is a online cookbook type thing, people will find it hard.
> Unless Clojure (not just Clojure, any functional programming language) > reduces this barrier to entry for both the non-core developers and the > Bosses, I think any FP language will find it hard. > Now, if we want Clojure to get accepted fast, I think we must be eager to > reduce this barrier to entry. Just saying that "If you can program in LISP" > then you can code Clojure is not a very smart answer. Similarly saying "get > used to parenthesis" is not a smart answer either.
> *It's really wrong to think that if they do not accept Clojure they are > doomed. The users have a higher hand and if not Clojure, new languages will > keep on being built until some language gets accepted by all. *
> I think what needs to be done is the following:
> 1. In LISP like languages, Parenthesis is a non-issue as long as code > is properly indented. And hence *strictly following indenting rules*while defining functions/Macros etc. is really really crucial. Hence my next > point. > 2. Excellent IDE indenting support for code Indentation. I have tried > Enclojure and it is good. But what I find is difficult for the LISP newbie > is deciding when to put code on the new line for function arguments and all > that. I know that there are rules for that (most Scheme like), but frankly > speaking, people have become very lazy and wouldn't waste time reading the > indenting rules, especially when the other Haskell,F#, Scala camp boasts to > address the same issues and say that we do it all without a lot of > parenthesis. *So in short, Can we do something in the IDE to make > Clojure code indentation a totally no-brainer?* > Perhaps Enclojure must show some *placeholders* properly indented based > on whether it is defmacro, defn or fn etc and the developer just fills it > up. This would be an excellent aid in promoting LISP indenting standards. > Overtime, once Clojure is widespread people will automatically start > doing it correctly. > 3. A nice and good article written by Clojure folks that highlights how > to transition from the OOPS thinking to Functional thinking. > 1. Just saying "Practice coding recursively" does not help at all. > Even core CS people do not use recursion for every thing these days. > Students have OS labs, Networking Labs and projects but everyone knows that > it does not involve much of recursion and all - just a plain sequence of > operations, that's all. At most 2-3 courses on Algorithms is where they use > Recursion heavily. > 2. I think the keyword "let" and the pipeline is very understated. > "let" is the single most important thing that makes this transition easy. > 4. Have an article that has some decent functions in it and each should > have an explanation of how an experienced Clojurian/LISPian would read this > code mentally. Just write it as a transcript. Or may be a Screen cast. > 5. Have a cookbook like article for all common tasks. > 6. Explain how idiomatic code looks like in Clojure. I feel experienced > Lispers can help in this. It feels very scary when an experienced OOPS > developer knowing all idiomatic code in OOPS does not know anything in LISP. > I'm afraid to say that this feeling of shame must be prevented. After all, > writing idiomatic LISP code is not rocket science. It is just lack of > experience
> *I personally feel that Clojure has enough of nice features.* All that is > left to do is to make the transition easier. Although it may seem less > technical and less interesting to the geeks, it is important to realize that > all coders are not geeks and not everybody behaves rationally. Looks, > presentation and ability to lure people also matters. After all, looks and > ease in *every* way is an integral part of a Programming Language.
> Finally, comments like "doing XYZ will encourage them to write sloppy code" > is not good. Nobody likes to write sloppy code. They do it because writing > good code is very hard in the language or the IDE does not support it.
> A language need not be very good to be a success. A lot depends on the IDE > support. It is known to everybody that most of the Java code is written in > IDE like Eclipse only. And Eclipse goes a long way in reducing the > boilerplate code, thus reducing a flaw in the Java language. Similarly > Enclojure and Counterclockwise support be just splendid. Just saying "use > Slime/Vimclojure" does not help again.
> My 5 cents. it is too long for 2 cents.
> Thanks, > Ajay G
> On Fri, Dec 18, 2009 at 9:28 PM, Sean Devlin <francoisdev...@gmail.com> > wrote: > > Look, Clojure...
> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@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+unsubscribe@googlegroups.com<clojure%2Bunsubscribe@googlegroups.com > > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
On 18 Dez., 20:07, Martin Coxall <pseudo.m...@me.com> 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 advantage, you will learn to love them if you start some serious hacking. * Reason. They could have been taken away in more than 50 years of history. Guess what, they are still there. If I came to lisp as a newbie, I would think that there must be some reason. * Trust. Just trust all the people telling you over and over again for ages, just trust all the fine software engineers who kept them in place for a very long time.
> I had this thought at work, when I should have been working, so please bear with me if it's nonsense.
> One of the things that always puts people off of Lisp, as we all know, are the parentheses. Now, many ways have been suggested of doing this in other Lisps, but have never taken off, mainly due to inertia and a fear of sacrificing homoiconicity.
> However, I love Clojure, and want to see it really take off. And so I want to see all barriers to that removed. Also, I think the language is young enough that seemingly-but-not-really radical proposals can still be sneaked in.
> Let's take this example, since I note that Rich Hickey weighed in in the comments:
> This little snippet has ten parentheses. And is potentially very unnerving to a non-lisper. Ten parentheses in four lines seems a lot to most programmers.
> Rich, in the comments, suggests a pipelined style to make the code more readable:
> I accept that this is more readable because it has less nesting. But it now has *12* parentheses, more than the original, potentially just as alarming to the Lispophobes.
> 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?
> A very simple offside rule could turn the original into:
> Also with two. That last example in particular looks splendidly readable. Almost... monadic.
> The parenthesis inference here is very simple, and could be stated in two sentences:
> 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 indentation is the same as or less than the remembered one.
> My question is: why would such a scheme work/not work, and why would/would not it be desirable?
> Martin
Whitespace-sensitive S-exprs have indeed already been implemented for Clojure. The author's github account seems to have been renamed/ deleted, however:
For my own toy programs, I have seen little use for significant whitespace in Clojure so far. Even though I work with Python professionally and like it's lack of syntactical noise, Clojure's parentheses (and vector brackets, and map braces) tend to communicate the programmer's intent more clearly, especially when code becomes as dense as is possible using Lisps/FP. All of this once the initial hurdle is overcome, of course. Clojure just looks and feels different compared to most mainstream languages, different even compared to the more traditional Lisps.
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.
Personally, I don't think the problem for non-Lispers is with the number of parentheses so much as with the *depth* of parens-nesting and having to invert the reading order, starting from the deepest s-expr and reading your way back out.
I'm still very new to Clojure (basically I have only been paying close attention to it for a few weeks, and have not written any substantial Clojure code yet), and I come from ten years of programming the usual non-Lisp Python/Java/JavaScript/C-style languages. But I can honestly say that reading Clojure code comes very naturally for me now, as long as I'm familiar with all the functions in an expression, and I assure you that it's certainly not that I'm special or particularly bright.
Interested programmers are willing to learn different syntaxes - judging from the number of apps, there are probably at least fifty thousand programmers who were willing to look past all the square brackets in Objective-C so that they could write iPhone apps. What I think makes it difficult to approach an S-expression isn't the parentheses, but the fact that you often have to read it in an inverse order, or maintain a mental stack of functions that have been applied so far. For me, this is especially the case when function calls are nested very deeply.
I'm not familiar with it, but from your example it appears that the ->> macro lets the code be written in an order which is not inverted. Furthermore, the first example "looks" like it has more parens than the ->> example, even though it actually has fewer, because of its deeper nesting - so it's easier to read through what's happening in the ->> example, without having to maintain a mental stack of what functions have are being applied to the expression. For interested programmers new to Clojure, I would think this is way more useful than reducing the number parentheses.
e
PS: I use the term "interested programmers" above because I don't think Clojure will ever appeal to a programmer who isn't interested in learning something new. The syntax is the easy part. The hard part is learning a different approach to designing and structuring programs.
On Fri, Dec 18, 2009 at 2:07 PM, Martin Coxall <pseudo.m...@me.com> wrote: > I had this thought at work, when I should have been working, so please bear with me if it's nonsense.
> One of the things that always puts people off of Lisp, as we all know, are the parentheses. Now, many ways have been suggested of doing this in other Lisps, but have never taken off, mainly due to inertia and a fear of sacrificing homoiconicity.
> However, I love Clojure, and want to see it really take off. And so I want to see all barriers to that removed. Also, I think the language is young enough that seemingly-but-not-really radical proposals can still be sneaked in.
> Let's take this example, since I note that Rich Hickey weighed in in the comments:
> This little snippet has ten parentheses. And is potentially very unnerving to a non-lisper. Ten parentheses in four lines seems a lot to most programmers.
> Rich, in the comments, suggests a pipelined style to make the code more readable:
> I accept that this is more readable because it has less nesting. But it now has *12* parentheses, more than the original, potentially just as alarming to the Lispophobes.
> 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?
> A very simple offside rule could turn the original into:
> Also with two. That last example in particular looks splendidly readable. Almost... monadic.
> The parenthesis inference here is very simple, and could be stated in two sentences:
> 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 indentation is the same as or less than the remembered one.
> My question is: why would such a scheme work/not work, and why would/would not it be desirable?
> Martin
> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
> 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 developers. A prospective Clojure developer must accept > that the language does this to help you, not hurt you, and they need > to be open to the ideas.
> That is the intended audience.
Clojure may be a new Lisp, but it seems the die hard holier-than-thou attitude of old-school Lipsers is alive and well.
Look, there's a reason nobody uses Lisp. And the attitude of "we know best and if you can't see that you're an idiot" is certainly part of it.
A prospective Clojure developer "must" not do anything. They will probably take one look at Clojure's seemingly user-hostile syntax, read how unless they immediately embrace parens that they are *not welcome*, click their browser back button and never give another thought to Clojure again.
On 19 Dec 2009, at 13:50, Stefan Kamphausen wrote:
> Hi,
> On 18 Dez., 20:07, Martin Coxall <pseudo.m...@me.com> 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 advantage, you will learn to love them if > you start some serious hacking.
I've seriously hacked in many languages, and have come to rely on the presence of Syntax. If Clojure wants me to seriously believe that syntax is overrated, it had better had a bloody go argument.
> * 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.
> If I came to lisp as a > newbie, I would think that there must be some reason. > * Trust. Just trust all the people telling you over and over again for > ages, just trust all the fine software engineers who kept them in > place for a very long time.
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.
> 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 language, so we can all feel smug that we understand something those poor average programmers were too simple to see.
You know there's nothing wrong with allowing Clojure to display its elegance upfront, rather than making programmers work for it like it's some Presbytarian admission exam.
On Sat, Dec 19, 2009 at 8:25 AM, Martin Coxall <pseudo.m...@me.com> 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 actively desirable that it remain a minority language, so we can all > feel smug that we understand something those poor average programmers were > too simple to see.
I don't think anybody in the Clojure community wants to Clojure to be a fringe language. Considering the ML now has about 3K subscribers (up 2500 from 14 months ago) I think Rich Hickey and the community have done a fair job touting it's advantages.
However, there are somethings about every language that you just have to accept. Lisp's parentheses are one of those things. For example, it's really not worth complaining about Python's enforcement of significant whitespace. Sure people sing it praises now, but to this day there still fruitless discussions about the matter mostly initiated by people with only a passing familiarity of the language.
> You know there's nothing wrong with allowing Clojure to display its > elegance upfront, rather than making programmers work for it like it's some > Presbytarian admission exam.
You are not the first to bring up the concern about parentheses and you will certainly not be the last. My advice would be to let the matter drop. People who aren't going to learn Lisp just because it has parentheses aren't going to be converted. But from the variety of programmers on this list, parens are not a significant deterrant for programmers coming from the background of Java, Scala, JavaScript, C, C++, Objective-C, OCaml, Haskell, Prolog, Erlang, PHP, Perl, Python, Ruby, etc.
> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@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+unsubscribe@googlegroups.com<clojure%2Bunsubscribe@googlegroups.com > > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
