Re: Parenthesis Inference
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 about clojure because they're corporate drones and couldn't care less. Maybe they're not allowed to use clojure at work. Maybe (as others have said) clojure is just more mental work per-line and that turns people away. If you look at the group's history, I think you'll find the clojure community is more than willing to work with people who have a genuine problem. However, if you come in here with unsubstantiated claims and demand a major language change, you'll need to provide more proof that there is an actual problem first. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
I was watching Pleasantville again and it reminded me of this whole argument. On Mon, Dec 21, 2009 at 6:39 PM, Joost jo...@zeekat.nl wrote: On 21 dec, 15:38, kyle smith the1physic...@gmail.com 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 study). Maybe java programmers don't know about clojure because they're corporate drones and couldn't care less. Maybe they're not allowed to use clojure at work. Maybe (as others have said) clojure is just more mental work per-line and that turns people away. As long as we're just speculating about the great unwashed I want everybody to note that Java was written with the great unwashed in mind, and look where it got us :) IMO many Java programmers (and especially their managers) think dynamic type resolution in large-scale projects is scary. And you know what, they may even be right. Ofcourse that completely ignores the kind of code-reduction (and project-size reduction!) it can bring, but it's a somewhat valid point. To those people: learn Haskell, THEN complain about Lisp syntax. :) The other thing that probably feels new and scary is the whole build- everything-from-expressions standpoint. You know; the side-effect free emphasis. This is something that every non-embedded programmer will have to let go of soon anway, so let's ignore that, except to note that it's not surprising that Erlang - which has been around for 15+ years - has only getting some real attention in the last couple of years. Again also: Haskell. Once you get those two big ones out of the way, there is no reason at all to assume that it's the parentheses that are actually holding anybody back. -- 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+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 the same time it comes with its overhead(?). So in essence ruby or python like languages which have very lispy constructs are actually lisp + parsing ? On Sun, Dec 20, 2009 at 12:57 PM, ajay gopalakrishnan ajgop...@gmail.comwrote: 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 expressions, so the whole () problem in LISP in general) Arithmetic expressions are rarely complicated enough to need full bracketing. And hence, it is better to have a preprocessor that fills in the required brackets when they are just redundant. For e.g. (+ (* 1 3) (/ 1 5)) It would be better if I could write it as: + (* 1 3) (/ 15) and the preprocessor should be able to convert it to (+ (* 1 3) (/ 1 5)) After all, the additional () is what the compiler needs. Not me. Above simplified version is mathematically unambiguous. This is much less noise. On Sun, Dec 20, 2009 at 2:12 AM, Richard Newman holyg...@gmail.comwrote: ( 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 me up when writing. Reading prefix-notation arithmetic is, of course, a joy when compared to infix (no trying to remember precedence, building intermediate tree nodes in my head, 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+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 way before. Even though I am accustomed to them now, I wish I'd had somebody explain them like this to me before. 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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, if it does not prevent us from writing efficient and correct
code then why not forget it and leave the compiler to worry about that.
If possible, I would also want to see a macro that allows me to write (x y)
instead of ( x y).
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.
[|...|], %...%, $...$?
I'm sensing that most people seem to agree that S-exprs *are* fugly and hostile
to those new to Lisp, but that the alternative (significant whitespace) is even
worse. So we're kind of stuck with them if we want the expressive power of
homoiconicity.
It's just that I think there's ample reason to believe S-expressions are the
reason most people abandoned Lisp. It doesn't seem to be a great hook to get
people to try a new one.
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
Martin Coxall pseudo.m...@me.com 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 just try a few example functions from contrib.
(defn subset?
Is set1 a subset of set2?
[set1 set2]
(and (= (count set1) (count set2))
(every? set2 set1)))
Drop the outer parens.
defn subset?
Is set1 a subset of set2?
[set1 set2]
and (= (count set1) (count set2))
(every? set2 set1)
Lets break after and so we can drop some more parens.
defn subset?
Is set1 a subset of set2?
[set1 set2]
and
= (count set1) (count set2)
every? set2 set1
Now lets introduce infix with say, |...|.
defn subset?
Is set1 a subset of set2?
[set1 set2]
and
|(count set1) = (count set2)|
every? set2 set1
Maybe they need spaces?
defn subset?
Is set1 a subset of set2?
[set1 set2]
and
| (count set1) = (count set2) |
every? set2 set1
Has that suddenly made things more readable? Maybe. I don't know. It
certainly felt really weird writing it. That and by itself does
remind me of Haskell. The code is definitely looking very tree-like
now, maybe that's a good thing? My eyes *are* jumping to the words
easier and it's definitely less noisy.
Yet, this no longer obviously looks like a list. Is that bad? I don't
know. Do we need to be constantly reminded our code has a list
representation? Does it make macros harder to think about?
Lets try some more examples. How about arity overloading?
defn reductions
Returns a lazy seq of the intermediate values of the reduction (as
per reduce) of coll by f, starting with init.
[f coll]
if (seq coll)
rec-seq self (cons (first coll) (map f self (rest coll)))
cons (f) nil
[f init coll]
rec-seq self (cons init (map f self coll))
Or a macro?
defmacro rec-seq
Similar to lazy-seq but binds the resulting seq to the supplied
binding-name, allowing for recursive expressions.
[binding-name body]
`let [s# (atom nil)]
reset! s# (lazy-seq (let [~binding-name @s#] ~...@body))
It becomes weirdly tempting to insert more line breaks just to get rid
of the rest of the parens.
defmacro rec-seq
Similar to lazy-seq but binds the resulting seq to the supplied
binding-name, allowing for recursive expressions.
[binding-name body]
`let [s# (atom nil)]
reset! s#
lazy-seq
let [~binding-name @s#] ~...@body
Hmm. Have we solved anything? Will this just make the complaints go
(from (too (many (parens
to
too
many
nesting
levels?
--
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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/a3df3bb6741b1a56) * The problem is not parens, the problem is *nested* parens. The 2 tips above + adding intermediate meaningful immutables using let help a lot. Hmm. Have we solved anything? Will this just make the complaints go (from (too (many (parens to too many nesting levels? -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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:05 am, Alex Osborne a...@meshy.org wrote:
Martin Coxall pseudo.m...@me.com 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 just try a few example functions from contrib.
(defn subset?
Is set1 a subset of set2?
[set1 set2]
(and (= (count set1) (count set2))
(every? set2 set1)))
Drop the outer parens.
defn subset?
Is set1 a subset of set2?
[set1 set2]
and (= (count set1) (count set2))
(every? set2 set1)
Lets break after and so we can drop some more parens.
defn subset?
Is set1 a subset of set2?
[set1 set2]
and
= (count set1) (count set2)
every? set2 set1
Now lets introduce infix with say, |...|.
defn subset?
Is set1 a subset of set2?
[set1 set2]
and
|(count set1) = (count set2)|
every? set2 set1
Maybe they need spaces?
defn subset?
Is set1 a subset of set2?
[set1 set2]
and
| (count set1) = (count set2) |
every? set2 set1
Has that suddenly made things more readable? Maybe. I don't know. It
certainly felt really weird writing it. That and by itself does
remind me of Haskell. The code is definitely looking very tree-like
now, maybe that's a good thing? My eyes *are* jumping to the words
easier and it's definitely less noisy.
Yet, this no longer obviously looks like a list. Is that bad? I don't
know. Do we need to be constantly reminded our code has a list
representation? Does it make macros harder to think about?
Lets try some more examples. How about arity overloading?
defn reductions
Returns a lazy seq of the intermediate values of the reduction (as
per reduce) of coll by f, starting with init.
[f coll]
if (seq coll)
rec-seq self (cons (first coll) (map f self (rest coll)))
cons (f) nil
[f init coll]
rec-seq self (cons init (map f self coll))
Or a macro?
defmacro rec-seq
Similar to lazy-seq but binds the resulting seq to the supplied
binding-name, allowing for recursive expressions.
[binding-name body]
`let [s# (atom nil)]
reset! s# (lazy-seq (let [~binding-name @s#] ~...@body))
It becomes weirdly tempting to insert more line breaks just to get rid
of the rest of the parens.
defmacro rec-seq
Similar to lazy-seq but binds the resulting seq to the supplied
binding-name, allowing for recursive expressions.
[binding-name body]
`let [s# (atom nil)]
reset! s#
lazy-seq
let [~binding-name @s#] ~...@body
Hmm. Have we solved anything? Will this just make the complaints go
(from (too (many (parens
to
too
many
nesting
levels?
--
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 francoisdev...@gmail.comwrote:
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:05 am, Alex Osborne a...@meshy.org wrote:
Martin Coxall pseudo.m...@me.com 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 just try a few example functions from contrib.
(defn subset?
Is set1 a subset of set2?
[set1 set2]
(and (= (count set1) (count set2))
(every? set2 set1)))
Drop the outer parens.
defn subset?
Is set1 a subset of set2?
[set1 set2]
and (= (count set1) (count set2))
(every? set2 set1)
Lets break after and so we can drop some more parens.
defn subset?
Is set1 a subset of set2?
[set1 set2]
and
= (count set1) (count set2)
every? set2 set1
Now lets introduce infix with say, |...|.
defn subset?
Is set1 a subset of set2?
[set1 set2]
and
|(count set1) = (count set2)|
every? set2 set1
Maybe they need spaces?
defn subset?
Is set1 a subset of set2?
[set1 set2]
and
| (count set1) = (count set2) |
every? set2 set1
Has that suddenly made things more readable? Maybe. I don't know. It
certainly felt really weird writing it. That and by itself does
remind me of Haskell. The code is definitely looking very tree-like
now, maybe that's a good thing? My eyes *are* jumping to the words
easier and it's definitely less noisy.
Yet, this no longer obviously looks like a list. Is that bad? I don't
know. Do we need to be constantly reminded our code has a list
representation? Does it make macros harder to think about?
Lets try some more examples. How about arity overloading?
defn reductions
Returns a lazy seq of the intermediate values of the reduction (as
per reduce) of coll by f, starting with init.
[f coll]
if (seq coll)
rec-seq self (cons (first coll) (map f self (rest coll)))
cons (f) nil
[f init coll]
rec-seq self (cons init (map f self coll))
Or a macro?
defmacro rec-seq
Similar to lazy-seq but binds the resulting seq to the supplied
binding-name, allowing for recursive expressions.
[binding-name body]
`let [s# (atom nil)]
reset! s# (lazy-seq (let [~binding-name @s#] ~...@body))
It becomes weirdly tempting to insert more line breaks just to get rid
of the rest of the parens.
defmacro rec-seq
Similar to lazy-seq but binds the resulting seq to the supplied
binding-name, allowing for recursive expressions.
[binding-name body]
`let [s# (atom nil)]
reset! s#
lazy-seq
let [~binding-name @s#] ~...@body
Hmm. Have we solved anything? Will this just make the complaints go
(from (too (many (parens
to
too
many
nesting
levels?
--
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+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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@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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 as all the other Lisps nobody uses. 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 put in quite a bit of time to make beginners feel welcome and to help this community grow. I object to people who are -- to exaggerate somewhat -- saying hey, this motorcycle's great, and I think tons more people would ride if you put two more wheels on. Let me know when you're finished. Real communities grow around people scratching shared itches, and I'm not going to spend my time working on somebody else's non-problem for free. I have plenty of -- paid -- Lisp work to do. (Must be all those customers that don't exist.) I think most of the active Clojure community ranges from not caring to genuinely liking s-expression notation, and many of us have seen (many times!) folks arrive from other languages, suggest that the Lisp of the day should switch to using indentation to get rid of all those parens, and then either move on to Ruby/Python/whatever… or realize than the parens aren't a problem after all. The same goes for infix math; lots of beginners start writing an infix math library, and by the time they're done they've become familiar with prefix notation and no longer want their new library. Someone who cares enough to solve a problem should go and solve it. Saying we should go and solve a problem is using weasel words to coerce others. Back on the topic: McCarthy originally intended Lisp to have an Algol- ish syntax (m-expressions), but nobody ever finished the work because they found s-expressions to be sufficient: http://en.wikipedia.org/wiki/M-expression The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned. It just receded into the indefinite future, and a new generation of programmers appeared who preferred internal notation to any FORTRAN-like or ALGOL-like notation that could be devised. — John McCarthy[1], History of Lisp I think a lot of people would benefit from learning the lessons of history. I'm done on this topic. It's old enough to drink, I don't think anything significant will come of it, and I'm happy with Clojure's current trajectory. -R -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
Hi, On 20 Dez., 18:41, Martin Coxall pseudo.m...@me.com 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 building a community at least as repellingly exclusionary as all the other Lisps nobody uses. 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 nothing new to this discussion in this thread compared to all the others. There are many other things to criticize in Common Lisp with good cause, and Clojure does a hell of a job cleaning many of those. Let's just be happy with that. This is my second and definetely my last post to this thread and hopefully to this topic in general. I only participated because I thought we need to go this once for Clojure, too. Kind regards, Stefan -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 nothing new to this discussion in this thread compared to all the others. Agreed. Some people can deal with the parentheses and some can't. It is what is. Let's move on to a more fruitful subject. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 prior to now has religiously referred to this family of languages as LISPs (LISt Processing), calls Clojure the first Lisp. [...] The same goes for infix math; lots of beginners start writing an infix math library, and by the time they're done they've become familiar with prefix notation and no longer want their new library. This is a telling point. No such library has to my (limited) knowledge ever become popular, and you would think this is where the idea would get the most traction. [...] Back on the topic: McCarthy originally intended Lisp to have an Algol- ish syntax (m-expressions), but nobody ever finished the work because they found s-expressions to be sufficient: http://en.wikipedia.org/wiki/M-expression The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned. It just receded into the indefinite future, and a new generation of programmers appeared who preferred internal notation to any FORTRAN-like or ALGOL-like notation that could be devised. — John McCarthy[1], History of Lisp I think a lot of people would benefit from learning the lessons of history. Indeed. Although I think the above ends during the punched card FORTRAN subroutine period of LISP. To draw in Sean Devlin's excellent point about REPLs, as I remember, not long after this period someone realized you could add read and print to eval and get an interpreter. One general principle I've noted is that when you have a design that solves problems you didn't know you had, you should pay attention. - Harold -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 all these required delimiters (parenthesis required in a if/while/for condition, semi-colons to split for loop expressions, statements, curly braces to create compound statements...). These are different requirements depending where you are in your code. Without hefty IDE support, you would be left nude on the ice bank. When HP introduced their pocket calculator with Postfix notation, people had to get used to it but it did not prevent HP calculators to become popular ones in the engineering/scientific/accountants community. Ok you would not expect your grocery store owner to use one but he's not building bridges or a creating a new cancer cure either. People bought HP calculators not for the Postfix notation but for all the others things it offered at the time... Luc On Fri, 2009-12-18 at 17:58 -0800, Vagif Verdi wrote: 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. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 guido.carba...@gmail.com 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 likes parentheses, good, if not, don't program in anything lispy. No body is forcing that person to program in lisp. Guido On Dec 19, 7:45 pm, Phil Hagelberg p...@hagelb.org wrote: Alex Osborne a...@meshy.org 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 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 Dylan! ... (peals of explosive laughter here) -Phil -- 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+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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. David -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
:)) 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 buy HP calculators because of the postfix notation. Oh, the other things are nice, too. David -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 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. David -- 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+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 dnolen.li...@gmail.com wrote: 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 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. David -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Omnem crede diem tibi diluxisse supremum. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
Martin Coxall pseudo.m...@me.com 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 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? I've just realized there's a really obvious problem with this scheme, which shows it's not really so easy. What if you don't want parens on a line? What if we try to write the identity function? defn identity [x] x This is interpreted as: (defn identity [x] (x)) Whoops! Python and sweet-expressions avoid this by adding () everywhere you want an actual function call. defn my-rand [x] rand() Yuck! Ruby and Perl, which allow paren-less calls do so by basically being the equivalent of a Lisp 2. Haskell deals with it by currying. Maybe use the infix notation to work around it? defn identity [x] |x| This is already getting bothersomely complicated. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 dnolen.li...@gmail.com wrote: 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 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. David -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Omnem crede diem tibi diluxisse supremum. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 Clojure, I really do. I find it concise, elegant and expressive. My great worry is that a wonderful language stands to be ignored by the assembled masses of Java programmers, simply because it has unwittingly inherited more Lisp baggage than it needs to. (Incidentally, I'd never really grokked how different Clojure is from trad Lisps until I watched Rich's screencasts on Clojure for Lisp 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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
Re: Parenthesis Inference
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 avi...@thewe.net 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
Re: Parenthesis Inference
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. * 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. Stefan -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
On Dec 18, 8: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: http://www.innoq.com/blog/st/2009/12/clojurelisp_readability.html (apply merge-with + (pmap count-lines (partition-all *batch-size* (line-seq (reader filename) 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: (- (line-seq (reader filename)) (partition-all *batch-size*) (pmap count-lines) (apply merge-with +)) 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: apply 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) 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, 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: http://209.85.129.132/search?q=cache:-f3Sb3BYidoJ:github.com/onyin/pleajure 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. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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: http://www.innoq.com/blog/st/2009/12/clojurelisp_readability.html (apply merge-with + (pmap count-lines (partition-all *batch-size* (line-seq (reader filename) 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: (- (line-seq (reader filename)) (partition-all *batch-size*) (pmap count-lines) (apply merge-with +)) 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: apply 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) 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, 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
Re: Parenthesis Inference
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. 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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. 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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. 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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. 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+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 the IRC channel this list. I believe you browse the archives you'll see that mutual assistance is the prevailing attitude here. Clojure's clean design does make it easy to learn. The sequence abstraction makes the core library small. The persistent data structures make it easier to write multithreaded stuff than in any other language (I invite you to provide a counter example). The macro system is hygienic, and as powerful as any other. I'm going to use a point from Paul Grahams' crtique of Java: http://www.paulgraham.com/javacover.html The main point I want to echo is that tools designed for other people always seem to be inferior to tools designed for myself. Clojure was originally written by Rich for Rich. I check that any feature I suggest really improves my own code before I post to the list. After that, the idea has to survive critique from lots of other Clojure experts, making sure that the feature is designed for myself. A lot of proposals don't get past this step, because it is already solved or it doesn't fit into the Clojure way. Removing parens is one of those changes that simultaneously is designed for other people and makes the expert's job more difficult (By making macro writing argument resolution harder). It's a complete and total loss from my perspective, and that is what evokes the emotional response. I've suffered enough at the hands of languages designed for other poeple. This is Clojure, and I want to keep it a language designed for myself. Sean On Dec 19, 9:18 am, Martin Coxall pseudo.m...@me.com 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 :)) 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. 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
Very abstract java example (as concise as possible):
ListObject processList(ListObject oldObjects)
{
ListObject newObjects = ArrayListObject;
for(Object object : oldObjects)
{
newObjects.add(manipulate(object));
}
return newObjects;
}
Clojure equivalent:
(defn processList [#^Object list]
(for [object list] (manipulate object)))
I realize this is a very pedestrian example, but a couple things to note (and
I'm sure mentioned previously):
- Lisps are much more expressive, in general
- Compared to most languages there is significantly less syntactic noise-
There is just enough syntax to delimit the code.
- The code is a data-structure (homoiconicity), and it is very easy to see
where the expression begins and ends (this is good for readability, code
formatters, etc)
- Lisps are very consistent- no special code formatting rules to remember.
Despite what seems like a large number of parentheses there are far less
'control' characters.
I.e. instead of : . ; ( ) { } you have ( ), and usually fewer of them.
- Most programmers rely on their IDE/Editor or indentation to make sure they
are matching curly-braces correctly,
which is made harder by blocks of code that frequently extend beyond the
height of your screen.
IDEs/editors can match parentheses as well. :)
- The parentheses make the code sleek and aerodynamic
---
Joseph Smith
j...@uwcreations.com
(402)601-5443
On Dec 19, 2009, at 11:21 AM, David Nolen wrote:
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.
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
Oops.. left two parentheses out in my Java code. Guess that just furthers my
point. :)
ListObject newObjects = ArrayListObject();
On Dec 19, 2009, at 12:04 PM, Joseph Smith wrote:
Very abstract java example (as concise as possible):
ListObject processList(ListObject oldObjects)
{
ListObject newObjects = ArrayListObject;
for(Object object : oldObjects)
{
newObjects.add(manipulate(object));
}
return newObjects;
}
Clojure equivalent:
(defn processList [#^Object list]
(for [object list] (manipulate object)))
I realize this is a very pedestrian example, but a couple things to note (and
I'm sure mentioned previously):
- Lisps are much more expressive, in general
- Compared to most languages there is significantly less syntactic noise-
There is just enough syntax to delimit the code.
- The code is a data-structure (homoiconicity), and it is very easy to see
where the expression begins and ends (this is good for readability, code
formatters, etc)
- Lisps are very consistent- no special code formatting rules to remember.
Despite what seems like a large number of parentheses there are far less
'control' characters.
I.e. instead of : . ; ( ) { } you have ( ), and usually fewer of them.
- Most programmers rely on their IDE/Editor or indentation to make sure they
are matching curly-braces correctly,
which is made harder by blocks of code that frequently extend beyond the
height of your screen.
IDEs/editors can match parentheses as well. :)
- The parentheses make the code sleek and aerodynamic
---
Joseph Smith
j...@uwcreations.com
(402)601-5443
On Dec 19, 2009, at 11:21 AM, David Nolen wrote:
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.
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send
Re: Parenthesis Inference
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 are Gods and the most brilliant minds on the planet. A lot are just average. And ofcourse, if Clojure does not try to make them feel at home, it is just going to be another Hobby language. That's all. -- 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+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
On Sat, Dec 19, 2009 at 9:21 AM, David Nolen dnolen.li...@gmail.com 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 in between the two extremes. You certainly want enough people who love working with a language that the language keeps moving forward and cool libraries and tools are continually being developed. On the other hand, there's something very nice about knowing a language that is a bit of a secret weapon. Sometimes companies advertise that they are looking for a certain language, not because they really need that language, but because they know that any developer who knows that language is likely to be of a certain high caliber. They use the language as a way to weed out run-of-the-mill software engineers. Languages like Haskell, Scheme, and ML are often used for this purpose (not Java, of course, it's too mainstream). Such job posts also send a signal to talented developers that their company is a special place to work, because they know the value of secret weapon languages. I would actively like to see Clojure remain obscure enough to fall into this category. I sympathize with the original poster's point, however. I have been using Lisp dialects for 20 years, and I still find Lisp code harder to read than its mainstream counterparts. The parentheses provide a visual sameness to the code that forces you to think very hard to understand it. Python, on the other hand, is the most readable language I've encountered. So, despite all the claims that you'll learn to love parentheses, I'll say that it's not necessarily true. I have no love for the hyper-consistent prefix syntax for functions, macros, and keywords, and all the deeply-nested parentheses that result. Still, I'm flexible enough that I have no problem *tolerating* Lisp's syntax. And if other people can't see past the parentheses and understand the value of the language, I have a hard time getting worked up about that (see above point). -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
On Dec 18, 9:28 pm, Sean Devlin francoisdev...@gmail.com 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 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
Well, good thing you repented of your evil ways On Dec 19, 3:37 pm, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Dec 18, 9:28 pm, Sean Devlin francoisdev...@gmail.com 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 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
On 19 dec, 15:25, 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. 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. Most programming languages aren't judged on their syntactical elegance, otherwise nobody would use Erlang, for example. Now I like Erlang, but I still think it just looks horrible and it has way too many syntactical niggles that are hard to get familiar with. Lisp languages are completely simple in that regard. The worst question you generally run into is whether to add 1 or 2 pairs of parentheses at some point. Clojure makes this a bit simpler in the generally-used cases and a bit harder overall (since it uses 4+ different kinds of delimiters) Now that does not mean it doesn't look alien. It does. Deal with it or do something else. But don't pretend that doing what clojure *does* is much easier to write or read in any kind of familiar syntax, unless you're got a really serious contender. It's been tried many times - McCarthy himself did not think s-expressions were the final syntax for the language - but nobody has been able to come up with a syntax that actually works better for Lisp. Once everything is an expression - and especially when you place a large emphasis on side-effect free code - all you can really do to improve the parenthesis problem is to compact typical constructs. We've already got macros and decent reader syntax. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
Martin Coxall pseudo.m...@me.com 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 considered mainstream, there was just as much noise about Python and whitespace-sensitivity and the explicit self in method arguments as there is about Clojure and parens. 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. Take away the parens and that same Joe Q. Coder is likely to pick something else to take one look at and run away screaming. Perhaps the JVM, perhaps immutability, perhaps the whitespace-sensitive syntax. I'm not telling you not to try it. If you can pull off a preprocessor or much better an editor, that makes Clojure code _significantly_ easier to read while retaining its expressiveness, simplicity of macro writing and tool support then I will join you in using and championing it. 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. That doesn't mean it's not possible, just that it's not going to be as simple as just allowing others to write whitespace-sensitive Clojure. The reaction you are seeing from the old-school lispers (of which I am not one, unless 4 months is old) is understandable. It's the same sort of reaction you would get from an old-school Python programmer if you jumped on the Python mailing list and declared that you've solved the significant-whitespace problem: allow newcomers to write Python code with lisp-like parens. ;-) -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
Alex Osborne a...@meshy.org 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 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 Dylan! ... (peals of explosive laughter here) -Phil -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 likes parentheses, good, if not, don't program in anything lispy. No body is forcing that person to program in lisp. Guido On Dec 19, 7:45 pm, Phil Hagelberg p...@hagelb.org wrote: Alex Osborne a...@meshy.org 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 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 Dylan! ... (peals of explosive laughter here) -Phil -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 that I am unable to understand the code. However, in the
case of Lisp, since it is more condensed than Java, even though I am looking
at the same place for a longer time, I am actually assimilating at almost
the same rate!
I believe that for Lisp beginners coming from Imperative style, the Brain is
being fooled into believing that it is dumb! Actually it is doing perfectly
fine as long as it understand the different functions/API.
Parenthesis, prefix notations were never a big issue for me. In fact, the
parenthesis are mostly invisible in properly syntax highlighted and properly
indented code. However proper indentation is the key. In other languages you
can figure out things based on syntax symbols like [] { } = and so on.
Since Lisp does not have any of these, the only support the Programmer has
is Indentation!
I should not say this ... but just to get a feel I stared at some Scala code
for a while and said to myself - What the hell is this! Why am I feeling it
painful to move my eyes so much and there is so much of syntactic noise.
It is just a matter of getting used to. Granted not everybody will feel
comfortable in the same time and so there will be resistance to Lisp style
syntax for a while.
On Sat, Dec 19, 2009 at 2:35 PM, Mark Engelberg mark.engelb...@gmail.comwrote:
On Sat, Dec 19, 2009 at 9:21 AM, David Nolen dnolen.li...@gmail.com
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 in between the two extremes. You certainly want enough
people who love working with a language that the language keeps moving
forward and cool libraries and tools are continually being developed.
On the other hand, there's something very nice about knowing a
language that is a bit of a secret weapon. Sometimes companies
advertise that they are looking for a certain language, not because
they really need that language, but because they know that any
developer who knows that language is likely to be of a certain high
caliber. They use the language as a way to weed out run-of-the-mill
software engineers. Languages like Haskell, Scheme, and ML are often
used for this purpose (not Java, of course, it's too mainstream).
Such job posts also send a signal to talented developers that their
company is a special place to work, because they know the value of
secret weapon languages. I would actively like to see Clojure
remain obscure enough to fall into this category.
I sympathize with the original poster's point, however. I have been
using Lisp dialects for 20 years, and I still find Lisp code harder to
read than its mainstream counterparts. The parentheses provide a
visual sameness to the code that forces you to think very hard to
understand it. Python, on the other hand, is the most readable
language I've encountered. So, despite all the claims that you'll
learn to love parentheses, I'll say that it's not necessarily true.
I have no love for the hyper-consistent prefix syntax for functions,
macros, and keywords, and all the deeply-nested parentheses that
result. Still, I'm flexible enough that I have no problem
*tolerating* Lisp's syntax. And if other people can't see past the
parentheses and understand the value of the language, I have a hard
time getting worked up about that (see above point).
--
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+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
On Sat, 19 Dec 2009 14:22:22 + Martin Coxall pseudo.m...@me.com 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 overstated the case. Both times. I encounter about one company a year that uses LISP commercially - mostly doing the heavy lifting on the back end server in what we call cloud applications these days. Anyone serious about either emacs or Autocad works with lisp. XlispStat seems to still be alive and well. Sure, even all put together, they're a really small fringe group - but the difference between nothing and almost nothing can be *very* significant (just ask the guy who though that the Tacoma narrows wind resonance was nothing). Second, I've encountered both people and companies that have dropped LISP, and the reason is almost never those parens. It usually because of one of a number of reasons that can be summarized as LISP doesn't play well with others: 1. Lack of access to system libraries and frameworks. 2. The pain of sharing data with system utilities and applications. 3. The difficulty of moving programs to other platforms, *especially* if the LISP has solved 1 2! This is why the people doing LISP commercially tend to use it on servers - they duck issue #3 for getting the solution to their customers, and thus only have to find an implementation that solves #1 and 2 on their server platform. Note that Clojure solves all three problems by running on the JVM with Java integration. Of course, the question is - how much have you overstated the case? Because that will determine how true this is: On Sat, 19 Dec 2009 12:16:03 -0500 ajay gopalakrishnan ajgop...@gmail.com wrote: Why is it that you believe them to be mutually exclusive events? You portray Software engineers as if they are Gods and the most brilliant minds on the planet. A lot are just average. And ofcourse, if Clojure does not try to make them feel at home, it is just going to be another Hobby language. That's all. Possibly. But what do you mean by Hobby language? Something like Oz, which only a few people have heard of, and is pretty much only used academically? I suspect we're already past that stage. Or something like Python, which has a fair share of the LAMP market, in spite of having syntax issues that drive about as much discussion as the parens in LISP do, but almost no presence as an enterprise language? If the latter, I'm perfectly happy with that. I've made pretty good living writing Python the past decade or so. If I were willing to use Django or one of the other web templating systems built in Python, I could have done even better. The question here is, how much are you willing to give up in order to make Clojure an enterprise language? In the python community - and I've already seen a bit of it here - complaints about the lack of static type checking are about as common as complaints about the lack block delimiters. Are we going to add type declarations to Clojure to make those people feel at home? The end result of this path is that Clojure just becomes another Java, and won't be as productive or as much fun as it is today. One of the best things about Python is that the community wants the language to actually improve, even if it means not growing the community. Features aren't normally added to the language just because a lot of people want them; they're added because they actually answer a real need, and don't encourage people to write ugly code. Part of this is because they realize that adding a feature has a cost even for people who don't use it. If nobody uses it, why add it? If somebody uses it, then at some point you'll encounter code that does - so you'll have to know about it. If it encourages the creation of ugly code, so much the worse. The net result of these attitudes is that, even after nearly 20 years of change and community growth, python remains both powerful and a joy to write and read. So, does it really do you any good to add features to Clojure that attract more programmers if the end result is a language that you don't enjoy programming in, and that doesn't give you the productivity that drew you to the language in the first place? mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 expressive and information-dense. The remedy to this though is not to eliminate the perens syntax, but to use intermediate defs and defns to break up the logic into manageable chunks. These defs would also make the code more self documenting, by associating names with information. As someone who's never learned a lisp before, I find myself warming up quickly to the perens syntax. I think that it's appropriate that a language which takes a completely different approach should also have a different syntax than what I'm used to. I don't think that it might offend some people is a valid argument for stripping out a core element of the language syntax. If they're not willing to come out of their comfort zones on such a minor detail then they probably aren't very receptive to functional programming in the first place. And that's my $0.02. :-) -Brandon On Dec 19, 10:21 am, David Nolen dnolen.li...@gmail.com wrote: 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. 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+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
Phil Hagelberg p...@hagelb.org writes: Alex Osborne a...@meshy.org 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 Dylan! Gosh. So I am. It was created by Apple, no less. It even lets you use semicolons. Semicolons and Apple! That's got to be a recipe for success with the superficial masses. Seriously though, there's plenty of examples that show that popularity does not strongly depend on readable syntax (look at HTML, Ant, heck Perl). But from either side, an argument based on an appeal to popularity is sort of missing the point. I share the opinion of Mark Engelberg and others. I don't mind Lisp syntax because it has benefits, but it's definitely not as readable. The sweet expressions guy (David Wheeler) covers this pretty well: http://www.dwheeler.com/readable/retort-lisp-can-be-readable.html I'm not sure if sweet expressions are the answer. Or even if there is an answer. But for me editor support is key. I've overheard this conversation countlessly, about so many languages: Oh, what's that you're coding in? Foobar. It's pretty awesome. Yeah, it looks pretty nice. See how you don't need to specify the blahs? The compiler just figures it out. Nice! I might try it out. Does it work with Eclipse? Well, sort of, but ... Oh. Are there any other nice editors that work better with it? Netbeans maybe? Not really. There's an Emacs mode but ... Oh. Well. Nevermind then. Some other time, maybe. I know David Wheeler's retort to the suggestion of tools is: If you have to use tools to make parens less of a problem, perhaps you should use a better notation that removes extraneous characters in the first place. But I'm not sure I agree with him. I find code (in any syntax) harder to read without syntax highlighting. I also find it frustrating to write without at least basic auto-indentation. We're going to want tools anyway and Lisp's simple syntax and homoiconicity make it so much easier to write them. Funnily enough, I know people who claim Python and Ruby are horrifying. What do they prefer? XSLT. Yes, that XSLT. Yes, the W3C one. Really. Why? Better editor support. Structural editing, on the fly validation, online previewing, XPath generation, backmapping, extensive auto-completion, profilers, debuggers, graph and table visualizations, WYSIWYG XSL-FO report generators, the list goes on and on. The language and syntax are quite frankly awful, but boy do they have some nice tools. The more I use paredit's structural editing the more I find I can't live without it either. The one annoyance I have with it is when I accidentally manage to insert a stray bracket and it gets confused. But maybe here there's something to be learned from the XSLT folks, even if their serialization format leaves a lot to be desired. Maybe paredit should be taken to its logical conclusion: just edit data structures directly, don't worry about the text. Let your editor display and edit infix math. Heck, let it show you complex math expressions with LaTeX formatting for the ultimate in readability. Let it show nesting just with indentation. When you save the file, what does your hypothetical editor do? It writes things out, properly indented, in that good-old relatively easy to parse (for both man and machine) syntax from time immemorial. Can we have our cake and eat it too? -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
Give it a shot. Hack up a prototype. Let's see what happens. On Dec 20, 12:07 am, Alex Osborne a...@meshy.org wrote: Phil Hagelberg p...@hagelb.org writes: Alex Osborne a...@meshy.org 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 Dylan! Gosh. So I am. It was created by Apple, no less. It even lets you use semicolons. Semicolons and Apple! That's got to be a recipe for success with the superficial masses. Seriously though, there's plenty of examples that show that popularity does not strongly depend on readable syntax (look at HTML, Ant, heck Perl). But from either side, an argument based on an appeal to popularity is sort of missing the point. I share the opinion of Mark Engelberg and others. I don't mind Lisp syntax because it has benefits, but it's definitely not as readable. The sweet expressions guy (David Wheeler) covers this pretty well: http://www.dwheeler.com/readable/retort-lisp-can-be-readable.html I'm not sure if sweet expressions are the answer. Or even if there is an answer. But for me editor support is key. I've overheard this conversation countlessly, about so many languages: Oh, what's that you're coding in? Foobar. It's pretty awesome. Yeah, it looks pretty nice. See how you don't need to specify the blahs? The compiler just figures it out. Nice! I might try it out. Does it work with Eclipse? Well, sort of, but ... Oh. Are there any other nice editors that work better with it? Netbeans maybe? Not really. There's an Emacs mode but ... Oh. Well. Nevermind then. Some other time, maybe. I know David Wheeler's retort to the suggestion of tools is: If you have to use tools to make parens less of a problem, perhaps you should use a better notation that removes extraneous characters in the first place. But I'm not sure I agree with him. I find code (in any syntax) harder to read without syntax highlighting. I also find it frustrating to write without at least basic auto-indentation. We're going to want tools anyway and Lisp's simple syntax and homoiconicity make it so much easier to write them. Funnily enough, I know people who claim Python and Ruby are horrifying. What do they prefer? XSLT. Yes, that XSLT. Yes, the W3C one. Really. Why? Better editor support. Structural editing, on the fly validation, online previewing, XPath generation, backmapping, extensive auto-completion, profilers, debuggers, graph and table visualizations, WYSIWYG XSL-FO report generators, the list goes on and on. The language and syntax are quite frankly awful, but boy do they have some nice tools. The more I use paredit's structural editing the more I find I can't live without it either. The one annoyance I have with it is when I accidentally manage to insert a stray bracket and it gets confused. But maybe here there's something to be learned from the XSLT folks, even if their serialization format leaves a lot to be desired. Maybe paredit should be taken to its logical conclusion: just edit data structures directly, don't worry about the text. Let your editor display and edit infix math. Heck, let it show you complex math expressions with LaTeX formatting for the ultimate in readability. Let it show nesting just with indentation. When you save the file, what does your hypothetical editor do? It writes things out, properly indented, in that good-old relatively easy to parse (for both man and machine) syntax from time immemorial. Can we have our cake and eat it too? -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 expressive and information-dense. The remedy to this though is not to eliminate the perens syntax, but to use intermediate defs and defns to break up the logic into manageable chunks. These defs would also make the code more self documenting, by associating names with information. Yes. Even I feel the same. The problem is not the Parens, but Remembering the deep stack of function calls. This brings me to my next question: - Is it LESS idiomatic to use lets to bind the output of a few functions. - Do you derive ANY benefit by deeply nesting functions? I would assume the opposite. The only loss is conciseness and I would be willing to sacrifice it a bit for readability. If not, then the use of Let should be highly encouraged. And that will fix the problem provided code is indented correctly. As someone who's never learned a lisp before, I find myself warming up quickly to the perens syntax. I think that it's appropriate that a language which takes a completely different approach should also have a different syntax than what I'm used to. I don't think that it might offend some people is a valid argument for stripping out a core element of the language syntax. If they're not willing to come out of their comfort zones on such a minor detail then they probably aren't very receptive to functional programming in the first place. And that's my $0.02. :-) -Brandon On Dec 19, 10:21 am, David Nolen dnolen.li...@gmail.com wrote: 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. 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+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com clojure%2bunsubscr...@googlegroups.comclojure%252bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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
Re: Parenthesis Inference
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 then why not forget it and leave the compiler to worry about that. If possible, I would also want to see a macro that allows me to write (x y) instead of ( x y). (+ x y) can be read literally as add x to y (square x) can be read literally as squares x ( x y) how do you read this literally left-to-right? Relational operators being so common in code, I think it abuse of notation is valid here. Thanks Ajay G. On Sun, Dec 20, 2009 at 12:40 AM, Sean Devlin francoisdev...@gmail.comwrote: Give it a shot. Hack up a prototype. Let's see what happens. On Dec 20, 12:07 am, Alex Osborne a...@meshy.org wrote: Phil Hagelberg p...@hagelb.org writes: Alex Osborne a...@meshy.org 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 Dylan! Gosh. So I am. It was created by Apple, no less. It even lets you use semicolons. Semicolons and Apple! That's got to be a recipe for success with the superficial masses. Seriously though, there's plenty of examples that show that popularity does not strongly depend on readable syntax (look at HTML, Ant, heck Perl). But from either side, an argument based on an appeal to popularity is sort of missing the point. I share the opinion of Mark Engelberg and others. I don't mind Lisp syntax because it has benefits, but it's definitely not as readable. The sweet expressions guy (David Wheeler) covers this pretty well: http://www.dwheeler.com/readable/retort-lisp-can-be-readable.html I'm not sure if sweet expressions are the answer. Or even if there is an answer. But for me editor support is key. I've overheard this conversation countlessly, about so many languages: Oh, what's that you're coding in? Foobar. It's pretty awesome. Yeah, it looks pretty nice. See how you don't need to specify the blahs? The compiler just figures it out. Nice! I might try it out. Does it work with Eclipse? Well, sort of, but ... Oh. Are there any other nice editors that work better with it? Netbeans maybe? Not really. There's an Emacs mode but ... Oh. Well. Nevermind then. Some other time, maybe. I know David Wheeler's retort to the suggestion of tools is: If you have to use tools to make parens less of a problem, perhaps you should use a better notation that removes extraneous characters in the first place. But I'm not sure I agree with him. I find code (in any syntax) harder to read without syntax highlighting. I also find it frustrating to write without at least basic auto-indentation. We're going to want tools anyway and Lisp's simple syntax and homoiconicity make it so much easier to write them. Funnily enough, I know people who claim Python and Ruby are horrifying. What do they prefer? XSLT. Yes, that XSLT. Yes, the W3C one. Really. Why? Better editor support. Structural editing, on the fly validation, online previewing, XPath generation, backmapping, extensive auto-completion, profilers, debuggers, graph and table visualizations, WYSIWYG XSL-FO report generators, the list goes on and on. The language and syntax are quite frankly awful, but boy do they have some nice tools. The more I use paredit's structural editing the more I find I can't live without it either. The one annoyance I have with it is when I accidentally manage to insert a stray bracket and it gets confused. But maybe here there's something to be learned from the XSLT folks, even if their serialization format leaves a lot to be desired. Maybe paredit should be taken to its logical conclusion: just edit data structures directly, don't worry about the text. Let your editor display and edit infix math. Heck, let it show you complex math expressions with LaTeX formatting for the ultimate in readability. Let it show nesting just with indentation. When you save the file, what does your hypothetical editor do? It writes things out, properly indented, in that good-old relatively easy to parse (for both man and machine) syntax from time immemorial. Can we have our cake and eat it too? -- 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
Re: Parenthesis Inference
( 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 me up when writing. Reading prefix-notation arithmetic is, of course, a joy when compared to infix (no trying to remember precedence, building intermediate tree nodes in my head, 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
ajay gopalakrishnan ajgop...@gmail.com 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 to y (square x) can be read literally as squares x ( x y) how do you read this literally left-to-right? Ah yeah, that's one that still trips me up. Some people kind of read ( x y z) as (ascending? x y z) and you could think of the symbol as a ramp going up so the z is above the y is above the x. Even knowing that I still confuse myself occasionally though. I don't have any problems with arithmetic or function calls, I just really expect the larger quantity to be on the wide side of the wedge. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 expressions, so the whole () problem in LISP in general) Arithmetic expressions are rarely complicated enough to need full bracketing. And hence, it is better to have a preprocessor that fills in the required brackets when they are just redundant. For e.g. (+ (* 1 3) (/ 1 5)) It would be better if I could write it as: + (* 1 3) (/ 15) and the preprocessor should be able to convert it to (+ (* 1 3) (/ 1 5)) After all, the additional () is what the compiler needs. Not me. Above simplified version is mathematically unambiguous. This is much less noise. On Sun, Dec 20, 2009 at 2:12 AM, Richard Newman holyg...@gmail.com wrote: ( 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 me up when writing. Reading prefix-notation arithmetic is, of course, a joy when compared to infix (no trying to remember precedence, building intermediate tree nodes in my head, 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+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Parenthesis Inference
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: http://www.innoq.com/blog/st/2009/12/clojurelisp_readability.html (apply merge-with + (pmap count-lines (partition-all *batch-size* (line-seq (reader filename) 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: (- (line-seq (reader filename)) (partition-all *batch-size*) (pmap count-lines) (apply merge-with +)) 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: apply 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) 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, 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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? -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 On Dec 18, 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: http://www.innoq.com/blog/st/2009/12/clojurelisp_readability.html (apply merge-with + (pmap count-lines (partition-all *batch-size* (line-seq (reader filename) 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: (- (line-seq (reader filename)) (partition-all *batch-size*) (pmap count-lines) (apply merge-with +)) 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: apply 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) 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, 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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 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 -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
On Fri, 18 Dec 2009 19:07:43 + 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. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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. http://www.dwheeler.com/readable/sweet-expressions.html 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: http://www.emacswiki.org/emacs-zh/UnParenMode 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. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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:
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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. -- 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Parenthesis Inference
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
