5 ms·

> Still many can read [novels] without much problem. Compared to what? I didn't say reading of Lisp comes to a stand-still, only that it's slower than block-ty

• lispm 7y ago
  > I didn't say reading of Lisp comes to a stand-still, only that it's slower than block-type-indicator symbols. That's an assumption of yours. > No, I meant features-per-hour, at least for business-oriented coding [in COBOL]. Another assumption, for which you assume justifications. > The standing implication, as I interpret it, is that functional programming is inherently superior in general, for a price of a slightly longer learning curve. I think of 'functional programming' as a tool. 'superior' is an attribute that you use. Implication of what? 'functional programming'? Lisp is not 'functional programming'. Lisp in its root is a mix of full imperative programming (mutable variables + imperative control flow) with functional programming (first class functions, higher-order functions, ...). > You add them just for debugging? Imperative style typically does that as in regular course. Imperative code uses operators (which are functions) and functions. a = 2 * b + 3 ^ b c = 4 * a r = c * pi * sin(a) It's basically arbitrary which variables one introduces. We could write the thing down as one expression, add more variables, etc. Using variables has two purposes: save intermediate results for multiple use and naming intermediate results for documentation/code readability purposes. +, ^, sin, ... are basically functions. An operator is a function with an infix notation. Thus any imperative code which uses functions and operators is ALREADY a mix of imperative elements (mutable variables and imperative control flow) and calling functions. In Lisp one might introduce the variables first and then set them: (prog (a c r) (setf a (+ (expt 3 b) (* 2 q))) (setf c (* 4 a)) (setf r (* c pi (sin a))) ...) or use LET* (let ((a (+ (expr 3 b) (* 2 q))) (c (* 4 a))) (r (* c pi (sin a)))) ...) or I could use local functions. (flet ((e1 (b q) (* (expr 3 b) (* 2 q))) (e2 (a) (* 4 a)) (e3 (c a) (* c pi (sin a)))) (let* ((a (e1 b q)) (c (e2 a)) (r (e3 c a)) ...) etc... Or I could write the code in some infix notation, since one can add infix syntax: CL-USER 8 > (ql:quickload "infix") To load "infix": Load 1 ASDF system: infix ; Loading "infix" ("infix") CL-USER 9 > #I( a = 3 , b = 5 , c = a * b, c) 15 CL-USER 10 > #I( a = 3 , b = 5 , c = a * b, c) 15 We can write Lisp code any way we want. We can write it in an basic imperative style in s-expression syntax and also in infix syntax. We can also write it in slightly more functional styles. Every function introduces variables and LET / LET* are nothing else then binding constructs which are function calls: (let ((a 10)) (* a 4)) is basically the same as ((lambda (a) (* a 4)) ; anonymous function 10) The more functional style of variable free calls is not the general way to write down code in Lisp. The extreme style variant is so-called 'point-free' where functions are combinated is also not very much used. So when you think that one does use a strict functional and variable-free style of programming in Lisp, then this has no base in reality. Lisp is very much an imperative language. > Indentation is not a difference maker in comparisons because both candidates can use it. Layout of code is more than indentation.
  • tabtab 7y ago
    > That's an assumption of yours. So is the opposite viewpoint. Neither of us has a solid study that's directly relevant such that anecdotal info is all we have here either way. A good study would probably require millions of dollars. Yours is NOT the default position given the lack of such studies. > Layout of code is more than indentation. Same issue: both can do it so it's not a difference maker in comparisons. > We can write Lisp code any way we want...one might introduce the variables first and then set them...or use LET*...or I could use local functions...etc... But that's part of the "lack of standardization" that contributes to Lisp being more difficult to read. Standards and conventions are somewhat counter to "flexibility". We typically don't want overly-detailed standards (hard to remember) nor want excessive flexibility because then everybody and every spot may do things different. There is an optimum balancing point in the standards vs. flexibility spectrum. Goldilocks. And the balancing point probably varies per individual.
    • lispm 7y ago
      One of the problems to learn a new programming language syntax is a mental block. One looks for all kinds of excuses. It's actually not that Lisp syntax is overly difficult, it's the pain of learning something new. > Yours is NOT the default position given the lack of such studies. Your view would be more interesting to me if you'd have spent some time learning to read and write Lisp code. Much of what you claim is just guessing. > Standards and conventions There are standards and conventions in Lisp code. You just don't know them. You are just guessing how difficult it might be to fly an airplane. It might be more difficult than a car, but how difficult it actually is not visible to you. You just guess that there are much fewer aircraft pilots than car drivers, and guess that flying a plane must be extremely difficult...
      • tabtab 7y ago
        > Much of what you claim is just guessing. Same with you. It's not statistically safe to say that because some people do better with Lisp that everybody will given enough time. That doesn't tell us whether it's a personal fit or something more general. Your line of reasoning appears to be "I did X and got result Y, therefore if everybody else does X, they will also likely get result Y". You hopefully should recognize the statistical fallacy in that pattern. Anyhow, we are going in circles. There are no solid studies to back either of our viewpoints so we just have "anecdote fights" that don't get anywhere, which is quite common in Lisp-related debates. BeenThereDoneThat. > There are standards and conventions in Lisp code. You just don't know them. But they mostly rely on "parsing" words. I personally believe in the power of symbols. My eyes/head process most symbols much faster than words. I can't explain it, they just do. That's just my brain, although others have told me similar. If YOUR brain can process textual words as fast as symbols, that's wonderful, but may be specific to you (and other Lisp fans). Your head is NOT my head. It's not like I'm new to words such that after reading a billion words I'll finally get better. People's textual reading usually plateaus after about 5 years as adults. Throwing time at the problem won't significantly change this. Why should Lisp be different? Words are words. And sure there are standards/conventions in Lisp, but the competition also has standards/conventions such that it's not a difference maker in comparisons. The difference maker is WORDS alone versus words + symbols. (Well, Lisp has parentheses, but mostly only parentheses, unless you "invent" something custom, which makes it non-standard by definition.) And I'm not against new things, but if they don't seem to be making sufficient progress after a reasonable amount of time, I abandon them. If Lisp is unique in that it has a hockey-stick shaped benefits curve (flat for long stretches, then goes up), then it stands out from most tools. It's hard to know if it has a weird learning curve up front since there are no decent studies on it. Often fans of tools claim "just try it long enough". That's not sufficient because it's a fan habit to claim that.