Clojure - Python Style suggestion

[Sergey Didenko]

Hi,

For us as Clojure community it is easy to see how Clojure benefits
from being a Lisp. Homoiconity, extreme conciseness, esoteric look and
feel, etc.

However it is hard to see from the inside how Clojure as ecosystem
(probably) suffer from being a Lisp. Please don't throw rotten eggs at
me, I mean only the part of Lisp that is ... parentheses.

I remember a number of people that mention parentheses as obstacles to
the wider Clojure adoption, in the Clojure space - in the Clojure
related discussions, even on this mailing list IIRC.

But the number of people thinking this way outside the Clojure groups
is even bigger! We probably don't notice it because got immune to this
famous argument "it has too many parentheses" early when diving into
Clojure.

I suggest there are a big number of people that could gain interest in
clojure if we provide them with parentheses-lite Clojure syntax. For
example we can steal Python way of intending blocks.

For example the following quicksort implementation

(defn qsort [[pivot & xs]]
(when pivot
(let [smaller #(< % pivot)]
(lazy-cat (qsort (filter smaller xs))
[pivot]
(qsort (remove smaller xs))))))

could be written as

(set! python-style-op-op true)

defn qsort [[pivot & xs]]
when pivot
let [smaller #(< % pivot)]
lazy-cat
qsort
filter smaller xs
[pivot]
qsort
remove smaller xs

What do you think?

Isn't is less complex?


P.S. Ok, I must confess, the mention of the C-Word in the last
sentence was just a desperate way to get Rich's attention.

P.P.S. Actually I would also love to see Clojure community making
video clip "Clojure - Python Style" as a remix for "G... Style", but
this idea is probably way ahead of its time.


Regards, Sergey.

[Timothy Baldridge]

Parens actually don't complect, they have a very very clear meaning. They organize functions and arguments. Let's take one line from your example:

filter smaller xs

So....is that the python equivalent to which of these?

filter(smaller(xs))
filter(smaller, xs)
filter(smaller(), xs())
filter(smaller(xs()))

I would also assert that Python complects formatting and semantic meaning of the code. I'm quite proficient at Python and even I hate that fact. 

Timothy

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[Sergey Didenko]

The main point is to reach new market by providing parentheses-lite
Clojure syntax.

Of course real serious Clojurians will be using the current syntax :)

[Sergey Didenko]

Unfortunately I don't know Python good enough to answer this. The
point though is just to mimic Python a very tiny bit. Basically to
convert some of "(" and ")" to indentations.

[Tamreen Khan]

Sergey's example code seems to have arguments to a function happen on the same line while new function calls appear on new lines. So:

filter

  smaller xs

...would be the equivalent of filter(smaller(xs)).

Anyway, I agree that parens don't add any more clutter. Having to *always* have all the arguments on the same line could lead to needlessly long lines. I also don't see how syntax like this would make the transition to full Clojure with all the parentheses any easier. Beginners would still shy away from all the parens and never go beyond playing around with the language.

Would Python ever have a "indent-lite" version that allowed beginners to use braces instead of indentation? Of course not, because learning to read and write code with significant whitespace is an important part of python. If a beginner doesn't learn those things from the start they'll only handicap themselves more later on. And the same goes with Clojure, it's important to learn those parentheses from the beginning so you can lose your fear of them earlier on.

Tamreen

[Mimmo Cosenza]

If someone is able to show me the homoiconity expressed in a better way than clojure I'll buy it.
mimmo

[Herwig Hochleitner]

I can't see the community migrating to such a syntax, even if somebody bothered to implement a reader for it.

For me, the parentheses are vital in editing my source code. With lisp, I'm editing faster than with any other language, thanks to paredit.

Regarding people seeing parens as an obstacle: Of all the arguments one could make against Clojure as a strict, dynamically typed, lexically scoped, JVM hosted lisp; when I hear someone complaining about the parens I conclude that this person didn't look at the real merits and trade-offs of clojure and/or didn't understand them.

While I still think, we should cater to them as users, introducing a new surface syntax doesn't strike me as a net win.

I'm happy to gain them as users, as soon as their company switches to clojure ;-)

If you still want to go down that route, have a look at dylan: http://en.wikipedia.org/wiki/Dylan_(programming_language)

[Sergey Didenko]

My point is to introduce a second-class syntax to attract orthodox
users. Definitely not migrating.

The rules of transformation can be so simple that any useful library
written by Clojure Python style adopters could be translated to the
canonical style automatically with a few line program.

[Tamreen Khan]

Again, I don't think it will help attract new users, at least not the way we want. Parentheses are an important part of the language and it's not something a beginner can just pick up later. If they're scared of parentheses now, they'll be scared when they try to jump from this paren-lite syntax to full Clojure. And it's for the same reasons that Python doesn't have a 'simpler' version without significant whitespace.

[Gabriel Perdue]

On Feb 4, 2013, at 2:01 PM, Sergey Didenko <sergey....@gmail.com> wrote:

For example the following quicksort implementation

(defn qsort [[pivot & xs]]
 (when pivot
   (let [smaller #(< % pivot)]
     (lazy-cat (qsort (filter smaller xs))
[pivot]
(qsort (remove smaller xs))))))

could be written as

(set! python-style-op-op true)

defn qsort [[pivot & xs]]
 when pivot
   let [smaller #(< % pivot)]
     lazy-cat
       qsort
         filter smaller xs
[pivot]
qsort
         remove smaller xs

What do you think?

I think that looks a bit like Haskell.  :)

pax

Gabe

[Armando Blancas]

What do you think?

 

I think, go right ahead and give it to them. Worst that could happen is you gain insights into language design. I'd be interested in your users' comments; what worked, what didn't. If you really believe in that idea, don't give it up before you learn something from it.

[Jason Lewis]

Significant white space is the most horrifying development in programming languages in the last 20 years. Please kill this thread.

On Feb 4, 2013 5:25 PM, "Armando Blancas" <abm2...@gmail.com> wrote:

What do you think?

 

I think, go right ahead and give it to them. Worst that could happen is you gain insights into language design. I'd be interested in your users' comments; what worked, what didn't. If you really believe in that idea, don't give it up before you learn something from it.

--

[Rich Morin]

On Feb 4, 2013, at 15:15, Jason Lewis wrote:
> Significant white space is the most horrifying development in programming
> languages in the last 20 years.

Oh, I think it has some competition there (but mostly agree).


> Please kill this thread.

There, I disagree. Clojurists should be open to the idea of syntactic
experimentation, even if they don't personally like the direction.

-r

--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume r...@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Software system design, development, and documentation

[Gabriel Perdue]

On Feb 4, 2013, at 5:33 PM, Rich Morin <r...@cfcl.com> wrote:
>> Significant white space is the most horrifying development in programming
>> languages in the last 20 years.
>
> Oh, I think it has some competition there (but mostly agree).
>
>
>> Please kill this thread.
>
> There, I disagree. Clojurists should be open to the idea of syntactic
> experimentation, even if they don't personally like the direction.

Are you suggesting people not be so cloje-minded? :)

pax
Gabe

[Mikhail Kryshen]

The problem of readability of S-expressions has been discussed since the
beginnings of Lisp.

Some known alternative notations:
http://en.wikipedia.org/wiki/M-expression
http://readable.sourceforge.net/

Mikhail

[Leonardo Borges]

Honestly I find myself missing S-Expressions in other languages now.
The structure they provide is extremely useful in my opinion -
especially when writing macros.

Also, syntax is only one of the many facets of Clojure - if all the
benefits and features Clojure provides doesn't cut it for newcomers, I
doubt a python-like syntax will do. In the end, Syntax is just that.
Syntax. People get over it. (Even thought I still think S-Expressions
ARE a feature.)

In the end, have newcomers program in a bastardised version of
lisp/clojure to only then have them deal with S-Expressions misses the
entire point.

my 2c.

Cheers,
Leonardo Borges
www.leonardoborges.com

[Josh Kamau]

I love the parenthesis.... please dont take them away ;)   I dont want to learn a language syntax. I want a language "without a syntax" . And thats why i love clojure . 

Josh

[Dave Sann]

The syntax does complect in one case. 

When you really do want a list as opposed to a function call. hence quote and (list ...)

[Softaddicts]

If you just think about the impacts of removing the top most parens and how you
could hide this to tools like macros that may fiddle with your sexps you can only
conclude that such a change is unlikely to happen. Plus changes to the compiler, IDEs, etc ...

Phthon has the following delimiters:

http://docs.python.org/release/2.5.2/ref/delimiters.html

Clojure uses (), {}, #{}, [], quote, (.), back-quote, %, #, #', #"", #(), \, ;, @, ^, ~, ~@ and _.
Maybe missing a couple here but not much time tonight to browse doc.

Aside from the parens, the interop call and the reader macro specific literals,
most of them are syntactic sugar.

You can write (hash-map ...) instead of {} and so forth.
You can write closures using (fn [a b] ...), no need to use #() and %n to refer to args.

Which brings me to my point that Clojure has no more essential delimiters than python,
maybe less (no time tonight to count). Except maybe if you write macros on a regular
basis.

This obsession about parenthesis misses the objective, to have less noise in the syntax
of the language.

Why twist Clojure if people are really searching for a better alternative to the
language they currently use ?

What about the ones that want a real improvement over their current situation ?
Why offer them a dual syntax with all the potential mess that such an approach
offers ?

How matching an algol like syntax makes Clojure more "acceptable" ?
If people just fly away because they heard that Clojure has too many parenthesis before
seriously trying it, well, excuse my comment, it's a lame excuse.

They will probably prefer to stick to what they have at hand, the parenthesis being the
less scary feature of Clojure :)

Luc P.

> The syntax does complect in one case. > When you really do want a list as opposed to a function call. hence quote > and (list ...)
> > On Tuesday, 5 February 2013 07:06:37 UTC+11, tbc++ wrote:
> >
> > Parens actually don't complect, they have a very very clear meaning. They > > organize functions and arguments. Let's take one line from your example:
> >
> > filter smaller xs
> >
> > So....is that the python equivalent to which of these?
> >
> > filter(smaller(xs))
> > filter(smaller, xs)
> > filter(smaller(), xs())
> > filter(smaller(xs()))
> >
> > I would also assert that Python complects formatting and semantic meaning > > of the code. I'm quite proficient at Python and even I hate that fact > >

> > Timothy
> >
> >
> >
> > On Mon, Feb 4, 2013 at 1:01 PM, Sergey Didenko <sergey....@gmail.com<javascript:>

> >> To post to this group, send email to clo...@googlegroups.com<javascript:>

> >> Note that posts from new members are moderated - please be patient with > >> your first post.
> >> To unsubscribe from this group, send email to

> >> clojure+u...@googlegroups.com <javascript:>

> >> 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 unsubscribe from this group and stop receiving emails from it, send an > >> email to clojure+u...@googlegroups.com <javascript:>.

> >> For more options, visit https://groups.google.com/groups/opt_out.
> >>
> >>
> >>
> >
> >
> > -- > > “One of the main causes of the fall of the Roman Empire was that–lacking > > zero–they had no way to indicate successful termination of their C > > programs.”
> > (Robert Firth) > >
> > -- > -- > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- > You received this message because you are subscribed to the Google Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> > > --

Softaddicts<lprefo...@softaddicts.ca> sent by ibisMail from my ipad!

[Gregory Graham]

I used to be a big Python user, and I liked the use of whitespace for structure back then. The only time it caused me a problem was when cutting and pasting code fragments, which didn't happen very often. Now that I've been using Racket (Scheme) and Clojure for a while, I like the parentheses better. My only complaint is that I have to press the shift key to type them.

I'm also teaching Racket to High School students. The simple regular syntax of Racket is much easier for them to learn than Java, which I taught a couple of years ago. They seldom have problems with syntax errors in Racket, but they did all the time in Java. Teaching with Racket, I can focus on logic and design rather than syntax. Since most of my students have done very little programming before, they are not scared by the parentheses.

So, I've come to the conclusion that parenthesis-hate is just prejudice. Lisps don't look like the languages people already know. Python actually fights the same kind of problem with people who come from the C/Java world because significant whitespace is different from what they are used to. And in the old days when I first learned C, most people were used to Fortran, Cobol, Basic, and Pascal, and they complained about the curly-braces and terseness of C.

If someone wants to create a no-parenthesis version of Clojure, that would be fine, but it wouldn't be Clojure. Many of the good qualities of Clojure would work in a non-Lisp language, and it might develop a following. However, I don't think you will find many people who currently like Clojure to be interested in doing the work because they probably like the parentheses. Why should they spend time creating another language when you like what you have?

[Rich Morin]

On Feb 4, 2013, at 19:49, deliminator wrote:
> Long story short: want more people to love lisp?
> Implement paredit for more editors.

+1!

[Lee Spector]

On Feb 5, 2013, at 12:15 AM, Rich Morin wrote:

> On Feb 4, 2013, at 19:49, deliminator wrote:
>> Long story short: want more people to love lisp?
>> Implement paredit for more editors.
>
> +1!

-1

Just another data point and YMMV, but I've long loved Lisp and long hated paredit. I do agree, however, that editor features are key. For me, what makes the difference is bracket/parentheses *matching* (showing what matches what, but not typing for me) and good auto-reindentation. In my experience those features make it so obvious what the code structure is that it's simple to keep things balanced correctly. Paredit, however, goes too far by thinking it knows more than I do about what I want to type when, and gets in the way when I want to type my ideas in a weird order and/or cut/paste unbalanced things, which I basically do continuously.

FWIW I also teach new programmers Lisp with some regularity, and I don't get the sense that parentheses are ever a big issue (in the context of the editors that I provide, which always have bracket matching and auto-reindentation -- yes, it' d be great for those to be more ubiquitous). On the other hand, defeating students' existing typing/cutting/pasting habits, or making them deal with emacs arcana: problems.

Again, YMMV!

-Lee

[Shouxun Yang]

When I taught myself Scheme and Common Lisp more than ten years ago, I
didn't have any problem with the parentheses, probably because I just
learned a little bit of C/C++ or Pascal (Delphi) and were eager to
learn Emacs (one of the two major editors in the Unix/Linux world)
when I switched to the then emerging free GNU/Linux OS from
virus-ridden Windows.

I believe if one is ready to learn new things and has access to
capable editors, parentheses won't be the real block. Of course,
saying this won't solve the problem Sergey meant to solve.

This problem has been raised numerous times and there have been many
attempts to remove the parentheses in Lisp languages for those not
getting it. Dylan could be considered as one of the most fruitful one.
Dylan, as you know, has not been a mainstream language all the same,
probably due to bad luck when Objective C was chosen instead for Mac
development before it really got off.

Anyone who is interested in implementing such a system is welcome to
go ahead and experiment, though the result may not be that
encouraging, given the history in Lisp languages.

Also, it seems that alternative syntax for other languages, such as
the revised syntax for OCaml, is difficult to gain widespread use and
even fragments the user community in some way.

Just some random thoughts.

[Stefan Kamphausen]

A simple workaround I've considered, but haven't gotten around to doing anything about in e.g. Emacs, is to simply tone down the parens visually in the editor.  Hierarchy of color, size, contrast, etc. matters a lot in perception, and by making the parens slightly less obvious visually one's eye would be drawn to the actual functions more, "parsing" the parentheses only when several symbols exist on the same line.  Similar to what colorizing parentheses does - the color tells you more, if you pay attention to it.

you might be pleased with the look of parens, that rainbow-delimiters.el provides:

https://raw.github.com/jlr/rainbow-delimiters/master/rainbow-delimiters.el

[Herwig Hochleitner]

2013/2/4 Sergey Didenko <sergey....@gmail.com>

My point is to introduce a second-class syntax to attract orthodox
users. Definitely not migrating.

 

OK, I can see how I missed that point. I would say then: go ahead, transform a couple of clojure source files to that style and see, if you can lure someone orthodox out from under their rock with it.

_If_ it does work, a couple of orthodox users might just be the right catalyst to make clojure greater in an even faster pace.

They'll have their own syntax to play with. We'll call it "infix the reader". jk with that last part.

[Softaddicts]

Orthodox synonyms:

according to the book, acknowledged, admitted, approved, authoritative, buttoned-down, by the numbers, canonical, conformist, conservative, conventional, correct, customary, devout, die-hard, doctrinal, established, in line, legitimate, official, old-line, pious, proper, punctilious, reactionary, received, recognized, religious, right, rightful, sanctioned, sound, square, standard, straight, straight arrow, traditionalistic, true, well-established

Good luck :)

Luc P.

> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

[Mikera]

Please No!!

I don't think it would help newcomers at all - it takes only a few days to get used to s-expressions. Coming from a C/Java world I found significant whitespace in Python to be just as much of a mental leap. And it would cause enormous confusion if two different syntaxes were in use.

But more importantly from a language design perspective, replacing an extremely flexible, general purpose code block delimiter with significant whitespace is an extremely backwards step. With s-expressions, you are free to format your code for clarity, using whitespace to display the code in the structure that makes most sense to humans while leaving the parens for the machine.

If you lose the parens, you lose the semantic structure of the code and introduce significant ambiguity.

Just to prove the point, what does the following evaluate to?

   and true or true true not true

I'd really hate to debug code with ambiguous execution order like that......

As the icing on the cake, losing the parens would make Clojure editors much less effective. Being able to select / cut / move whole s-expressions based on paren-matching is one of the key productivity advantages when editing Clojure code, we certainly wouldn't want to lose this.

[Marco Munizaga]

We had this talk with scheme. They called it I expressions. Here is the link http://srfi.schemers.org/srfi-49/srfi-49.html

Do it because you can, and so you can decide for yourself what to think about it.

[Chris Ford]

If someone does write a Lisp with significant whitespace, can we please call it "Whitespathe"?

On 7 February 2013 10:30, Marco Munizaga <drch...@gmail.com> wrote:

We had this talk with scheme. They called it I expressions. Here is the link http://srfi.schemers.org/srfi-49/srfi-49.html

Do it because you can, and so you can decide for yourself what to think about it.

[Softaddicts]

Having worked with a number of languages sensitive to white spaces including
"magic" columns reminiscent of the paper cards, I honestly do not find any
sex-appeal in a syntax relying on spaces, line breaks and indentation.

It's error prone, errors are harder to detect, and breaks the tool chain.

As far as this alternate proposal, I find the end result ugly at best.
It does not favor a compact coding style which I have chosen years ago
after stopping using the older languages above which did not allow me to be
concise.

Mixing both styles together does not do anything to dissipate this repulsion feeling.

Frankly, I do not catch it, I have been working in at least a dozen languages
and half a dozen assemblers dating back to Fortran and Cobol, older Lisps,...
Working I said, not as a hobby.

I never tried to bend a language to my previous habits. I adapted and made my
playground within the limits imposed by the language, that's it.

Are these discussions about parenthesis a sign that humans cannot adapt anymore
and truly try new concepts before judging their merit ? In a decent amount of time ?
It took me three months to adapt to Clojure while writing production code and
I started at ... 47 years old.

It's like if this parenthesis issue is the end of the world.

What will happen the day Earth suffers a major blow (The aftermath series) ?
Insects will pick up were we left ?

http://www.banquedessinee.be/all--21-58.html

No need to understand french, just look at the last picture of the page...

Sorry for the rant but I find these discussions a bad use of our life time.
There is so much to do aside from nit picking on parenthesis....

Luc P.

[Jason Lewis]

`quote` is a feature, not a bug. Its not just for distinguishing between lists and function calls, its for deferring evaluation. Its also been part of Lisp since the beginning... IIRC, its in McCarthy's paper that defined the first lisp.

[Herwig Hochleitner]

On Feb 4, 2013 7:58 PM, "Dave Sann" <dave...@gmail.com> wrote:

The syntax does complect in one case. 

When you really do want a list as opposed to a function call. hence quote and (list ...)

The evaluation rules are clojure's implementation of reduction in lambda calculus.

Every clojure form has an associated evaluation rule. 

So syntax and semantic are already complected from the start. Otherwise we wouldn't call it a language.

 

On Tuesday, 5 February 2013 07:06:37 UTC+11, tbc++ wrote:

I would also assert that Python complects formatting and semantic meaning of the code.

It does, however the mind of the typical human reader does too. I think that's the point of python.

In this sense, I think, making formatting significant is actually a good idea.

The reason we can still leave this thread now is:

- Python - style significant white space only works for code blocks

- It works great for python, because python is _an imperative language_

- In functional style, only let is consistently formatted as a block,

  hence blocks just don't work as the foundation of formatting

> filter(smaller, xs)
> filter(smaller(), xs())

This, btw, is the reason I have a bit of language envy towards haskell.

(with lazy evaluation, the difference between f and (f) vanishes)

cheers

[Dave Sann]

yes, I did not mean to imply otherwise.

[Laurent PETIT]

2013/2/7 Herwig Hochleitner <hhochl...@gmail.com>:

> On Feb 4, 2013 7:58 PM, "Dave Sann" <dave...@gmail.com> wrote:
>>
>> The syntax does complect in one case.
>> When you really do want a list as opposed to a function call. hence quote
>> and (list ...)
>
>
> The evaluation rules are clojure's implementation of reduction in lambda
> calculus.
> Every clojure form has an associated evaluation rule.
> So syntax and semantic are already complected from the start. Otherwise we
> wouldn't call it a language.
>
> On Tuesday, 5 February 2013 07:06:37 UTC+11, tbc++ wrote:
>>
>> I would also assert that Python complects formatting and semantic meaning
>> of the code.
>
>
> It does, however the mind of the typical human reader does too. I think
> that's the point of python.
> In this sense, I think, making formatting significant is actually a good
> idea.
>
> The reason we can still leave this thread now is:
> - Python - style significant white space only works for code blocks
> - It works great for python, because python is _an imperative language_
> - In functional style, only let is consistently formatted as a block,
> hence blocks just don't work as the foundation of formatting

To play the devil advocate, I'd say:

- almost any clojure.core macros / special forms can be seen as
introducing blocks: defns, fn, with-*, try, and so on ...

- it is true that people, that I admire and respect, that are great
minds, look at clojure code, and then disregard it because of its
syntax. This keeps annoying me. But I don't have a magical wand, so I
think I just have to live with it.
- What I've done in Counterclockwise is ease the pain and ease the
editing by : having rainbow parens, or grayed parens. This helps.
Also, of course, paredit, paren-matching, etc.
- From time to time, I've thought about adding a "read-only" mode for
viewing the code in the style depicted above (the Racket thing), but
it's not a priority (and I have no proof that it will help Clojure get
significantly more traction).

>
>> filter(smaller, xs)
>> filter(smaller(), xs())
>
> This, btw, is the reason I have a bit of language envy towards haskell.
> (with lazy evaluation, the difference between f and (f) vanishes)
>
> cheers
>

[faenvie]

>>A simple workaround I've considered, but haven't gotten around to doing anything about in e.g. Emacs, is to simply tone down the parens visually in the editor.

Just last week i was astouned how readable clojure is, when its proper indented and the parenteses are invisible. This insight came upon me by pure accident ... i embedded some clojure-code in my blog via github/gist and used a pygments.css that made clojure-parenteses visually disappear. it was really amazing ... the code looked very similar to phyton and was more human-readable ... just a note - no vote.

[Max Gonzih]

I can't understand how to distinguish where is function call and where is var in function arguments. Should it be indented too?

On 02/08/2013 01:14 PM, faenvie wrote:

>>A simple workaround I've considered, but haven't gotten around to doing anything about in e.g. Emacs, is to simply tone down the parens visually in the editor.

Just last week i was astouned how readable clojure is, when its proper indented and the parenteses are invisible. This insight came upon me by pure accident ... i embedded some clojure-code in my blog via github/gist and used a pygments.css that made clojure-parenteses visually disappear. it was really amazing ... the code looked very similar to phyton and was more human-readable ... just a note - no vote.

[Jason Lewis]

Unless the function is threaded (->), the function call is always in the car position in a list, the args are the cdr elements.

[vemv]

I like the parentheses better. My only complaint is that I have to press the shift key to type them.

You can always remap your keyboard / keyboard bindings. For example in emacs:

(define-key clojure-mode-map "9" 'paredit-open-round)

[Gregory Graham]

I like the parentheses better. My only complaint is that I have to press the shift key to type them.

You can always remap your keyboard / keyboard bindings. For example in emacs:

(define-key clojure-mode-map "9" 'paredit-open-round)

Thank-you, I'll try that. 

[Jason Lewis]

ITT: emacs users complaining about modifier keys.

Sorry, but as a Vim guy, I couldn't help laughing.

--

[Softaddicts]

<hyper><meta><super>:))))))

Luc P.

[Softaddicts]

For those too young to have seen this:

http://www.globalnerdy.com/2009/02/05/hacklabtos-lisp-machine-keyboard/

[Max Gonzih]

programmer dvorak is better :)

--

[sergey andriyaka]

Is there any readers that do this.
Python is great, it uses 2d and don't make us to live in one long line