Earlier quoted context omitted.
> 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".
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...
Practical Emacs Lisp
51–60 of 60 posts
Re: Practical Emacs Lisp
#52Xah Lee can't program a line of Lisp on his own. Most of that code is collected from elsewhere. There are much better resources to learn Emacs Lisp from.
Re: Practical Emacs Lisp
#53Inexperienced Emacs Lisp programmers coming to this site for the first time should be aware that Xah Lee's code is generally not very idiomatic. He discusses it himself here: http://ergoemacs.org/misc/emacs_lisp_coding_style_language_i...
I'm an experienced Lisp programmer and most of it looks fine to me from a random sampling, as far as formatting goes. Sometimes a closing parenthesis is on a line by itself: (defun foo () ... ) (let ((x y) (z w) ) ...) Historically, it's not been unheard of that Lisp experts (even implementors) do this sort of thing. Exhibit A, randomly picked source file inside CLISP: http://sourceforge.net/p/clisp/clisp/ci/default/…
Yeah, but for idiots like me who sometimes make mistakes, having a type system that catches errors for me helps sometimes. There are plenty of times in languages that treat null as false-y where I've put completely the wrong variable in and gotten no useful feedback from my interpreter because it type-checks just fine and the error doesn't become apparent until 50 lines of code later in a completely different function.
Besides, if you're frequently writing code like this, it's probably because you don't understand what you're doing and are working at the wrong level of abstraction for your problem. If you're recursing over items in a list, it's almost certain you should be using a higher-order function.
Re: Practical Emacs Lisp
#54Earlier quoted context omitted.
> 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".
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...
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_...
Re: Practical Emacs Lisp
#55Earlier quoted context omitted.
Xah Lee has trolled Lisp groups for years. It's well known that much of his 'advice' is useless. The number of bullshit posts by him is a bignum. His comp.lang.lisp trolling is legendary. Nothing 'ad homenim' or mean - just saying how it is.
> It's well known that much of his 'advice' is useless. The number of bullshit posts by him is a bignum. I wanted to check this. How easy would it be to find something trolling-like, written by Xah? Turns out it took only 3 tries when searching for "Xah Lee" on googlegroups comp.lang.lisp. The third post I clicked revealed this gem: there's a good solution to lisp's non-functional ways. BAN lispers from using list or…
Re: Practical Emacs Lisp
#56Xah Lee can't program a line of Lisp on his own. Most of that code is collected from elsewhere. There are much better resources to learn Emacs Lisp from.
what a malicious lie. I have written some 10 packages, at least hundred thousand lines of emacs lisp since 2005, all public in github or on my website. http://ergoemacs.org/emacs/xah_emacs_modes.html the only borrowed code i can think of now, now named xah-extend-selection in xah-fly-keys, by Nikolaj Schumacher, fully credited in the inline doc still. (and that function is also in ergoemacs-mode, fully credited still…
Your pages also always contain instructive examples, something which cannot be said for the manual itself.
There's a reason your pages always show up when people search for anything emacs. People in general find them helpful.
And that's what should count.
Re: Practical Emacs Lisp
#57Inexperienced Emacs Lisp programmers coming to this site for the first time should be aware that Xah Lee's code is generally not very idiomatic. He discusses it himself here: http://ergoemacs.org/misc/emacs_lisp_coding_style_language_i...
This is sort of funny coming from a guy who isn't using the shift key properly. Language conventions make communication easy. It's why $_ should be used. It's why "ain't" isn't a word and the subject comes before the verb.
Re: Practical Emacs Lisp
#58Earlier quoted context omitted.
I would avoid this stuff. His language advocacy is not very convincing and he also fails to understand what grep does.
OMG, he actually loads all the files to temporary buffers and calls it `grep`? And the other text is misguided for the most part and reveals a misunderstanding of some basic concepts. tumba, please don't use these texts. I second lispm here. Only read these once you have a solid understanding of described concepts yourself.
Re: Practical Emacs Lisp
#59Earlier quoted context omitted.
> It's well known that much of his 'advice' is useless. The number of bullshit posts by him is a bignum. I wanted to check this. How easy would it be to find something trolling-like, written by Xah? Turns out it took only 3 tries when searching for "Xah Lee" on googlegroups comp.lang.lisp. The third post I clicked revealed this gem: there's a good solution to lisp's non-functional ways. BAN lispers from using list or…
con shouldn't be used, especially today. see this Guy Steele article: Guy Steele on Parallel Programing: Get rid of cons! http://xahlee.info/comp/Guy_Steele_parallel_computing.html “Get rid of cons!” is the exact words from his paper.
Re: Practical Emacs Lisp
#60Earlier quoted context omitted.
> It's well known that much of his 'advice' is useless. The number of bullshit posts by him is a bignum. I wanted to check this. How easy would it be to find something trolling-like, written by Xah? Turns out it took only 3 tries when searching for "Xah Lee" on googlegroups comp.lang.lisp. The third post I clicked revealed this gem: there's a good solution to lisp's non-functional ways. BAN lispers from using list or…
Bullies always rationalize their bullying by arguing their victim deserved it. Their flunkies are recognized by their chorus of "Yeah he deserved it" noises.
It's just that other people do deserve to know that investing their time into studying some kind of material is not likely to pay off.
I agree, though, that "he's a troll" is not the best way of communicating it. You'll notice that I wasn't the one who did that.