Emacs Lisp critique

In this series of articles the author does a very brief look over languages and tries to make a conclusion whereas the language is good or not and should you use it. Honestly, reading a few of those shows some kind of bias against most other other languages except maybe Python and Kotlin IIRC. In this post I'm kind of surprised that the author went a bit further and implemented a small wordle clone, and not just a fizzbuzz thing. But still, it seems to me that the author didn't bothered to look too deep, and use Emacs Lisp for working with buffers, and not just strings, which are surely not its best.

> […] but both Emacs and Emacs Lisp are really obsolete. Lol, okay buddy.

[deleted]

For as much as I dislike Emacs Lisp, the only thing I agree with in this article is: > why do we need to do this silliness like (apply 'prints (cdr args)) instead of (prints &rest (cdr args)) or (prints . (cdr args))? For years I wished Emacs Lisp had such syntax. `apply` and `funcall` are just so annoying. ~~edit removed~~

This is hardly a critique. It barely even rises to the level of troll job. The author should reconsider whether a “speedrun of languages” can show anything other than their own prejudices. Furthermore, criticism of Elisp from a Ruby programmer is pretty rich, given Ruby is a much bigger, less consistent, and just as (if not more) wart-filled than Elisp.

I'd rather not have such magic syntax, tyvm.

I largely agree with this guy, although `search` comes to mind when checking if one string contains another. He cites a [steve yegge post](http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html) which is more intelligently controversial. Unfortunately, it'll prolly be above the heads of most of us. I grokked most of it having continuously programmed lisp for the past three years, but certainly couldn't after one year. First this: > Every single non-standard extension, everything not in the spec, is "wrong" with Common Lisp. This includes any support for threads, filesystem access, processes and IPC, operating system interoperability, etc. And second in regard to CLOS: > You can't create a new kind of measurable object and give it a length method; you have to call it rope-length or foo-length or whatever. This in particular echoed a recent change in the emacs codebase which introduced crudities like "symbols-with-pos-enabled" and "symbol-with-pos-p" to deal with what would be a derived class of plain old symbol in an "objects all the way down" language like smalltalk. What's really bad though is the powers-that-be broke the fourth wall and implemented "symbol with position" in the C core, thus compounding the inelegance. Fortunately none of these shenanigans will likely manifest to the casual users on this forum.

Gollum chasing the shiny things comes to mind here.

The first few paragraphs read as if the author is repressing emacs related trauma. Surely emacs can't be entirely dead for one who is willing to consider vim and even notepad++ active.

For someone with such hard and fast opinions, their wordle clone sucks.

> I largely agree with this guy Doesn't surprise me coming from the first person obnoxious enough to get "banned" from Emacs devel mailing list. Every time I've seen you communicate with someone you write in a bombastic and antagonistic style. This article is written in the same style.

Zdrajca! Just kidding :) however, did you ever try to do some plugin programming on vscode? Whatever you try to do it takes a million hours and you have to read thousands of pages of horrible written Microsoft docs. I stopped completely off vscode after i did some plugin programming and will never ever touch this piece of shit again. Contrast this with the fact that you can change everything in emacs with one function call. Another critic point of mine is that these new editors are ugly. 98% of software engineers nowadays haven't heard of Caravaggio so you can't expect good taste here. The only thing i don't like in emacs is that it's single threaded. I also don't get the complain about functional programming here. Haven't you heard about dash.el? Or have you ever seen a better string manipulation library then s.el? Lisp isn't for everyone. People who like codebloat, beaurocracy or have difficulties with mathematics never will see the benefits of it. All others are very happy with multiplying their productivity by N. Edit: sorry bro, emacs can read files and slurp files with one function call and has as already mentioned above the best string handling I've seen. Do you know what a library is? No? Please do your homework before you write so much nonsense about a tool you seem not to know at all. So while the word zdrajca was obviously a joke, the word ignorant seems to fit here very well. Of course bad publicity about emacs is good for us because it gives us an advantage on the job market against you vscodebloaters. Please write another article like this about vim or slot how awesome Microsoft windows is :)

There’s nothing magical about it. Just like `'(1 . (2 3))` is a flat three-element list, `(foo arg . rest)` could be a flat function call.

> Please do your homework before you write so much nonsense about a tool you seem not to know at all. This is a common theme between all posts in this series

So what it's about? Does any post writing bad about emacs make one popular off famous? Or is this a "small dick issue" like "I'm to stupid to use anything else then the popular IDEs so i invent some nonsense to show that it's them who are illiterate and not me"? Or maybe it's a super tricky reddit hack i don't get to get the post more publicity? I recently discovered here on Reddit that there are people that read less in a month then i can write in ten minutes. Really! These were such proportions, i am not exaggerating. "You can't open a file in emacs", that's the thing lisps excel at! Functions and macros make it possible to wrap everything up in one function call. "Emacs sucks in string handling", what else is emacs for? Since 40 years super smart people like RMS do nothing else then develop more and more string handling procedures for emacs. I discovered emacs only recently and am so astounded how powerful it is! I'm twenty years in SW engineering and haven't seen such a powerful tool. The level of ignorance here is unbelievable :))))

[Lisp-1 vs Lisp-2](https://en.wikipedia.org/wiki/Common_Lisp#The_function_namespace) and [Technical Issues of Separation in Function Cells and Value Cells](http://www.nhplace.com/kent/Papers/Technical-Issues.html).

I don't agree with his conclusions, but he did more with elisp in his wide-ranging language survey than most of the fanboys posting on /r/emacs. If even he, a guy who's clearly been around the block, is stultified by emacs's obtuseness, then what hope do we have for the general computing public?

Yeah, perhaps it's not a critique, but English is not my first language, so I couldn't pick a more fitting word for the title, sorry for that. I guess I could have kept the original title, but I've thought that it may associate me with the blog as if I'm the author, so I've decided to avoid it, as my personal opinions regarding text editors are a bit [different](https://andreyorst.gitlab.io/posts/2020-04-29-text-editors)

He knows some basic python or JavaScript and did one tutorial on elisp. He doesn't know the basic libraries, did not check how to do file nor string handling but has a strong opinion on this. I would go so far and say that op hasn't understood at all what emacs IS but wrote this article. In my eyes he compromised himself totally. I wouldn't contract this guy even to install windows :) If i would be him i would silently remove this article and cover myself in shame. As for your last statement, i don't see a problem here. Emacs doesn't have to be the most popular tool. I'm absolutely fine with that fact that such an unpopular tool is so powerful and not commonly understood. It's a big sign that there are still million of ways to make really good money in IT since the competition is SO weak.

Do you all know each other or something?

> really good money in IT since the competition is SO weak. We'll have to agree to disagree, especially on this point. IT is a much bigger and thus much dumber space than it was when I started out. But dumbing things down is how you make money, and emacs, to its credit, can't be dumbed down much.

Exactly I see new emacs users popping up every single day. I started using emacs 3.5 years ago. Few folks at my work started using emacs after they saw few of my demos. Emacs is going to outlast these modern editors, even with relatively tiny but proud user base.

> I would go so far and say that op hasn't understood at all what emacs IS but wrote this article. I'm not the author of the article.

[deleted]

No slight meant against you, OP—I’m sure the author would describe it as a critique.

No idea if the author is just trolling to boost his own ego or if he is genuinely that ignorant about his own ignorance. He is definitely not targeting the Emacs community, but some less knowledgeable audience. First, the idea that he will give a critique of 100 programming languages is just bizarre. In order to give critique to something you will have to learn it properly, there is no way this person is skilled enough, probably, in any of those languages to give critique of anything. I think he is just promoting himself in less-educated circles. No idea. But reading his wording about dynamic scoping and shitting on lexical scoping a paragraph or two later is just a sign of an idiot how is trying to "critique" something to make himself appear as more knowledgeable than he is. With other words, his posts are just ego-boosters, nothing to look at.

But emacs also does not try to make money

Why is this annoying: (apply 'prints (cdr args)) but this is not: (prints &rest (cdr args)) Honest question, I am trying to understand. The first one is more functional, the second one is more imperative.

Indeed.

> He cites a steve yegge post which is more intelligently controversial. In my country we have a saying: "A frog saw the horse getting a horseshoe, so she came too, to get one" (a horseshoe, not a horse :-)). That is how I feel, what the author of that "critique" is contributing to this world.

> Do you all know each other or something? https://github.com/dickmao https://github.com/commercial-emacs/commercial-emacs

The author clearly says "speedrun." That's a term borrowed from gaming where the player tries to get from point A to B optimizing for speed not depth. A similar series is Max Deutsch's articles on his month-long training regimen to becoming a chess grandmaster. Yes, Deutsch is an ass clown, but the point was never to achieve anything close to mastery -- it was to describe a headlong plunge into a nontrivial discipline. This Polish dude, who is likely smarter than Deutsch, was trying to do that with elisp and 99 other programming langauges. I'm surprised he even knew the difference between the scoping schools, which at least half of the people here don't fully understand.

I believe you miscategorize `kate` in your article, as it is quite a bit different than gedit/pluma, both in out of the box capabilities and advanced features. I used it for several years (up until the great kde4 breakage), and the only complaint I had was it was too resource hungry on my poor old 2GB laptop (core 2 circa 2008). It's IDE features are minimal, but given that it claims only to be an advanced text editor, those IDE features are more than enough for its intended purpose.

Yeah, and Kate is not really inbuilt AFAIU, so it's not fair to compare it to Gedit to begin with (Gedit is defacto default editor in GNOME, and KDE's default editor is KWrite, if I'm not mistaken). We also used Kate at a place I've worked several years ago, I know it's capable, and it's worth to say that it's one of the most capable across DE related text editor projects.

> The author clearly says "speedrun." That is completely wrong target for "speedrun". Critique is to be given with a reason. Being ignorant about something and giving it critique is just displaying the own ignorance. > Yes, Deutsch is an ass clown, but the point was never to achieve anything close to mastery -- it was to describe a headlong plunge into a nontrivial discipline. I am definitely not familiar with Deutsch and his experiment, first time I heard about him is now from you, but if his goal was to describe a month of trying a nontrivial discpline, it sounds legit. I don't think the polish dude is doing the same: > I won't be shy about my opinions, and I might be even exaggerating a bit. Feel free to share your thoughts in the comments. > > Episodes will all be indepedent. Target audience is people who know programming, but don't know a 100 difference languages, so I'll often use some less idiomatic ways of doing things if I think it's clearer for such reader, or if it lets me showcase specific language feature better. To me, this sounds like he is considering himself as a master of those languages, since he obviously believes he can use different ways hat makes him showcase some specific language features or make it more clear for the reader. I don't know, I am maybe too harsh on him, but I experienced his overall tone of the writing as if is very sure in what he writes, yet he obviously is neither well-informed about elisp nor programming in lisps in general. > I'm surprised he even knew the difference between the scoping schools, which at least half of the people here don't fully understand. He has probably looked that up somewhere. There is an old Emacs Wiki page where Elisp is critiqued, and there are some other articles. Dickmao pointed out he is citing relatively well known Yegge's blog too. In his writing, he is obviously aware of the history where people asked for Emacs Lisp to go (the Emacs Wiki article I can't find now), so he has done a research on Emacs Lisp and Vi.

I don't like elisp to be honest. But I love Emacs. It's great that elisp is so dynamic which makes emacs so great, but the syntax is still hard to read for me coming from c-derivred languages.

All Emacs lisp needs is FFI

It is as well which is why I would go for the second syntax as an analogue for quoted lists. > The first one is more functional, the second one is more imperative. I fail to see why that would be true.

I don’t see how this prevents `(foo bar . baz)` being equivalent to `(apply #'foo bar baz)`.

> The author clearly says "speedrun." That's a term borrowed from gaming where the player tries to get from point A to B optimizing for speed not depth. The reason it's a bad term for what he's doing is that most speed runners of games put in more hours than casual players do in order to optimize the time it takes them to complete it. To beat the game as fast as they do requires mastery.

Sounds like MIT-Scheme (a Lisp-1) is more your bag.

> It is as well which is why I would go for the second syntax Well you opposed (prints &rest (cdr args)) as a better version to "silliness like" (apply 'prints (cdr args)). > I would go for the second syntax as an analogue for quoted lists. (prints . (cdr args)) <-- how is that analogue to quoted lists? You are constructing a 'cons' cell there. It is analogus to (cons prints (cdr args)). And why would you prefer typing (prints . (cdr args)) if you could type (prints (cdr args))? > I fail to see why that would be true. Apply and funcall work with functions and their arguments as data. In your second example, you are just telling the system to execute prints operation. I agree that it is not so visible in a so small example, but in a bigger context, you can have function symbols stored in lists, constructed at runtime, and pass those to apply and funcall as you would pass arguments to prints. With other words you could generate set of functions to be executed at runtime, without ever hard-coded them in the source code in order to be executed: (defvar fn-list '(one two three)) (dolist (fn fn-list) (funcall fn)) With more imperative way, you will have each one specified in source code to be executed: (one) (two) (three) With other words you have to explicitly state which functions are called. With funcall and apply, we can dynamically generate and invoke any function. So I don't understand why are they silly and annoying? Macro can be used as well, in place of funcall and apply, but that is another story.

Is there a way to slurp files with one function call in elisp without using the `f` library? Best I could think of is `(with-temp-buffer (insert-file-contents "file") ...)`.

Notepad++ is almost the standard texteditor on windows, at work everybody uses it for basic file editing where you don't need an IDE or similar capabilites. Vim is more accessible and easier to work with out of the box, this is one of the reasons why it's more widely known and used. One big advantage of vim is also that it's easily available on every linux distro and it can be used as a "standard" text editor. Emacs is way more niche, it's basically only made for porgrammers or people who mainly use their text editor. On top of that it takes quite some time to get a good emacs config going and learn the keybinds, vim is a bit easier to get going in. I personally just switched to emacs and love it, for me it's the "ultimate" texteditor, not the one people use in their first year of programming.

Well, it is, but it still does not mean that `(foo bar . baz)` would be incompatible with Emacs Lisp. You would still need to write `(apply foo bar baz)` if `foo` is a variable of course.

> Well you opposed (prints &rest (cdr args)) as a better version to "silliness like" (apply 'prints (cdr args)). Not quite. I quoted the article which included both forms. Since you’ve asked I’ve then clarified that I would go with the `(prints . (cdr args))` syntax. > (prints . (cdr args)) <-- how is that analogue to quoted lists? `'(foo bar . (baz))` creates a ‘flat’ three-element list `'(foo bar baz)`. Value after the dot is tail of the list. Similarly, `(print . (cdr args))` would use value of `(cdr args)` as tail of the `prints`’s argument list. > You are constructing a 'cons' cell there. It is analogus to (cons prints (cdr args)). Yes, precisely. `(prints (cdr args))` is an analogue of `(list 'prints (cdr args))` while `(prints . (cdr args))` would be an analogue of `(cons 'prints (cdr args)` just like `'(foo bar)` is the same as `(list 'foo 'bar)` while `'(foo . bar)` is the same as `(cons 'foo 'bar)`. > And why would you prefer typing (prints . (cdr args)) if you could type (prints (cdr args))? Those would do different things. The former would call `prints` with as many arguments as `(cdr args)` has while the latter calls `prints` with a single argument . > With other words you have to explicitly state which functions are called. With funcall and apply, we can dynamically generate and invoke any function. So I don't understand why are they silly and annoying? They are annoying when you’re not dealing with dynamic function. For example, to find maximum of a handful of numbers I can write `(max 1 2 3)` but if I have those arguments in a list I now must add bunch of syntax and write `(apply #'max num-list)`. Of course the root of the annoyance is that Emacs Lisp has separate namespaces for data and functions but at least with static identifiers the noise could be avoided.

Ah, I should have thought of that everything in Lisp is a list, so of course are both cons cells and quoted lists equal :). > > And why would you prefer typing (prints . (cdr args)) if you could type (prints (cdr args))? > Those would do different things. The former would call prints with as many arguments as (cdr args) has while the latter calls prints with a single argument . And how would the system know that you are calling function: (prints . (cdr args)) and not constructing a cons cell: (prints . (cdr args))? You forgott that dotted pair notation is just a syntactic sugar for (cons prints (cdr args))? > Of course the root of the annoyance is that Emacs Lisp has separate namespaces for data and functions but at least with static identifiers the noise could be avoided. Yes, that is certainly the root of all evil. :-) Especially when it comes to dotted pair notation.

>And how would the system know that you are calling function: (prints . (cdr args)) and not constructing a cons cell: (prints . (cdr args))? You forgott that dotted pair notation is just a syntactic sugar for (cons prints (cdr args))? `(prints . (cdr args))` is a function call and `'(prints . (cdr args))` creates a cons. But turns out this whole discussion is moot. While I wasn’t looking, someone added this feature to Emacs Lisp it seems: (max 1 2 . (3 4)) ; => 4 (let ((x 1) (y 2)) (max x y . (3 4))) ; => 4 (let ((x 5) (y 2)) (max x y . (3 4))) ; => 5 Or maybe it was supported for ages and I just didn’t notice? I can’t find mention of it in documentation.

Oh my bad, I see what you mean now. You're beef is with `apply`. You want dot in an unquoted context to mean `apply`. It's a tad unruly to multiplex dot's meaning depending on context, but also the kind of syntactic sugar so minutely more compact than (let ((args '(1 2))) (eval `(+ . ,args))) that it's not worth cluttering the lisp spec, one that prides itself on its impressive *lack* of syntax.

> that it's not worth cluttering the lisp spec, one that prides itself on its impressive > lack > of syntax. This isn’t some new syntax, it’s already supported for quoted forms, so claiming that it’s somehow against Lisp’s lack of syntax is rather baffling. But as I just discovered, this whole thread is moot since this syntax is supported at least in Emacs 29.

I suppose then you'd be okay with semicolon meaning something other than a comment signifier depending on context. \> But as I just discovered, this whole thread is moot since this syntax is supported at least in Emacs 29. Yeesh! Then the emacs people lack more taste than I already didn't give them credit for.

This is not what you want. You want (let ((x 1) (y 2) (z '(3 4))) (max x y . z)) Your examples merely get flattened to `(max x y 3 4)` before the semantic parser evaluates it. You're after a variable arglist, since no one, not even a noob, would write `(max x y . (3 4))`.

> But turns out this whole discussion is moot. While I wasn’t looking, someone added this feature to Emacs Lisp it seems: > (max 1 2 . (3 4)) > ; => 4 Are you sure it is a moot? Have you tried this: (max 1 2 . '(3 4)) <- -error (defvar L '(3 4)) (max 1 2 . L) <-- error (apply #'max 1 2 L) <-- works (apply #'max '(3 4)) <-- works > (prints . (cdr args)) is a function call and > '(prints . (cdr args)) creates a cons. Ok, and how will system know when you are quoting a cons form '(prints . (cdr args)) or creating a new cons cell '(prints . (cdr args))? Not to mention ~1.5 million lines of emacs lisp code that would have to be revised to adapt to new syntax. > I can’t find mention of it in documentation. Have you looked in the right spot? > You can combine dotted pair notation with list notation to represent conveniently a chain of cons cells with a non-nil final CDR. You write a dot after the last element of the list, followed by the CDR of the final cons cell. For example, (rose violet . buttercup) is equivalent to (rose . (violet . buttercup)). https://www.gnu.org/software/emacs/manual/html_node/elisp/Dotted-Pair-Notation.html

> Well, it is, but it still does not mean that (foo bar . baz) would be incompatible with Emacs Lisp. > But as I just discovered, this whole thread is moot since this syntax is supported at least in Emacs 29. It is not :). You are misunderstanding what you have "discovered". I have posted you a link to documentation, that clearly has an example of that exact notation you mention, (rose violet . buttercup) and an explanation of what it means in Emacs Lisp.

On gentoo, `kwrite` is included by `kdecore-meta`, so yes, `kwrite` is the "always available" kde editor. `kate` is in `kde-apps-meta`, is is likely to be installed on a kde-based system, but may *not* be if the system is using some other family of tools (like xfce's) running on top of kwin/plasma. On a related note, in the advanced text editor category, I've found `geany` is the best. It has a similar feature set to `kate`, including a few things that it does better, while requiring fewer system resources, and not depending on the kde libraries. It is unfortunate that it largely languishes in obscurity, but it is very much an example of an editor that is used by the people who develop it, so spreading the word about it is not particularly prioritized. Oh, on one last related note, I first encountered multi-cursor/column-mode-editing in an ancient copy of `blackbeard`, which dates to 1985. I'm given to understand it was quite popular on dos machines at the time, not sure if it is what inspired sublime. Unfortunately, `blackbeard` never really made the transition from dos to windows, as the author passed away, so it has largely fallen down the memory hole.

I recently switched to emacs (doom emacs to be specific) and now 3 of my programs have switched to emacs, file manager terminal and text editor. I read the article and the guy commented on someone else's comment that people spent time configuring emacs with packages and make it fit their own needs and that he wouldnt recommend it to a beginner. I would say otherwise. You could recommend an emacs distro like doom emacs. I would say the same for vim as well. I woukd recommend spacevim for people just starting out on vim. Emacs *is* just that, a template for making your own environment however you want.

> I suppose then you'd be okay with semicolon meaning something other than a comment signifier depending on context. Semicolon already has two meanings depending on context. If its preceded by an odd number of question marks it’s an integer.

> Are you sure it is a moot? Ah, you’re right, it wasn’t quite the feature I was hoping for.

(add 1 2 3) ; ARGHHH so many parentheses!!! add(1 2 3); /* syntactic perfection!!! */ That was a joke lol. When reading Lisp code you should only look at the indentation and ignore the parentheses (of course that only makes sense if the Lisp code was correctly indented in the first place).

Still don't get it, these are the above two people?

That was very informative read. Thanks!

Both of those links belong to nnreddit-user. He also posts on the Emacs development mailing list.

I don't know if there is a better way, and this is how I do it. However, something that people programming in Elisp should \*really\* insist on is the fact that Emacs editing functions and capabilities are generally much better thought of as acting on a *buffer,* as opposed to *strings.* If what you really need is a giant string containing a file content, you might be better-off using ... a temporary buffer and perform your editing/computations in it, rather than allocating a string to use inefficient and awkward functions on it.

Oh hi! Author here. Might as well address some issues from various comments: * the series is about programming languages, not editors, so it's not Emacs review; I don't have strong feelings about Emacs either way, I used it casually back in the days * I only included a brief note about current editors and Emacs situation to give readers some background, as most readers don't know much about Emacs * Emacs is indeed fading away, you can check for example [Stack Overflow Developer Survey](https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-integrated-development-environment) * even that number (5.3%, and you can select multiple answers) likely overestimates it, as the kind of people answering surveys tend to be the most dedicated; millions of casuals using Notepad++ or VSCode, all the data scientists coding in Jupyter, and so on, wouldn't even know about the survey * [Emacs devs wanted to replace Emacs Lisp for very long time, you can even check out RMS talking about Guile/Scheme all the way back in mid 1994](https://vanderburg.org/old_pages/Tcl/war/). It's a bit surprising nothing really came out of that. * NeoVim managed to replace VimScript with Lua * it is a speedrun, not Emacs Lisp tutorial, or anything particularly in-depth * because it's a speedrun, languages that have fewer warts and where things just work out of the box are going to look a lot better; this is a great environment for Python, Kotlin, Julia, Crystal etc. to shine; but [Racket Scheme also does quite well](https://dev.to/taw/100-languages-speedrun-episode-34-racket-scheme-5b69) * yes, I'm aware `f` exists, I'm mostly sticking to whatever is available in standard library if possible to keep the series fair I hope this answers your questions.

Obviously, the snark bordering on vitriol from our replies comes as no surprise given the name of the subreddit. The marginal clunkiness of elisp relative to a generalized lisp is an acceptable cost for having a lisp, any lisp, be your extension language. The vimscripter, vscode pythonista, and neovim luaphyte who disagrees likely hasn't significant lisp experience. Would Scheme under the Guile VM have been better? Of course, but the history of computing, and really the world, is rife with examples of a suboptimal first-mover becoming too big to replace. Incidentally, neither Guile nor Tcl achieved its goal of becoming the configuration *lingua franca*.

[deleted]

Note: this may be a bit harsh, but I don't know how to put it the other way. I've tried to cut edges where possible though. > - it is a speedrun, not Emacs Lisp tutorial, or anything particularly in-depth As was pointed out by others in the comments, a speedrun (usually) takes a lot of time, preparation, and practice before you can produce actually good completion time. So a speedrun actually contains *a lot* of in-depth thinking. I said "usually" because of course if no one else runs the same game as you, as long as you're fast and obey common speedrun rules, it counts. However when an actual speedrunner comes to compete, they would eventually beat such runs by spending hours and hours practicing tricks and mechanics, learning patterns, developing an optimal route, to achieve the best time. Well, I'm sure you're aware of it. My key point of the previous paragraph is related to this particular point in your list: > - because it's a speedrun, languages that have fewer warts and where things just work out of the box are going to look a lot better Actual speedrun always contains a lot more tricky details, than what's usually available at the surface level, or even things no one actually seen before. So, speaking in a speedrun terminology, this is more like a run in the any% category, where you skip anything that a language actually has to offer, so you could finish the review as fast as possible, almost judging it "by the cover". What I'm trying to say (and what I saw in comments to some other posts in the series) is that writing examples in a non-idiomatic way (because idioms require you to spend some time learning and using the language), and comparing languages by writing fizz-buzz isn't going to produce a lot of value, or give the language justice. The word "speedrun" may sound cool, so I see why you might use it, but the way you approach this makes it more like a "rushed review" and not a speedrun. I guess it can be called a "marathon", but still, I'd wished for a more in-depth reviews instead.

> absolute number is almost certainly increasing. I've yet to see hard data hinting the year-to-year replenishment rate exceeds the attrition rate. I would say "almost certainly" the number of emacs users increased from 1994. Zero data to suggest it's increased from 2012. Before you object "the number of packages keeps going up" recall Twain's advice about staying silent.

Wow, all of us here slamming Polish guy for not having thought long and hard enough about using the word "speedrun" need to start chasing their own tail, which at least gives you some physical exercise.

[deleted]

well, if one makes excuses by calling something one does with a word that has a pretty specific meaning (even in the context), they might as well need to check if the meaning actually aligns with what one does. I mean, IMO

> Before you object "the number of packages keeps going up" recall Twain's advice about staying silent. Your crypto-incivility is not going unnoticed. Would you mind elevating the level of discourse around here, instead of depressing it?

Lol, okay buddy.