4 ms·

As an emacs beginner, I've landed on his site numerous times, often finding it helpful. The fact that he might or might not have trolled some mailing list is of

As an emacs beginner, I've landed on his site numerous times, often finding it helpful. The fact that he might or might not have trolled some mailing list is of no concern to me. If you have a better alternative resource, please present it. If you can find technical faults in this resource, you should provide them so the author can correct it and other might learn of them as well. Otherwise, stop trying to justify ad hominem with meaningless retorts.

lispm 11y ago
> The fact that he might or might not have trolled some mailing list is of no concern to me. It's not meaningless to me. > If you can find technical faults in this resource, you should provide them so the author can correct it and other might learn of them as well. We had extensive discussions with him for years. Literally thousands of posts can be found on comp.lang.lisp. The only Lisp he learned was some imperative crappy style, while lecturing everyone how dumb they are.
- josteink 11y ago
  > The only Lisp he learned was some imperative crappy style Not to be trolling myself, but I believe that's part of the "practical" aspect. You'll find much of the same in "Practical common lisp".
  - lispm 11y ago
    What I think of is Lisp code from the 60s, before structured programming, functional programming, etc. when he writes: (let (a b c) (setq a ...) ... (setq b ...) ....) That's basically the style of the past: (prog (a b c) (setq a ...) ...) With one difference: then it was usual to program control flows in Lisp with labels and gotos...
    - brudgers 11y ago
      That in no way excuses being mean.
    - xahlee 11y ago
      which way to use let is just a personal taste. When i begin in elisp, i ALWAYS stick with this form of using local var: (let (x y z) (setq ...) (setq ...) (setq ...) ... ) This makes it easier to read all local variable names. Especially when readers are beginners, non-professional programers, scientists, writers. If we always use this simple style of let, what possible problem can it create? • Does it creates algorithmic problem? • Does it slow down programs? • Does it violate some computer science principles? • Are there science based proof, or statistics, that shows this style does some damage, such as more difficult to maintain? The only thing i can think of, is a matter of esthetics. later on, sometimes i use this form (let (x (y 3) (z 4)) body) with the condition that, if i set the variable in the let parameter, it must be constant. The value never changes in the body. And now sometimes i also use the (let* ...) form. These variations are just sugar syntax. Not really important. It's a bikeshedding problem. The thing is, in emacs lisp, there's no way to declare constants. And also, it is unnatural to code elisp or even Common Lisp without lots of setq or setf or similar. In JavaScript, the issue is much worse. JavaScript Name Hoisting and One-Liner Functional Style http://xahlee.info/js/javascript_name_hosting_and_one-liner_functional_style.html http://xahlee.info/js/javascript_name_hosting_and_one-liner_...
klibertp 11y ago
> If you can find technical faults in this resource, you should provide them so the author can correct That's the problem, actually - I never saw Xah correct anything he thought "right", no matter how many people presented rational arguments. Granted, I don't follow his writings that much, so maybe it happens; however my general impression is that it's utterly impossible to convince Xah of anything. On the other hand, his site does provide a certain amount of information. It just mixes good information with bad in a way which makes it very hard for beginners to tell one from the other.

lispm 11y ago

> The fact that he might or might not have trolled some mailing list is of no concern to me. It's not meaningless to me. > If you can find technical faults in this resource, you should provide them so the author can correct it and other might learn of them as well. We had extensive discussions with him for years. Literally thousands of posts can be found on comp.lang.lisp. The only Lisp he learned was some imperative crappy style, while lecturing everyone how dumb they are.

josteink 11y ago
> The only Lisp he learned was some imperative crappy style Not to be trolling myself, but I believe that's part of the "practical" aspect. You'll find much of the same in "Practical common lisp".
- lispm 11y ago
  What I think of is Lisp code from the 60s, before structured programming, functional programming, etc. when he writes: (let (a b c) (setq a ...) ... (setq b ...) ....) That's basically the style of the past: (prog (a b c) (setq a ...) ...) With one difference: then it was usual to program control flows in Lisp with labels and gotos...
  - brudgers 11y ago
    That in no way excuses being mean.
  - xahlee 11y ago
    which way to use let is just a personal taste. When i begin in elisp, i ALWAYS stick with this form of using local var: (let (x y z) (setq ...) (setq ...) (setq ...) ... ) This makes it easier to read all local variable names. Especially when readers are beginners, non-professional programers, scientists, writers. If we always use this simple style of let, what possible problem can it create? • Does it creates algorithmic problem? • Does it slow down programs? • Does it violate some computer science principles? • Are there science based proof, or statistics, that shows this style does some damage, such as more difficult to maintain? The only thing i can think of, is a matter of esthetics. later on, sometimes i use this form (let (x (y 3) (z 4)) body) with the condition that, if i set the variable in the let parameter, it must be constant. The value never changes in the body. And now sometimes i also use the (let* ...) form. These variations are just sugar syntax. Not really important. It's a bikeshedding problem. The thing is, in emacs lisp, there's no way to declare constants. And also, it is unnatural to code elisp or even Common Lisp without lots of setq or setf or similar. In JavaScript, the issue is much worse. JavaScript Name Hoisting and One-Liner Functional Style http://xahlee.info/js/javascript_name_hosting_and_one-liner_functional_style.html http://xahlee.info/js/javascript_name_hosting_and_one-liner_...

klibertp 11y ago

> If you can find technical faults in this resource, you should provide them so the author can correct That's the problem, actually - I never saw Xah correct anything he thought "right", no matter how many people presented rational arguments. Granted, I don't follow his writings that much, so maybe it happens; however my general impression is that it's utterly impossible to convince Xah of anything. On the other hand, his site does provide a certain amount of information. It just mixes good information with bad in a way which makes it very hard for beginners to tell one from the other.