2 ms·

> Most Algol-derived languages use punctuation and symbols that seem to make them stand out better than words alone. If we read a long novel, then we read most

• tabtab 7y ago
  > 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-type-indicator symbols. Maybe it is indeed possible to refactor written English for speed reading. I haven't surveyed the tests. Does anyone here want to claim English is optimized for quick reading? It's kind of off topic, but I can envision using various symbols and block-markers to delineate parts of English sentences such as subject, verb, object, etc.: "(subject..) $verb {object...}" I think it would quicken MY reading, but I can't vouch for other humans. Maybe I'll patent it, or did Oracle beat me to it ;-) But that's the idea: commonly occurring features are marked or surrounded with different symbols. You can't really do that in Lisp because nouns are verbs and verbs are nouns depending on the context/usage of the libraries or deeper code, while with Algol-derived languages mostly hard-wire the difference up front. You instantly know and don't have to stop and think or dig. Indirection/abstraction can and does slow reading in many cases. I'm just the messenger. If YOU can read and process textual words fast, that's great but may NOT be universal across most humans. > In terms of lines of code I would think that's true. No, I meant features-per-hour, at least for business-oriented coding [in COBOL]. > Why should it be in the mainstream? 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. > Now you are shifting the goal. You originally claimed that functional code is hard to debug, because there are no variables you can inspect. But that's what we do in Lisp too: we use variables for that purpose. I'm addressing TWO goals: easier-to-read and easier-to-debug. > But that's what we do in Lisp too: we use variables for that purpose. You add them just for debugging? Imperative style typically does that as in regular course. Thus, one doesn't have to alter the code as often just for debugging. > After a while the reader/writer of Lisp code will recognize the symbolic hints and the usual visual patterns of the layouted code. Indentation is not a difference maker in comparisons because both candidates can use it.
  • 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.