Kessler83

I love Common Lisp. But I don't think you can look at a list of features and decide if it's a good choice to use or if those features are now "covered" by more recent languages. Not all REPLs (for example) are born equal, and recent is rarely a good thing when picking a programming language. I don't always use Common Lisp, but when I do, I enjoy the combination, depth and maturity of many attractive features that have only recently been introduced elsewhere (like poweful macros or the ability to compile into a running program). Also, I think not knowing Lisp is in a way like not knowing any C. Regardless of what you use at work, there are huge parts of the literature and discussion about programming that are closed to you.

The linked document isn't representative of books on Lisp or Emacs---it reads like a half-finished idea for a sketch of a pitch for a book. Since it is more than 10 years old, the project likely got abandoned at a very early stage. Writing a book is a lot of work, so don't mean this as criticism against the author. Just thought I'd say it in case someone doesn't want to waste time downloading and building something unfinished.

"in droves" isn't exactly a neutral expression, either. Says something about how they see workers.

For any laptop, I want at least full hd 15 inch screen, the very best keyboard (centered, without numpad) and a trackpoint. If it comes without dedicated graphics, that's a bonus. This means a thinkpad, afaik.

So unless I wanna spend a fortune on the new Thinkpad P1 (I don't!), I think the best option is a modded T530. I installed a 1920x1080 screen with great color, upgraded RAM to 16G, put in two SSDs and retrofitted a T420 keyboard (you need some scotch, a nail clipper and a BIOS hack). This is enough for my purposes---for now.

But you can also replace the heat sink and the processor using parts from a W530. Reportedly, this might also let you upgrade to 32G ram. So I'm confident that I'll be able to use this machine until I can either afford a P1, or lenovo puts out something even better.

Oh, come on, did you mean to be polemic or not? :) I think it's a hard sell to claim that the article was actually directed at a small, perhaps barely existent, group of Unix users who seem to be either afraid of the mouse (!) or proud not to use it.

I'll rather accept what you said earlier in this thread (the "I wrote this mess ..." post): that you simply meant to be provocative. That's OK in my book, even when it doesn't turn out all that great. Nothing wrong with the rest of the article, either.

What part of "I'm not saying you can't get pains from a keyboard" is unclear, would you say?

As you seem to have missed it, the author isn't positioning himself as a dogmatist using the mouse. He is calling Unix users who don't use the mouse dogmatists.

Hahaha, like you are some sort of brave free-thinker for using the mouse! There are tons of reasons for preferring the keyboard, one of which is to alleviate the hand and shoulder pains resulting from pointing and clicking with a mouse for 35 years ... Go into any work place where people work with mouse-heavy applications all day, and count the number of employees who have had to resort to special solutions, like trackballs, trackpoints or roller-bars. I'm not saying you can't get pains from a keyboard---not least from Emacs unless you switch capslock and ctrl. But the intro to this article is kinda silly I think. It's not a statement to use the keyboard, and you certainly aren't a rebel if you don't.

First of all, there are plenty of different data structures in Common Lisp. I don't know any Lisp resource that will tell you or encourage you to use lists for everything. For example, I think all the major Common Lisp books encourage you, explicitly, to use the advantages of different data structures.

Secondly, there is no contradiction between the usefulness of structs and the usefulness of nested lists and the ability to reach directly into them. But structs are no more a universal solution than lists are, so I don't know why you would be so hung up on them---in particular since we aren't discussing a particular use case.

I think the "unreadable monstrosity" thing in its various forms boils down to non-lispers not being used to car/cdr. That may be a fact, but it isn't an argument (and it takes about 5 mins to remedy).

Actually, there is no need to make guesses about whether cdaddr is bad, unreadable, introduces hard to handle bugs or what the limits of list structure complexity should be. It isn't some new idea or brief historic oddity that you can pass whatever judgement on.

The term is at least 40 years old, standardized, still in use, has its own established pronunciation and isn't known to cause a lot of bugs. It is also at the periphery of the car/cdr body of terms -- i.e. programming tradition shows that the level of complexity it covers is needed (or the term would have disappeared), but any further is too rare to merit a shortcut. In addition, it is easy to remember what it does: each d is a cdr, each a is a car. So it isn't any harder to read than a chain of firsts, seconds, rests and nth n's.

This isn't a very good article. First of all, this has to be the most rehashed curiosa topic about Lisp, ever. Secondly, "keeping in touch with tradition" isn't a shallow thing you do for fun---it is both about identity and about the ability to read and reuse code, even though it is decades old. And thirdly, the reason you keep car and cdr isn't only about tradition, but also about the ability to quickly reach into nested lists:

(cdaddr '(1 (2 (3 4 (5) (6 7) 8) 9) (10 1 3) 3)) => (1 3)

Without these oldies, you would have to write several combinations of first, second etc. and rest, or some combination of first/rest and nth n list.

Great article! I like the approach to focus on things that ship per default and take no time to learn! Also didn't know about undo in region!

I just wanted to say: Great article! It made me wanna try out Guix!

Don't mean to come off like a zealot. To me, it sounds like the user accessed a show/hide-function in the graphical interface while using the mouse, and then didn't know how to bring it back (Control-Right Click or menu-bar-mode). The mistake and the ability to hide the menu-bar are both super common in any application and don't make Emacs fragile. Instructions for how to hide/un-hide stuff are in the manual.

I think people are just kidding themselves when they arrive at the conclusion that a program like Emacs---which is super mature, has a huge user base amongst very picky programmers and has survived in fierce competition for 45 years---is somehow fundamentally flawed, fragile etc. Of course it isn't. But it might not be your thing, and that's fine.

You should probably tell Emacs users about it---they may not have noticed.

Vim is a fantastic editor---no argument there!

But you can always revert a configuration choice you made without restarting Emacs. Either use the built in configuration interface, or evaluate a form with the change. For example, if you set something to t you can reset it to nil and just C-x-e that form.

Well, I guess we have different experiences then. That kind of thing hasn't happened to me in 25 years. Not once.

The OS could matter, I guess. I didn't even think about that. I used Debian Stable and have been since the last century. Always a version or two behind, at least, so I guess bugs could be resolved before I get a chance to encounter them.

No, the definition of fragile is that if you use something in a wrong way, it breaks. But Emacs doesn't break. It obeys and keeps running.

With your reasoning, all software that gives you a choice, anything that can be configured, all programming languages etc. etc., become fragile, because as soon as someone says "I did this but I didn't like the result," your case has been proved. In other words, it is a circular definition.

Anyway, I didn't mean learning experience in a condescending way. The user I answered indicated himself that he was learning---and we all are, when it comes to Emacs.

Well, to each their own. I never have to restart Emacs. The only time I restart SLIME is when I do something I shouldn't, like redefine a struct or something. I'm sure I could avoid restarting SLIME, too---I just never bothered to learn if there is a way.

BTW, all software that changes will have a bug from time to time, but Emacs and things related to Common Lisp are like at the very bottom of the trouble-frequency charts. I can't think of any software that I use regularly that gives me fewer problems. For the record I never encountered a bug in either (which doesn't mean they don't exist).

I mean rock solid as in being able to edit buffers with very different contents of half a million characters, every day for decades without crashing. I wouldn't call what you describe fragile. It sounds more like a typical learning experience. You did something, Emacs obeyed and then you who didn't like what you just did :). There is a market for restricting choice, so you are clearly not alone!

But I don't think that the Emacs learning curve should be exaggerated, either. If you start it up and follow the instructions, you very quickly become productive. What gets people into trouble is usually when they expect Emacs to be like software X which they already know, so they don't read what's on the screen and kind of skip the introduction. And then they get frustrated when they find out that Emacs is Emacs. I'm not saying that's you, or that it is stupid, impatient etc. or whatever. I'm just saying that I've seen it quite a few times.

I find it doesn't really matter what I'm interested in (computer-wise)---Emacs has me covered. It saves a huge amount of time to not have to relearn a new IDE each time I need to switch programming language. There is always more about Emacs to explore, but it is well invested time, as I know that Emacs is going to be around most likely for the rest of my life-time. The killer features for me are:

+ Org-mode + SLIME (Common Lisp IDE) + A Lisp as "extension" language (it isn't really extension---Emacs is fundamentally reprogrammable). + Really smooth integration of LaTeX, Dot and Tikz. + Rock, rock, rock solid no matter what I through at it.

Also, I find that for me, Emacs has ergonomically good key-bindings once I accepted that they are different, learned them properly and did the CAPS-Ctrl switch.

Because that also gives you all the problems of having a Windows machine at the bottom (so to speak): bloat, intrusive updates, bugs, viruses etc. And the IT-department will constantly be on your ass with some new configuration and program that they have decided is what you need :). If you want to combine Windows tools with GNU/Linux, having the latter at the bottom is a way better solution imo.

To see the REPL and debugger advantages of Common Lisp over other Lisps, Python, Haskell etc., you really should try for yourself in SLIME or SLY (a SLIME fork) imo.

But anyway, let's say I made an error somewhere and the program halts, putting me in the debugger. I can then examine each frame preceding the error. I can see every value going into my functions and jump around in the code generating those values. I change the code, while the debugger is still running, recompile it into the halted program and then pick a frame point right before the error occurred, to test if my changed code solves the problem. If it doesn't, I'll examine some more, perhaps start a second instance of the REPL to experiment a bit, then try another change in my code. All the while, I don't lose state. Once the problem is solved, my program will continue where it was as if the problem never happened.

For something like game programming, where you may be deep in the game and have encountered some rare combination of circumstances, this is simply invaluable.

I've used GNU/Linux in large, Windows/Mac dependent companies for 25 years. You need to convince the IT-department, and you need to survive the first week learning how to connect to whatever system is in place, but after that, it's free of incidents to the point of being boring.

My advice for convincing the IT-department is to pick something that is known to be very secure and stable. I use Debian Stable.

My advice for the first week is to initially use the web interfaces for printers, e-mail etc. Move onto native solutions at your own pace.

When somebody tells you how GNU/Linux isn't good enough, 99 times out of a 100, it is someone who has limited actual hands-on experience, or someone who is a bit insecure and territorial about the Windows/Mac systems that he does know. Ask them how they know, and tell them you will look into the specific issues they mention. Return later and show them what you have found.

Word documents cause problems in Windows/Mac contexts too, constantly, so don't fret if you run into trouble. In addition to Libreoffice, a very quick way to deal with small inconsistencies in layout is to use pandoc with a template word-file. Basically, export a new word-file from your old one, using the template to strip the inconsistencies away.

Aim to learn Bash and regexp, at least to some degree. It can save you a ton of time.

GNU/Linux has fantastic tools for working with pdfs, comparing files of various kinds, quickly find information in a large file system and many other things. They evolve all the time. Make it a habit to check how others handle the same task you handle. Perhaps they have found a new and even better way?

Gradually start using Emacs Org-mode. There is nothing that compares.

Wow, tell me how you really feel :).

It's not a "supposed reputation" though. Nature is listed as a world-leading journal (class 2) by the internationally widely acknowledged research register "Norwegian Register". The double blind reviews aren't performed by Nature, but by peer scientists. And it isn't gate-keeping. You have every opportunity to publish your stuff in another journal or simply on the internet if you want to. A lot of scientists do the latter before trying to get it into prominent journal. Even in the case of a rejection, the feed-back you get from reviewers is often of very high quality, as in really helping you make your article better, as most journals give the review jobs to experienced scientists in your field.

In other words, a world leading journal generally contributes greatly to what you say in your last paragraph.

That said, I agree with most of your statements in the third paragraph (publish and perish etc.). It's not like I'm claiming that the current system is fine without side-effects, fake-journals etc.. I just don't think there is cause for the kind of suspicions voiced in the thread, in relation to Nature or the OP article.

Nature is a world leading journal with a very rigorous review process. They publish less than a tenth of the (proper) submissions they get. So the science here is likely to have high quality.

As for the Guardian article, there are some pretty heavy direct quotes in there, in case you don't trust the journalist's assessment (I don't see any strong reason why you wouldn't).

A vast majority on book typography agrees on 66 characters per line in one-column layouts and 45 characters per line in multi-column layouts as being the optimal numbers for reading. The text-block should also be placed assymetrically on the page, with the margins in size order being inner<top<outer<bottom. The line height should be set at 120% of the highest character hight for normal book typefaces, but should be increased for typewriter typefaces and can be decreased slightly with shorter lines. A small set of typefaces are economic without losing readability, and if you use them you can increase these numbers slightly. But any more than 80 characters and anything less than 40 characters is suboptimal for texts that are longer than a paragraph or so.

If you adhere to these very simple principles, you will have avoided like 95% of the typographic choices that can make texts hard or slow to read.

Absolutely---also, Emacs, Vim and GNU/Linux aren't hard to use. You just have to accept that they're not like Windows and follow the instructions on the screen. The documentation is generally very well written and exists from beginner level to advanced. There are also tons of places where you can go to get help when you get stuck.

Imo the whole "hard to use" thing mostly comes from people who feel they are already expert (at something in Windows) and get frustrated when they discover that there are other paradigms in which they are still beginners. So they label their own knowledge as doxa, and anything that doesn't conform to it is labeled "unintuitive," "obscure," "dated," "hard to use" etc. The same mechanism is behind quite a few of the voices claiming GNU/Linux communities are unfriendly or abrasive (i.e. someone gets frustrated upon the discovery that not everyone recognizes them as the expert they think they are).

I'm sure Micro is great, but I doubt it's anywhere even near Vim or Emacs, in any respect. Because it's not "all about keybindings," and claiming that either of those editors is stuck in a local optimum is simply counterfactual. As for living and dying, Vim is 30 years old and Emacs is 45 years old. We'll just have to see how long Micro stays in the game.

Emacs is like Earth. You can't claim to "learn it" or "master it," but it's still the best place to live.

Some other editor is more popular now, and in five years, something else will be more popular than that. Meanwhile, Emacs will continue to grow, fascinating new users and developers.

Simply put, (eq 'new 'best) doesn't evaluate to true. Knowing your way around Emacs says something about you as a programmer or computer user. Like you are clearly curious, willing to learn, know some Lisp, read documentation and recognize possibilities and depth when you encounter them. Knowing editor XXXXXX usually says nothing.

Dude, you seem to think you have a big audience :).

The reason you think my posts are astonishing, misdirecting, examples of clever deceit, manipulative, snide etc. is because you fail to counter them properly. And as it is apparently unthinkable for you that it has to do with anything on your side, it must be my fault. But consider the below points:

+ Saying something is similar to another thing because they have the same shape is an argument. That is what I did when pointing to the similarities (made explicit for your benefit in my second post) between the counter-article and classic anti-Linux FUD. You can't counter that with "prove it!", because it only indicates that you can't distinguish between a discussion about an article and some query about pointers and memory objects.

+ It is factual that people have personal experiences, strong emotions etc., but that doesn't turn these things into factual states of affairs.

+ Nobody gets to decide whether their actions, opinions, choices etc. are ideological or not. That is a judgement passed by others. For example, if you want to call LT a dictator, there isn't much I can do about it. But I can at least---gently---point out that he open sourced the Linux kernel decades ago. If you want to fork it and build and OS without GNU on top of it, go ahead. If you just want to look inside and change something, go ahead. If you want to make a commerical endeavor out of it, go ahead. My point about taking sides is that you can't do any of that with Windows.