With Lisp, I have honestly tried to find good documentation on its module system, and I have tried my best to understand the workings of ASDF, but when it comes down to it, I just don't have the time to muck around with stuff that is so much more difficult. The simple fact is that if I need to get something done, it's going to be in Python for the time being, and who knows when I'll get to the point where I'm not coding against a deadline, the point where I'll be able to waste some time really learning Lisp.

When I first came to Python I didn't need to become an expert Python programmer to understand Python source code without much effort. But I still haven't gotten to the point of looking at a piece of Lisp code and right away having an idea of what it does. Eventually your brain recognizes the patterns (but heck if you write assembly long enough you start to see the patters of common C control structures).

But I think it all depends on the problem at hand. Certain things I can write faster in Java than Python (occasionally static typing and interfaces can make large programs easier to keep in one's head and work with). Most things I can write easier in Python. And a few things I can write easier in Lisp (primarily writing programs that manipulate trees and essentially create mini-languages).

... used to C

You sound like an English speaker claiming that English is easier for people to understand than other languages. There's nothing intrinsically human about infix syntax. It's just a question of what you're used to. I honestly find prefix syntax (or lack thereof) much easier to read, because that's what I'm used to.

As a result more people find y=m * x+b easier than (let ((y (+ (* m x) b))) y) until they get the chance to spend some quality time with a REPL.

a.b().c().d().e() is easier to read to me than (e (d (c (b a))))

I also prefer object.method() instead of (method object). Now granted the OO model used in Lisp allows for some really powerful things (like methods that specialize on more than one object and adding before, after and around methods to modify code).

I sure find (e (d (c (b a)))) easier to read.

Here's why: In your first exemple "a.b().c().d().e()" you have to read up to the end to know what you are "really" doing, i.e. calling e() whereas in "(e (...))" up front I know the most important part: I'm calling function "e" on something.

The funniest part is even if you consider it from object perspective the message is more important at least to my view, even OO father Alan Kay thinks that too (see Computer Revolution has not happend).

As someone said before what we know condition us to what will be easier to read, to that I'd like to add that it is also "how we undestand thing". Sure I know C++/Java syntax better but the way I conceptualize OO is more through message than object...

Think about it this way do you like when you speak to someone and they start by a very lengthy introduction which you have no idea where it is leading to realise at the end that they were trying to sell you something? Or do you prefer to know up front and then listen for as much detail as you need before determining if you are interested or not?

It seems silly to demand science in a discussion of programming languages, but you're making some big assumptions about how human mind works. Considering how recent the discipline of programming is, and how fast it's evolving, what makes you think the designers of Python have discovered some immutable laws of the mind--ones that go against common sense, no less? (Common sense being that fewer tokens is better.)

This is a very easily testable theory.

That's almost identical to python, but how do you make it exactly identical? Nobody knows.

http://www.python.org/dev/peps/pep-3103/

Tested. Found false.

Now how about Scheme? I recently tested that myself by using a case expression, a syntax I rarely use. I didn't have to look in R5RS. I just put the parens where they would naturally go for the most obvious syntax tree, and it worked.

For someone steeped in Algol-like languages, Python will be easy to get started with. Scheme/Lisp takes longer to get started, but once you get it, you don't have to keep going back to the documentation. It just makes sense.

  case beercount
       0 1      "inanity"
       2 3 4    "good sense"
       else     "genius"

Your example falls short because case statements aren't such an obvious method of solving the problem as you think. They are nothing more than an artifact of the machine that C pushes up to you.

Concise? I've got some perl code for you.

  if beercount is 0 or 1 return "inanity"
  if beercount is in 2,3,4 return "good sense"
  return "genius"

It seems to me that what counts is not necessarily tokens of the programming language but rather "tokens" of the mental model into which a syntactical expression is translated. But what are the fundamental characteristics of those mental tokens and are they distinct tokens in the first place? We probably need to look to cognitive sciences to find out more about that.

What is pretty clear to me (admittedly through self observation) is that the brain likes to take shortcuts based on the context we preceive ourselves to be in. We see things in one context that we don't see in others even though they are there. So, basically, we form context specific mental models that filter the world and create a vocabulary of shortcuts that work efficiently in that particular context. Syntax can be a visual cue to invoke that context switching facility of the brain, for better or worse.

in other languages, you write weird things that get turned into trees, seemingly by magic.

other languages seem easier to understand, to most people. this is because they have a lot of experience with all that magic -- it has become a tradition. if you're better at normal languages, go ahead and use them. i don't care. but they are not objectively easier to read, they are much harder and more complicated.

Maybe people have an easier time understanding other languages because they work in the same way the computer does.

you don't need to know what your lisp gets turned into. you do need to know something about what tree your lisp, or infix math, or chained C functions, get turned into. you have to actually know which tokens go into which branches. you have to know what functions are being called on what tokens, in what order.

Personally, I find Lisp easier to write but much harder to read. The syntax certainly plays some role in that, but I don't think it's the key. The problem, I think, is that it's just too dense. When you use a lot of intermediate variables, you get to name them something relevant. But Lisp code (or at least my Lisp code) usually doesn't have all of this context floating around, so it's harder to figure out what's going on.

It's quite possible that the prevalent style of writing Lisp code is in some ways worse than the dominant style for C/java/etc. But that is a different issue than the language itself, which can, for example, create a bunch of name intermediate variables, if you want them.

The flexibility of Lisp probably makes it more suited to adapting to encourage naming data, over imperative languages encouraging MSFs. let/let* is a little clunky for simple things -- it reminds me a little of Pascal's variable declaration blocks. It would be better to do a sort of: (lambda (a b) (A <- foo a) (B <- bar A b) (Z <- baz B) Z) or optionally (return Z) instead of just Z, which macros to (lambda (a b) (baz (bar (foo a) b))))

It seems like the sort of thing that someone would already have implemented, but I don't recall it being a core feature anywhere.

Objectively easier to read? Thats a strange road to go down. Theres no reason that languages with grammars that generate strange and wacky trees might not suit a human's ability to describe formal solutions better. I think the reason people find languages like C easier to understand is all in the state handling anyway.

That's not the issue - the issue is that lisp folk can easily write programs that manipulate their code. Other folks have to get a parser involved.

In most cases, that means that people who write programs in "not lisp" rarely have automated methods for manipulating their code. They don't define dsls. They have macros weaker than regular expressions.

Programs have a lot of structure that can't be exploited without being able to manipulate code.

and that is basically what i mean about lisp being objectively easier to read: the notation actually works better. so you can nest a lot and it doesn't get horrible. but also, you don't have to, and then it's about the same.

something about C/etc is bad for nesting heavily.

Edit: example. both lisp-style versions are nicer. if C has advantages, it isn't in making state work better.

  (def avg (numbers)
    (/ (sum numbers) (count numbers)))
  
  (def avg (numbers)
    (= total-number (sum numbers))
    (= total-count (count numbers))
    (= result (/ total-number total-count))
    result)
  
  function avg (numbers) {
    /(sum(numbers) count(numbers))
  }

  function avg(numbers) {
    =(total-number sum(numbers))
    =(total-count count(numbers))
    =(result /(total-number(total-count))
    result
  }

(+ 3 4 (- 1 (/ 3 4)) (* (- 9 2) 8 3))

+(3 4 -(1 /(3 4)) *(-(9 2) 8 3))

why oh why would you want a function to be in the same grouping (set of paren) with arguments to another function, instead of grouped with its own arguments?

the less you nest, the less it matters. but it is not a matter of taste which way makes more sense and scales better.

You could make a language that had very lisp like syntax but didn't support things like lists and lamda functions and it would equally clearly define a tree. That language would be just about completely useless.

if infix is C's advantage, that is pretty silly. because first of all there is only a limited number of infix operators, and when you make your own constructs they are prefix, but different from s-expressions in the kinda silly way i illustrated.

anyway, you can put infix into a lisp. people don't usually want to because it kinda sucks. unless you're working in certain domains.

infix means:

- memorizing order of operations and remembering it whenever reading code (does == or && have higher precedence? they didn't drill that one into us in middle school, so it doesn't feel quite so obvious as arithmetic order of operations)

- losing characters for use in identifiers

- commas in argument lists

- paren for changing order of operations

- functions that take a predefined number of arguments that has to be 1 or 2

- infix only works with a limited number of built in things, it doesn't scale nicely. i suppose you could change this, e.g. make # a special character, and then you can define infix foo then write arg1#foo#arg2. but like, that's ridiculous. no one wants to do that with functions in general. they only want to do it with math because they hate math and don't want to have to understand anything about it, they just want to use it mechanically like they memorized in school.

- infix is an approach with less generality

(plus 3 4 (minus 1 (divide 3 4)) (times (minus 9 2) 8 3))

plus(3, 4, minus(1, divide(3, 4)), times(minus(9, 2), 8, 3))

Anyway none of this has anything to do with the assertion that people only use explicit state in procedural languages because the languages don't support nesting well. I prefer functional programming to procedural but that doesn't ring true for me at all. As a matter of fact I prefer functional languages that don't have lisp's bracketing syntax.

  (sum 3
       4
       (difference 1 (division 3 4))
       (product (difference 9 2) 8 3))

P.S. The way to pronounce the < function is "ascending".

It's logically consistent with how the rest of the system works, but it sucks because having to unlearn anything sucks. Personally, I just imagine it being rewritten as infix.

The "ascending" tip is from experience. It's really easier than moving operators around in your head.

The human mind is good at overloading operators. Especially since the infix < never appears after an open paren, it takes little time to teach yourself to read it as "ascending". It even looks small on the left and big on the right, visualizing an ascending list. Once you learn it that way, shortcuts like (<= 1 n 10) to see if a number is between one and ten come naturally.

Really, the problem is that a small amount of whitespace can change the meaning of the code.

(< 1 2) => #t

(<1 2) => #f

...for a convenience function <1 that semantically means "is less than 1". Maybe you wouldn't define such a function, but having to think about it at all or having to mentally redefine < somewhat validates the idea that the syntax here is a stumbling point.

you could also change the argument order, but that's probably not a good idea :)

edit: and state is not only used to avoid nesting. that is just common. i do it myself in ruby. too much chaining stuff is confusing in ruby, even with OO shortcuts (which are how people actually avoid using the crappy function call syntax too much, even more than via infix math). so you save to a variable and split it up.

Some infix languages have a mechanism for defining new infix operators.

     infix only works with a limited number of built in 
     things, it doesn't scale nicely. i suppose you could
     change this, e.g. make # a special character, and then
     you can define infix foo then write arg1#foo#arg2. but
     like, that's ridiculous. no one wants to do that with 
     functions in general.

Additionally, you don't have to have an arg1#foo#arg2, as long as you're willing to use spaces to separate things, the way that lisps, forths, and so on do.

x foo y

over

foo x y

? well, right or wrong, you are definitely deviating from the mainstream. that is, C and java coders will agree with me that prefix, and unlimited arguments, is better. the only difference they'll do in the general case of function calls is to add commas in the argument lists, and move the open-paren to the right one token.

i think not using infix function calls has nothing to do with why people are put off by s-expressions.

No. Nowhere am I advocating that. Rather, I'm pointing out that it's not an obviously ridiculous idea -- people have implemented it, and some people like it.

"i think not using infix function calls has nothing to do with why people are put off by s-expressions."

I disagree; I think it is one reason.

and infix function calls in general is obviously a bit ridiculous because it doesn't scale. why would you want all functions to take 2 arguments? or were you going to

(a b foo x y z)

for a function of 5 arguments? and memorize which side to put the extra one on, and what order they go in, etc?

There are a number of possible solutions to your question about infix functions. In J, insofar as I understand it, all functions take either one or two arguments, but the arguments can be arrays, so you often get the effect of more than two arguments.

For example (it's been a while) the form * / 2 3 4 would have the function *, the function /, and an array or list of three integers. J is parsed right to left, so the array is collected first, and then there's a modifier function '/' which takes two arguments: a function on the left, and an array on the right, and applies the function to each of the elements of the array (like map in lisps), outputing the new array. I don't know the details anymore of which symbols are what primitives, but J is interesting, in my opinion.

Alternatively, for your example, you might do

    (a b) foo (x y z) ; or
    (a b, foo, x y z) ; or
    a b Foo x y z     ; if functions have their own
     naming rules like in Erlang, or
    a b foo! x y z;   # where the bang means call, or

If you code Lisp long enough does your first expression becomes as natural to read as my expression is for me?

  (+ 3
     4
     (- 1
        (/ 3 4)
     (* (- 9 2)
        8
        3))

Also, a lot of math is prefix: f(x,y) ; d/dx (...) etc..

And I've never really had a hard time with reading arithmatic, so the debate really leaves me scratching my head.

Infix looks reasonable until one has more than 2 operators. Then people start making mistakes. To combat those mistakes, they start parenthesizing. The number of mistakes goes down but there's still confusion. (Some folks know more precedence levels than others and many folks think that they know precedence levels that they don't know.)

However, in every field besides this niche of computer science, including almost all of math, finance, science, and engineering, infix is used. This means that it is at least good enough and I suspect it has advantages.

Many math operations really are just fundamentally unary or binary. Generalizing - or / or x^y or mod to lists is just silly as far as I can see, and adds confusion. I don't need to see parens around the outermost operation. For the two most common associative operations, + and *, order of operations is quite good enough and it has the advantage that everyone since grade 6 has been working with it.

(I'll give you that there are very many cases where list notation is great, but I don't think it's common that they help very much in science, business, or engineering.)

The reason is that the "reader" in all of those domains is another human and humans do error correction almost without thinking.

Also, each of those domains has a very small number of operators - programming languages have lots of operators.

Feel free to demonstrate that you know the precedence/associativity rules for your favorite programming language by typing them without looking them up. (I know two people who can do that for C; the vast majority can't.)

Code is read by human beings too (perhaps just the person who wrote it) and more find infix arithmetic more natural looking.

I see the appeal in the idea that arithmetic is really just a very special case of a programming structure and should be treated as such, but on the other hand, I and many others can instantly see what a + bc/d - d(e+f)*g means and would like equation-heavy pieces of my programs to somewhat resemble equations everywhere else in life.

Does you have the quadratic formula memorized in list notation? How about the sum of an arithmetic or geometric series, or a formula for an inverse square law force?

Programming isn't math.

> Code is read by human beings too (perhaps just the person who wrote it) and more find infix arithmetic more natural looking.

And that's how infix causes bugs. The human reader error corrects and the compiler doesn't.

My goal is correct programs. What's yours?

Lisp notation eliminates a whole class of bugs.

Bugs are expensive - what are you getting for the ability to have more of them?

> I and many others can instantly see what a + bc/d - d(e+f)*g means

Really? It has at least two meanings. Which one is correct?

Yes, I do memorize formulas in a form that doesn't allow for precedence/associativity errors. Why I should prefer a form that does allow for such errors?

In the general case of complex logical and bitwise expressions, order of operations can cause a tremendous number of bugs. I like to use parentheses to make these cases absolutely unambiguous anyway. But I can't remember introducing a serious bug because I messed up order of operations between +- and X. Anyway, if it's such a problem, there's nothing to say you can't put parentheses around every operation in infix notation, at least in any language that I know of!

Maybe my preference relates to having a fairly visual memory for formulas and such. If I want to find a root of a quadratic equation, I do (-b + sqrt(b * b - 4 * a * c))/(2 * a), and that is easy, and anyone with high school math sees that in someone's code they know what it is. (I probably have to check for a zero denominator and also look at the discriminant unless I'm directly using complex numbers, and there's also the conjugate root, but that doesn't change much.)

If I have to write (/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a)) then I can do it, but it takes a lot of thought and it doesn't go along with the way I think about the quadratic formula. Granted, this is because I learned it the way I did, but I also know I'm not the only one.

A footnote to that is that to my mathematical sensibilities, in list notation, using the same symbol for negation and subtraction is hideous!

Most of us have to read code written by other people. Those other people don't have exactly the same precedence defense habits that we do.

No, we don't have to end up in the nasty middle ground where the paretheization is inconsistent and buggy, but we do. Since the "infix is good" theories and argument predict otherwise, how much weight should we give them?

I believe what is popular right now with new calculator buyers are the versions of the TI-83 and TI-89 with USB connectors and faster processors, I think they're called the TI-84 and TI-89 Titanium.

If one works in multiple languages, the only safe thing is to ignore precedence and associativity and parethesize everything.

what i am used to is * and / first, then + and -.

And then there's associativity. It doesn't much matter for * and +, but it matters a lot for / and -, and if you think that * and / have the same precedence, it matters for .

And, you're continuing to ignore the fact that there are far more infix operators. Even if infix worked for +-/, that doesn't tell us that it works when there's .,->,<, &, ?, %, $, #, @, ~, ^, |, \, =, and so on (such as digraphs).

No language that uses infix has resisted the temptation to extend it past the point where it causes more problems than it solves.

I believe I posted a comment pointing out that lots of people aren't completely sure, offhand, if && or == has higher precedence.

And even in this branch of the thread, when I said he could have omitted some of the parentheses, I didn't mean to say infix is powerful because it can use less parenthesis. it gets rid of them with a dirty trick that doesn't scale. What I was pointing out is that people don't actually know the infix precedence rules by heart (like they try to say they do. they say it's so natural...). so they end up putting parenthesis frequently just cause they aren't sure.

Absolutely the libs make the difference. [0] But are there other forces going on that limit language choice and adoption?

I'm thinking of say Perl. Perl has CPAN, which kicks pythons pants , hands down when it comes to the variety of usable tested modules. Is it the Perl syntax or core language that scares off the hackers?

My own pet theory is that it's not the hackers who ultimately decide the language(s) they use at work. Additional libs don't matter as much as the initial (fad) language the code base is written. It is the companies (and PHB's) that hackers ultimately work who determine language choice. In the end hackers just give up.

One more reason to "start a startup". You can choose the best tool(s) for the job.

[0] A friend of mine, a strictly "ANSI-c" man wondered how I could code the rings off him. Then I showed him the Python libs I could choose from. He had to download the source code, compile it, learn how to use it at 'c' level and then do the job. For example regular expressions.

Most companies I know actually asked their developers which language they should choose. Typically there is a decision eventually to concentrate on a limited set of languages, but choosing that or those languages is not usually being done without consulting the developers.

It does require dev's have to be better programmers. There are plenty of ways to make Perl code safe. Maybe you have to work harder at it?

"... Typically there is a decision eventually to concentrate on a limited set of languages, but choosing that or those languages is not usually being done without consulting the developers ..."

I agree with the limiting of languages. But I've yet to see languages chosen purely for good technical reasons. [0] And this is one reason I think Lisp gets pushed out.

[0] PHB's dont like you re-writing code from scratch so you could be forced to work with what ever was previously chosen ~ http://www.joelonsoftware.com/printerFriendly/articles/fog00...

C is beautiful for what it is. Pure. Running on the metal.

And LISP too is beautiful for what it is. Running on abstractions.

The rest are all kind of in between.

Thanks.

Just ask ~ http://news.ycombinator.com/submitted?id=lisper

This was written in 2002FEB and pre-dates the reddit rewrite from lisp to python.