9 ms·

As an old lisp fan, I never got this. (f x) and f(x) have the same number of parenthesis. and the nice thing about (f x) is that the parenthesis group f with x

As an old lisp fan, I never got this. (f x) and f(x) have the same number of parenthesis. and the nice thing about (f x) is that the parenthesis group f with x; so you have the whole call inside the (). Consistent and simple to understand. vs i.e. print(f"a string"), where it isn't even clear that the "f" is a function call.

junon 4y ago
That's the joke. The number of terms doesn't change, and the last two have the same number of parens. The statements relate quantities of those things as though they're a problem, when in reality the "just right one" only changes the order slightly. Hence the joke. It's one of those jokes that earns a loud sigh from me, rather than a chuckle.
YetAnotherNick 4y ago
> (f x) and f(x) have the same number of parenthesis. That's the joke
- quickthrower2 4y ago
  I have heard that if you count { and ( as parens, a Java program for example has just as many parens as. lisp one. A lisp paren can do both jobs: expression and scopes.
  - layer8 4y ago
    > A lisp paren can do both jobs: expression and scopes. Using different symbols for different purposes makes sense, it helps humans to parse correctly faster.
    - gorjusborg 4y ago
      Sure, why care about splitting algorithms into functions and naming them appropriately when you can just write it all in a 3k line function.
    - kazinator 4y ago
      That's right, which is why the parenthesis is combined with a leading symbol like (let ...). Mainly, you don't look at the parenthesis when reading; you look at that let and your eyes rely on indentation for structure.
      - hyperhopper 4y ago
        Okay, but now you have to look at more things. Also, the ending paren doesn't have anything to help you see what it is on its own.
        lispm 4y ago
        Just ignore the parentheses. Setting them to the background color may enforce that.
        kazinator 4y ago
        You're not supposed to look for ending parentheses in Lisp; getting the right number of them is more or less your editor's job, and they are maximally stacked together like this: )))), as much as the given nesting and indentation permit. Given some (let ..., the closing parenthesis could be the third one in some ))))) sequence; you rarely care which one. If it's not matched in that specific ))))) sequence where you expect, then that's a problem. )))) is like a ground symbol in a schematic: (+5V (+10V (-10V (INPUT3 ...)))) ----- local "ground" for all the above (different circuit)
        layer8 4y ago
        That doesn’t seem very user-friendly. ;) Or at least that’s always my perception when programming Lisp. As a side note, I believe that different people fundamentally have different programming languages that objectively suit them best, due to differences in their respective psychology and way of thinking and perceiving. It’s interesting to discuss trade-offs, but in the end there is no single truth about which language is better overall — it depends on the task and on the person. There’s no “one size fits all”. What’s valuable is to understand why a certain syntax or language might work better for certain people.
    - quickthrower2 4y ago
      It does, but there are still many different purposes. In JS: ( can mean: function call, part of an expression to be evaluated first, regex capture group { can mean: scope [of ... loop, if, lambda, function etc.], object definition, string interpolation code i.e. ${..}, class definition There are probably other things I am not thinking of. The one that trips me in JS is code like x.map(v => {...v, v2}) breaks because the compiler sees the { as the beginning of a scope, not the object definition I intended. The working solution is x.map(v => ({...v, v2})) But x.map(v => v+1) is allowed. I don't think the compiler could figure out what you meant because an object definition might be a lambda function body. For example { myvar } can be both an object definition, and a function that returns myvar.
  - lptk 4y ago
    That's obviously nonsense. Java, one pair of parens: int x = 1; int y = x + 1; System.out.println(y); Clojure, six pairs of brackets: (let [x 1 y (+ x 1)] ((. (. System out) println) y))
    - deleted 4y ago
      [deleted]
layer8 4y ago
> the nice thing about (f x) is that the parenthesis group f with x The drawback is that they are put on the same level, whereas in most people’s minds the function is a fundamentally different thing from the argument(s). The “f(x)” syntax reflects that asymmetry.
- agumonkey 4y ago
  What creates that distinction ? in the lisp / fp world you quickly stop considering functions as separate entities.
  - layer8 4y ago
    The function represents the operation or computation you want to perform. The arguments represent inputs or parameters for that operation or computation. Of course, theoretically you could also view the function as a parameter of the computation and/or the arguments as specifying an operation (in particular if those are also functions), but for most concrete function invocation that's not generally the mental model. E.g. in "sin(x)" one usually has in mind to compute the sine, and x is the input for that computation. One doesn't think "I want to do x, and `sin` is the input of that operation I want to do". One also doesn't think "I want to do computation, and `sin` and `x` are inputs for that computation". It's why you may have mentally a sine graph ranging over different x values, but you don't imagine an x graph ranging over different functions you could apply to x.
    - agumonkey 4y ago
      But even in high school topics start to talk about functional equations (calculus, e/ln). I'm not sure the <function> vs <value> doesn't come from the mainstream imperative paradigms and only that.
      - tikhonj 4y ago
        The distinction isn't between functions and values in general, it's between the function being called and the arguments passed to the function being called. The difference isn't in the things themselves, it's in the role that they play in the specific expression we're reading.
agumonkey 4y ago
I wish we had stats about sexps (we shall call it the kinthey scale). As a kid what you said was the first thing my brain caught on. It compresses the number of things I had to remember it's ~always (idea arguments...). We can now discuss interesting problems.
- throwaway17_17 4y ago
  I had the same feeling when I first started using a lisp (which was Scheme to work through SICP and the Ableman&Sussman MIT course). I was utterly entranced by the simplicity and uniformity. It was absolutely a factor in the way syntax works in my personal language (which I use for almost everything in my day to day). I really do agree that learning a lisp can truly expand the way in which a dev views and thinks about code.
  - agumonkey 4y ago
    Brown university PLT labs also vouched for this approache. Their textbook starts with a descriptions of sexps as syntax saying that's the only parsing theory covered here.
hota_mazi 4y ago
It's a stupid joke. The negative reactions that a lot of people have toward Lisp's parentheses are not because of the call function syntax but because parentheses are used everywhere else in Lisp's syntax.

junon 4y ago

That's the joke. The number of terms doesn't change, and the last two have the same number of parens. The statements relate quantities of those things as though they're a problem, when in reality the "just right one" only changes the order slightly. Hence the joke. It's one of those jokes that earns a loud sigh from me, rather than a chuckle.

YetAnotherNick 4y ago

> (f x) and f(x) have the same number of parenthesis. That's the joke

quickthrower2 4y ago
I have heard that if you count { and ( as parens, a Java program for example has just as many parens as. lisp one. A lisp paren can do both jobs: expression and scopes.
- layer8 4y ago
  > A lisp paren can do both jobs: expression and scopes. Using different symbols for different purposes makes sense, it helps humans to parse correctly faster.
  - gorjusborg 4y ago
    Sure, why care about splitting algorithms into functions and naming them appropriately when you can just write it all in a 3k line function.
  - kazinator 4y ago
    That's right, which is why the parenthesis is combined with a leading symbol like (let ...). Mainly, you don't look at the parenthesis when reading; you look at that let and your eyes rely on indentation for structure.
    - hyperhopper 4y ago
      Okay, but now you have to look at more things. Also, the ending paren doesn't have anything to help you see what it is on its own.
      - lispm 4y ago
        Just ignore the parentheses. Setting them to the background color may enforce that.
      - kazinator 4y ago
        You're not supposed to look for ending parentheses in Lisp; getting the right number of them is more or less your editor's job, and they are maximally stacked together like this: )))), as much as the given nesting and indentation permit. Given some (let ..., the closing parenthesis could be the third one in some ))))) sequence; you rarely care which one. If it's not matched in that specific ))))) sequence where you expect, then that's a problem. )))) is like a ground symbol in a schematic: (+5V (+10V (-10V (INPUT3 ...)))) ----- local "ground" for all the above (different circuit)
        layer8 4y ago
        That doesn’t seem very user-friendly. ;) Or at least that’s always my perception when programming Lisp. As a side note, I believe that different people fundamentally have different programming languages that objectively suit them best, due to differences in their respective psychology and way of thinking and perceiving. It’s interesting to discuss trade-offs, but in the end there is no single truth about which language is better overall — it depends on the task and on the person. There’s no “one size fits all”. What’s valuable is to understand why a certain syntax or language might work better for certain people.
  - quickthrower2 4y ago
    It does, but there are still many different purposes. In JS: ( can mean: function call, part of an expression to be evaluated first, regex capture group { can mean: scope [of ... loop, if, lambda, function etc.], object definition, string interpolation code i.e. ${..}, class definition There are probably other things I am not thinking of. The one that trips me in JS is code like x.map(v => {...v, v2}) breaks because the compiler sees the { as the beginning of a scope, not the object definition I intended. The working solution is x.map(v => ({...v, v2})) But x.map(v => v+1) is allowed. I don't think the compiler could figure out what you meant because an object definition might be a lambda function body. For example { myvar } can be both an object definition, and a function that returns myvar.
- lptk 4y ago
  That's obviously nonsense. Java, one pair of parens: int x = 1; int y = x + 1; System.out.println(y); Clojure, six pairs of brackets: (let [x 1 y (+ x 1)] ((. (. System out) println) y))
  - deleted 4y ago
    [deleted]

layer8 4y ago

> the nice thing about (f x) is that the parenthesis group f with x The drawback is that they are put on the same level, whereas in most people’s minds the function is a fundamentally different thing from the argument(s). The “f(x)” syntax reflects that asymmetry.

agumonkey 4y ago
What creates that distinction ? in the lisp / fp world you quickly stop considering functions as separate entities.
- layer8 4y ago
  The function represents the operation or computation you want to perform. The arguments represent inputs or parameters for that operation or computation. Of course, theoretically you could also view the function as a parameter of the computation and/or the arguments as specifying an operation (in particular if those are also functions), but for most concrete function invocation that's not generally the mental model. E.g. in "sin(x)" one usually has in mind to compute the sine, and x is the input for that computation. One doesn't think "I want to do x, and `sin` is the input of that operation I want to do". One also doesn't think "I want to do computation, and `sin` and `x` are inputs for that computation". It's why you may have mentally a sine graph ranging over different x values, but you don't imagine an x graph ranging over different functions you could apply to x.
  - agumonkey 4y ago
    But even in high school topics start to talk about functional equations (calculus, e/ln). I'm not sure the <function> vs <value> doesn't come from the mainstream imperative paradigms and only that.
    - tikhonj 4y ago
      The distinction isn't between functions and values in general, it's between the function being called and the arguments passed to the function being called. The difference isn't in the things themselves, it's in the role that they play in the specific expression we're reading.

agumonkey 4y ago

I wish we had stats about sexps (we shall call it the kinthey scale). As a kid what you said was the first thing my brain caught on. It compresses the number of things I had to remember it's ~always (idea arguments...). We can now discuss interesting problems.

throwaway17_17 4y ago
I had the same feeling when I first started using a lisp (which was Scheme to work through SICP and the Ableman&Sussman MIT course). I was utterly entranced by the simplicity and uniformity. It was absolutely a factor in the way syntax works in my personal language (which I use for almost everything in my day to day). I really do agree that learning a lisp can truly expand the way in which a dev views and thinks about code.
- agumonkey 4y ago
  Brown university PLT labs also vouched for this approache. Their textbook starts with a descriptions of sexps as syntax saying that's the only parsing theory covered here.

hota_mazi 4y ago

It's a stupid joke. The negative reactions that a lot of people have toward Lisp's parentheses are not because of the call function syntax but because parentheses are used everywhere else in Lisp's syntax.