This is classic Blub paradox. You don't feel like you need a feature until you start using it, at which point you start wondering how anyone can live without it. Tools you have available limit the thoughts you can have. That's why it's always good to look for better and more powerful tools :).

A couple weeks ago, though, I found myself in a situation where the user needed to be able to specify a filter, and the filter was going to be a tree of expressions, and the program had to take what the user specified and turn it into something the program could execute... and the filter tree looks a lot like an S-expression... hmm...

So I'm seeing something that could be done much easier in Lisp. It's still not a need for a macro, though (unless you're going to suggest that I use a macro to turn some user-writeable DSL into Lisp, and sure, it could be done that way.)

The idea with macros is to extend the syntax of the language to move the entire language to the problem domain, for example the html generating dsl pg and company used at viaweb (see his writing).

This distinction is not as profound today, imo, because languages have come a long way. Php didn't exist when pg and friends were doing viaweb, today templating html is old hat, but at the time specifying a dsl in lisp macros to dyanmcically generate html was quiet innovative.

In fact, I'm not sure I've heard of anyone who wrote any significant amount of lisp code and came away talking about parentheses. This seems to be mostly a reaction from people who've read a bit of Lisp without using it.

Then again, I just noticed that I type ( and ) with my third and fourth fingers, so maybe it would be worse if I typed properly :)

Plus, its whitespace-based syntax was used as an argument to not evolve the language, being one reason for why they haven't added proper anonymous functions.

I can't comment on LISP's parens much, for now it doesn't bother me, but Python's whitespace did and I tried liking it for about 3 years.

Concerning whitespace, serious (large) projects have a very specific style guide, which includes prescriptions on whitespace. Python doesn't add any extra restrictions to that and in other languages a mismatch between whitespace and braces is a frequent source of bugs, so significant whitespace avoids that as well.

Python has at least 3 features that are not needed in languages that have proper support for anonymous functions and that are more expression oriented:

1. for comprehensions

2. the with statement

3. decorators

You cannot work efficiently with higher-order functions until you have anonymous multi-line functions, period - also, Python's single-line lambdas would be a lot more useful if Python wouldn't have been so statement oriented, unfortunately in practice they are useless.

In regards to your points:

a) no, I don't buy that

b) ordering matters, we read code as we are reading text, top-down, left to right

> 1. for comprehensions

Off the top of my head Scala, Erlang, and Haskell -- all of which are "more expression oriented" than Python (and all of which have robust support for anonymous functions including multiline anonymous functions -- the latter despite, like Python, having indentation-sensitive syntax), all have comprehension syntaxes like Python's for comprehensions.

So, I'm not entirely buying the idea either that "being more expression oriented" or "having proper support for anonymous functions" eliminates the utility of comprehension syntax.

And yes, if Python makes it easier to work with higher-order functions and such combinators / operators become the norm, then we'll talk about 2 non-orthogonal and conflicting features.

Python is the only language I know that added for comprehensions before proper support for anonymous functions. All the other languages I worked with (including Clojure, to be on topic) had anonymous functions before the syntactic sugar built on top. Clearly Python has a problem here.

Wait, first you claimed that Python wouldn't need comprehensions if it had better anon function support, and now you've claimed that Python has a problem because it added for comprehensions before anon function support, even though languages with anon function support still find the need for for comprehensions.

You seem to be convinced that Python is wrong, but not really committed to any consistency in the reason that Python is wrong.

You can live without for comprehensions if you have good anonymous functions support. If Python adds better anonymous functions support, its for comprehensions will be conflicting and much less useful than in languages that had good anonymous functions support from the beginning.

Either way, Python will never get multi-line anonymous functions support, since it's first of all considered to be un-pythonic. So we're having this discussion for nothing - I fell out of love with Python some time ago, if you still like it than good for you.

You can live without either, as decades of C programmers have demonstrated. Both are beneficial, as theeir widespread popularity in newer language attests. Neither is a perfect substitute for the other, as the fact that they tend to be both present in many newer languages, rather than being exclusive.

> its for comprehensions will be conflicting and much less useful than in languages that had good anonymous functions support from the beginning.

I don't see the "conflict" asserted here. I've used Ruby fairly heavily -- which has, in the relevant sense, far better anonymous function support than Python (even though it has different quirks) -- and certainly as nice as Ruby blocks are, a clean comprehension syntax is pretty much the main thing I find myself wishing I had sometimes in Ruby that Python has.

And, sure, Python's comprehensions may be less general than, e.g., Scala's, but switching them to be monadic rather than iterator based doesn't require better anonymous function support, it just requires changing which protocol they depend on.

How do you define working "efficiently with higher-order functions"? Given that Python fully supports higher-order functions, I am really curious what you could mean. I didn't downvote you, but it may have to do with your pointed assertion here, without anything in the way of an argument.

As to "ordering matters"; sure, but as the functions a nontrivial program calls are inevitably described as a graph, they must necessarily be defined in some arbitrary linear order anyway.

    some_collection.where(x -> x.name == 'foo').sort_by(x -> x.age)

    nameIsFoo = x -> x.name == 'foo'
    getAge = x -> x.age
    some_collection.where(nameIsFoo).sort_by(getAge)

I wrote an elegant parser definition library, used for parsing specialized output of ... never mind.

It had hierarchic specifications (regular expressions etc) of parsing states, along with anonymous functions which stored away parsed data and sent the parser among different states.

New juniors could after a few hours use this to quickly parse complex text documents.

I cursed a lot while trying to port this to Python. :-( A dozen named sub-ten lines functions specified by names and referenced inside a parser structure? Just didn't work.

Edit: The point is, there are use cases where real lambdas are useful (except from map etc). It is just weird to argue otherwise.

I can live without multiline anonymous functions - but I'd make use of them if they did exist.

Scala sample:

      cache.get[String]("name").flatMap {
        case Some(value) => value
        case None =>
          database.query("names").head.flatMap {
            case Some(id, value) =>
              cache.set("name", value, 10.minutes)
                .map(_ => value)

            case None =>
              Future.successful("Anonymous")
          }
      }
 

      async {
        val cached = await(cache.get[String]("name"))

        cached match {
          case Some(value) => value
          case None =>
            val fromDB = await(database.query("names").head)
            
            fromDB match {
              case Some(id, value) =>
                await(cache.set("name", value, 10.minutes))
                value

              case None =>
                "Anonymous"
            }
        }
      }

Reduced visual clutter and better flow in reading code.

> For documentation purposes it's a) better to give something a name, b) have a multi-line function in a separate place instead of inline in the form of a lambda.

I disagree: if the only place its ever used is in a particular call to a higher order function, it reduces the difficulty of reading the code -- if its not a large multiline function -- for it to be directly in the call as a lambda. Having it named is useful (1) if it needs to be referenced more than once (DRY), or (2) if it is large enough that it breaks up the flow too much for it to be included in one place (which is a somewhat subjective cut-off, but for me 1 line is far below it.)

EDIT: That being said, I'm mostly fine with Python the way it is -- while I sometimes wish a way to fit multi-line lambdas without disrupting the rest of the language could be found, I'm not sure I can see a good way for it to work, and its not really essential.

http://vim.wikia.com/wiki/Indent_text_object

    def foo():
        do_this()
        and_this()
    

    def foo():
        if something():
            do_this()
        and_this()

(imagine a much bigger more complex example of the above function)

In large pieces of code this can be easy do. If you are forced to use parenthesis it's much more difficult to make this error. One could argue that experience prevents you from doing this but I have sadly found this not to be the case in practice.

By "parentheses" you mean delimiters, which create visible boundaries to defined areas in code. Parentheses are an example of delimiters, but not all delimiters are parentheses.

Bash has if ... then ... else ... fi

Ruby has if ... else ... end

C/C++/Java have (logical test) { controlled area }, nested to any practical depth.

And so forth. Python doesn't.

> One could argue that experience prevents you from doing this but I have sadly found this not to be the case in practice.

This is an argument against complex functions that do a lot, as opposed to breaking program logic up into smaller blocks that are easier to understand and control. The old argument against this practice was that a large function that did everything was faster than the same logic broken into smaller blocks. A modern compiler will generally prevent this from happening.

> This is an argument against complex functions that do a lot

Functions large and complex enough to make this problem significant seem to be the reality I have to deal with when programming in the large. It's only my opinion but a language feature that improves my real world experience at no cost is a bonus.

I wouldn't say "no one." I read comments regularly from people, usually students, who get into trouble with whitespace in Python, especially if they mix tabs and spaces in the same source file.

Though to be fair, there would be some people that use python day-to-day that don't like significant whitespace. I'd bet there'd be at least a few lispers that don't enjoy wrangling parens.

http://legacy.python.org/dev/peps/pep-0008/#tabs-or-spaces

Spaces are the preferred indentation method.

Tabs should be used solely to remain consistent with code that is already indented with tabs.

Python 3 disallows mixing the use of tabs and spaces for indentation.

Python 2 code indented with a mixture of tabs and spaces should be converted to using spaces exclusively.

When invoking the Python 2 command line interpreter with the -t option, it issues warnings about code that illegally mixes tabs and spaces. When using -tt these warnings become errors. These options are highly recommended!

I feel it's actually easier with parenthesis because with always well formed lisp you get the benefit of incredible tools like paredit-mode which make it easier to type than in other languages and I say this as someone who does full time c++ with a fair bit of python, javascript and html and I only do lisp stuff as a hobby.

Lisp is a building material, the expressions are objects, the syntax is object. You don't want to look at it, you want to model with it, live. And with the "metacircular" (sorry for the sophisticated looking lingo) mindset, you can program how you interact with it (protorefactoring ala paredit/redshank etc).

Most people can't judge s-exp properly because they're not playing with it only looking at dead printouts; and the few who does are using a textbuffer[1], avoiding one important programming rule : automate everything. Lisp syntax has a simple and potent programmable API giving you a lot of power for free.

[1] I even watched a lisper using emacs without paredit at a meetup and it was painful.

Whelp, now you have. Hi! :)

Although I sometimes miss the goodies homoiconicity brings, I much prefer the increased syntactic structure of other languages.

If your fingers are on the standard home keys (index fingers on "F" and "J"), '(' is between the middle and ring finger and on the normal (inward) path of the ring finger as it extends, ')' is between the ring finger and pinky and on the normal path of the pinky as it extends.

OTOH, if you keep your right index finger on the "K", which is less standard, then those become naturally on the middle and ring (and it may make sense for programming, but less for general typing -- the standard home position is based on where the letter keys are, but the extra symbols on the right are more used in programming than general typing, so moving the right hand one key out makes some sense.)

Many people seem to type it the way you have just suggested (middle/ring) - myself included. I'm currently re-training myself to do that properly.. it feels weird at first, but I'm starting to get the feeling it will actually be faster.

Your touch typing can always be better, right?

On the other hand, once you've tried the sweet honey of lisp macros, going back to C macros makes you sad. There's not a week that goes by without me being frustrated at the rudeness of C macros. Not to mention languages that don't offer a macrosystem at all. And the parens thing is a tired meme.

I agree with you for the diamonds though, very distracting.

I noticed the article mentions that some don't like calling syntax extensions macros because of the comparison to Common Lisp macros. To that, I say that's a crazy way of thinking. Macros are necessarily dependent upon the semantics of the language they are for, so anybody who thinks that all macro systems are identical are the people who probably wouldn't go out of their way to learn a language with a non-textual substitution macro system, so changing the name for that purpose seems foolish. On the other hand, syntax-extension or syntax-transformations are a more descriptive term on their own merits.

And yeah, the diamonds are silly. Better to just color the word.

Well, "need" is a strong word. I mean, you could probably argue, in a philosophical sense, you never needed to write any computer programs in the first place (plenty of people go through life without doing so).

However, it is very likely there were times in your life where having your code edit itself would have led to getting a program working in less time, with fewer bugs, or better performance. Which of these benefits apply, of course, depend on the problem you were trying to solve.

"So I just don't really feel the need to get repetitive strain injuries in my pinky from reaching for the parentheses all the time."

Um, no. Rich Hickey has pointed out idiomatic Clojure requires fewer parens than the equivalent Java.

About macros, in the case of C#, what, if not a kind of macro, is the 'using' statement that works with IDisposables? If it's useful here, why not in other places?

I hadn't even noticed that they're hyperlinks, I thought something had went wrong with the text formatting or character set!

I've literally never run across a situation where I needed my code to edit itself.

Needed to is too strong a statement. I've never needed to write a macro (and in Clojure, its somewhat frowned upon to write macros when normal functions will do), but sometimes it saves you from a lot of working around limitations (and every language has limitations). It also allows things to be added to the language as libraries that otherwise would have to be built in - the majority of programmers won't need to do this, but if you do, its awesome knowing that its possible. Clojure's core.async is an excellent example (Go-style goroutine's, as a library).

I've never run across a situation where the lack of an everything-is-an-expression-is-a-list feature prevented me from doing what I wanted to do.

Of course not, but you can also do everything you want in assembly. What everything-is-an-expression-is-a-list gives you is 1) uniformity - everything works the same way, so it lowers the cognitive load; 2) simpler code - if you need a statement in an expression, you can do so, and other languages don't prevent you from getting the same result - they just take more code, or the code is more complex, or you use less-than-ideal constructs, or...

So you never need these things, but they make life more pleasant to have them.

I just don't really feel the need to get repetitive strain injuries in my pinky from reaching for the parentheses all the time.

I program in Clojure fulltime and I don't find that it has any more parentheses than a language like C++ or Java does. On top of that, anyone who programs in a Lisp for a while will use some form of paredit, which makes working with parentheses a breeze to the point where I find I type less than I do in other languages because jumping between parentheses, splicing parentheses-enclosed lists, wrapping things in parentheses and such tasks are a single keypress that just isn't possible in other less-parentheses-focused languages.

In short, just like significant whitespace in Python, parentheses are a non-issue in practice (after a short adjustment period).

But at the end of the day, to each his own. If Lisp doesn't do it for you, then that's fair enough - you don't have to use it :-)

People see the parentheses and go crazy, but in fact it is just a matter of moving the opening parentheses.

I now use this approach when explaining Lispy languages to others.

I realize this is not necessarily the norm. But it was hilarious in context.

Echoing everyone else, basically, your other points are a bit shortsighted.

You never need code that edits itself - completely true. Completely missing the point. Most programming features fall into this category; you don't -need- them, you could always use assembly instead. The point is that once you get them into your brain as an option, problems that might otherwise be tricky or time consuming become much easier.

To that end, everything is an expression is a list...yeah, you don't need it either. But, assuming the above (that code that can edit itself turns out useful sometimes), imagine how easy it is to metaprogram when all your executable code is just a list, and you already know how to modify lists.

In either case, you don't -need- the feature, sure, but a moment's reflection might open up the possibility that once you fully grok the ramifications, and have it amongst your other programming tools, you'll find a good use for it.

As to too many parentheses, as someone else mentioned,

  foo(a, b, c)

  (foo a b c)

    c = sqrt(a*a + b*b)

    (setf c (sqrt (+ (* a a) (* b b))))

...I think operator precedence allows the removal of the parenthesis for at least: Ada, C, C++, D, Dylan, Erlang, Fortran, Go, Haskell, Icon, Java, Javascript, Julia, Lua, Mathematica, OCaml, Pascal, Perl, Prolog, Python, QBasic, R, Ruby, Scala, and TCL.

That's not an example of homoiconicity.

What?!?

Proper Lisps compile to native code, both JIT and AOT.

Plus there are quite a few code commercial compilers with networking libraries.

http://franz.com/products/allegrocl/

Don't judge Lisps by the open source alternatives.