From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Fri, 08 Sep 2023 04:00:56 +0200 Message-ID: References: <87ledwx7sh.fsf@yahoo.com> <877cpfybhf.fsf@yahoo.com> <873503y66i.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21796"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Richard Stallman , luangruo@yahoo.com, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 08 07:34:16 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qeU8E-0005ON-Lb for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Sep 2023 07:34:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qeU7F-0007GM-AJ; Fri, 08 Sep 2023 01:33:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qeQo1-0002ou-3w for emacs-devel@gnu.org; Thu, 07 Sep 2023 22:01:09 -0400 Original-Received: from mail-am6eur05olkn2025.outbound.protection.outlook.com ([40.92.91.25] helo=EUR05-AM6-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qeQnw-0000Au-J3; Thu, 07 Sep 2023 22:01:08 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Sz09XQx5e9USYwM0KSfTjUamC87FJad7+aWqoslLCia1npLqja5LJ9zVaTyL+A4jsAlGrsiwUypkymLxldUkIM/TdpU95MSBoT298qt4BmIJb1lUszm+CR+NmqFgRuHfETN/fyRlebmdDhJJ7FVGWKbDK1+yElnTo9tw2EOytigpvjO/gLyFyjComNeEXtBxPetdULc5bgtuf+wMRoyPAoGgdxzp0ghoeNrT2d0ly9tkSqgk09Ppwf4WmngG5/XhJzaDbL0QN4Y2NVW2x0Q0vxuoc3D99BxHrzPtla4OV/ZL6pRFaY+xM1xTFeQwwkO1QjU4zBH8vzCSlbb55MUUow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jodbPyVOggxUDZhiboc/fGMvNetZ9+ahvn1BWGD0+Bs=; b=MRh5s8wQx3WmITuvAendg4Au18UkbdQ2ZcJbI3HNZBmbt7hGd1DfhwRbQs74vaQ9Pq6KQfdF/HFIY+3b7l86VKj3Sxu9K/0wwSfaLFCu6KHD7jIPv01xOG1xHF2df4rC5fZdygwoCtZ+KUyQjzp4UZCmTIeoir6oScPQHwLsFavbVnpgcod+KnQH+SJwj0h2PzzZLLiXM/M+POW1IF7tp8Gfj26josyCtMaYEpq1AJ/f0vq9IRac2Gr9jXL5s08ttizpo/MP/opvS80uk8ddHEDbEFSoKWZFOb8qvoFYHDH1ojh3qzH65cKvP2fNhf9610yitMzkRZ4JjCM8dWElCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jodbPyVOggxUDZhiboc/fGMvNetZ9+ahvn1BWGD0+Bs=; b=eGUSkwkvlxAhYcwL10TnUvfKAaCP/re6xPhG3iWcf8p1266qQnUk99+hw+Vzau0RrnpE1tyL1QAzuxokS6NhgvCwOlTQ3+rVmILOM4aJczEJDt4yEOBaUBfUNTvREdO3VjoirbAN3gxdBmltsePzSpysUoTITru6HOSgXqN/7XtOQ5t1b7DpmK+XKMai4VuHl+RPbIiD0pqVdVSAkRqT8dcCdl42U9OTGX1UdlqNZkZwR9erK3UukuSiQedvmVfr8ibAhWB26gx04NpVGoYzKKAGTuZSD5eUlPid0GPqTVDZ1MF/b0bGtGp4obj59HaCa7YYD4grbpy7viUQEoCntg== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by PA4PR09MB4589.eurprd09.prod.outlook.com (2603:10a6:102:e7::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6768.30; Fri, 8 Sep 2023 02:00:59 +0000 Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::df56:b1b1:64b1:6122]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::df56:b1b1:64b1:6122%7]) with mapi id 15.20.6745.035; Fri, 8 Sep 2023 02:00:59 +0000 In-Reply-To: (Alan Mackenzie's message of "Wed, 6 Sep 2023 11:29:11 +0000") X-TMN: [AYjYq+5In7EhitOI4ek4jI4Kqr+Z6boZipBbY3l2N1Y=] X-ClientProxiedBy: BE1P281CA0129.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:7a::19) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <87cyyt1l0n.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9PR09MB4977:EE_|PA4PR09MB4589:EE_ X-MS-Office365-Filtering-Correlation-Id: 28aad160-0e68-449a-500b-08dbb00f713f X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: WeilPtXvBsbi9CF5heE0ia4tWNbwocQCHzlz6yK51yVuxyAOFgY3lbEMQD2Vde5k9upBcpgy6O1U2dUOhepS6j2N85ZewmOZzM/tz/9nz+8oQ8S8Z1WSQuwKhZuwx1yo9v6vGfn/w6t2CbJtFZCLhsj4jxe4N+4SgZlvJWjmDQeKaQUyP/aZXOVSVsFxq2S0s/L2DqAWu77SsFTM4hjxCxtqaAEtV5dR+ahQltwdWMNcOXrEAypN1SBetdqXjCRwssvXQak24rtBHZISnXw9+vwxAIxijQjPc1GxuAIy2Ppa/SAdg64wCEIrYbT3hRUbMG6/ok6ZBwcqdCZGqUdCO7AlCLmfHKIBZctlSd9LLraSiMF6XZy1GY86jdmJ+n33ORKtVvIV9UZWhZTOK8o5Migz8tls3+A2s5+hj4snvunsXYbYHfmvLmZ2MqBHcW4YOtq5PSugOvtoFEz6UIFpkWPSzdtou9E+JEamvgE2nFH4lREyst8c2rOLAQ6xKSYripyAK4yDJrva/TvCrGFGaRFdaO8zp5JvhxJhGroeW+fx2yFGfEqZ3fcZ1X3YMIYfCAkSep1TR968RRyXNYw8uQ== X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?F+U2aApMab/NW8gehH2RgXiCxQw0jOG4GWjtD9Nswr+q5AMEbFXlwy5QpXuJ?= =?us-ascii?Q?quGzl24UlAhpGEz9eeL5AOD+ijCiQ0adjVm1i3Srj620UzbUybPZc5hmGla2?= =?us-ascii?Q?CnvZMLxcWVD3HmlxxDOzAgSZrjz2KJbmd158uaB8cUOVd4+vi5kqHqiWGXU0?= =?us-ascii?Q?xSFx2U6sa7wf1FYYrbhAYWUQA5awmxlSAh+encE+vICFVnv7+e7MDPF9anUL?= =?us-ascii?Q?NrL+/M7cd0LYmKipGuIX7tX7PAdEqEWKUQjn/b7tqDUL0Db+/p4HV2VOd8yH?= =?us-ascii?Q?V3zmmK2djIBb9kxN7RC5RuNY5EYQIYI1CI+DGAu6rfzTeENL9heb40+EgWGe?= =?us-ascii?Q?+6dOxrJzE7vp2LJ4x3xNf0KVC1A5oLT8JgKQNPmkNQ1kkG7pSD3IT0hrJv78?= =?us-ascii?Q?eYmd2F5akKB+n1RTJ4FWuucbvvIPh0FOgCKG+VlsOHGX9k02z1UvnD3XhNJA?= =?us-ascii?Q?QkT68mwYVnHwmeZkNZJiOz9M/OKXJlyCRzCzBKcj+TgSs8SBzJGxq8bDhEoS?= =?us-ascii?Q?FO8Oo2FBAb45P5kZGGB42X20HefmWW3kcsq71DKMMZHoX2TDHLFhPM6s8jlY?= =?us-ascii?Q?CjXbNj+YWt3dmbTQxmXrKVCKNwfRZBjr76M3kpFRSad0OJGJ8coLIXgNU/CV?= =?us-ascii?Q?QS X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-64da6.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 28aad160-0e68-449a-500b-08dbb00f713f X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Sep 2023 02:00:59.4738 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR09MB4589 Received-SPF: pass client-ip=40.92.91.25; envelope-from=arthur.miller@live.com; helo=EUR05-AM6-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 08 Sep 2023 01:33:06 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310305 Archived-At: Alan Mackenzie writes: > Hello, Arthur. > > On Wed, Sep 06, 2023 at 07:04:43 +0200, Arthur Miller wrote: >> Richard Stallman writes: > >> > [[[ To any NSA and FBI agents reading my email: please consider ]]] >> > [[[ whether defending the US Constitution against all enemies, ]]] >> > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > >> > > Would you please stop arguing for rewriting Emacs in Common Lisp? It >> > > is a non-starter. > >> > > It would be an enormouse job -- including rewriting the Emacs Lisp >> > > Referance Manual. > >> > Also, there are aspects of Common Lisp which i rejected as clumsy and > >> With all respect to you, but sound to me like an emotional argument, not >> a rational one. > > It's a rational argument expressed in emotional terms for simplicity. What you basicaly say: it somehow is a summarization of some more advanced/complicated reasons which can't be explained, but have to be expressed in the term "I don't like it" for the simplicity? I don't think it is a rational argument, but I explicitly didn't want to speculate why RMS feels so, but asked him to clarify for pure respect for him as a person. You can try to teach me why is it a rational argument and why it has to be expressed in emotional terms for simplicity, and I promise I'll try to understand it as best as I can, but I have hard time to see such an explanation, because the argument is truly just an opinion. CL for sure has things that in retrospect can be debated about, but I don't think keyword arguments are one of those. Also note that keyword arguments, or at least similar principle is used in other parts of Emacs, not just cl-lib; for example look at define-minor-mode. While define-minor-mode macro does not use "&key" as an explicit keyword, the arguments to it are a plist which basicaly gives you the very same effect. The "new" defvar-keymap is another example. Keyword arguments are undeniably useful because they let us omit arguments we are not interested in, and type only the ones we are interested in. I don't see how they complicate a Lisp by much; we have &rest and &optional so what is problem having &key? In my personal opinion it is by far more clumsy to have two defun macros, and to prefix one with cl- for no good reason at all; and than have to explain for users why they are two different versions, how they differ, when they should use each, why would they like to use one or another etc. If ordinary "defun" was simply upgraded to act as cl-defun, potential user dilemas and explanations would be avoided. >> I don't know why you reject them as clumsy, but why does it matter to us >> if a tool includes features we don't use? > > It matters a very great deal. In practice you cannot avoid "using" these > features if you have to understand or debug somebody else's code. In practice most of code will use some common part of the language, and relatively little code will use some specialized parts. In a big language that targets many different kind of developers, there will always be features that are needed by some developers but not by all. Falacy in your, by now very tired and wornout argument, is the assumption that everyone will use everything in the language all the time, which certainly isn't the case. Interestingly, yesterday why commuting home after the work, I have heard a talk by Stroustrup, quite recent just a few week old: https://www.youtube.com/watch?v=eo-4ZSLn3jc The talk is more or less about that very argument: why is C++ so big and why are there so many features in c++. (If the link gets removed search on Stroustrup C++ 2023). I think that was one of better Stroustrup's talks, definitely worth watching. There is also an incredibly inspirational talk by Steel (search on "Growing the Language"); I have seen it just a few weeks ago myself: https://www.youtube.com/watch?v=lw6TaiXzHAE Observe that Steel gave us the "most minimal" and "elegant" Lisp as Schemer's like to think of Scheme, which is probably important to remember in the context of this discussion. If you don't watch it, the essence is in this summary, and in my opinion is really a clever insight: "Over the last quarter-century Guy Steele has been convinced that trying to design a complete and perfect programming language is the worst thing you can do. A programming language (including its associated libraries) must grow over time as its user community and its development community grow. This is a different situation from 25 years ago, when all such communities were relatively small. The difference is a problem of scale. As a result, programming language design now and in the future is necessarily as much a matter of social engineering as technical engineering and must rely more on a set of general principles than on a set of specific technical decisions." >> I don't know if I understand it correctly, but CL was made so other >> Lisps can be abstracted on top of it; so we use those features to >> abstract stuff on top of those lengthy verbose functions? In other >> words we can hide those keyword params behind elispy abstractions if we >> don't like them? > > That's complexity and bloat. Far better not to have them in the first > place. Complexity and bloat by which metric? Emacs has long time ago exceeded CL in numbers of "core functions". By the time I have extracted all Lisp defuns from the C core, a couple of months ago or so, it was ~1800 functions in C core. That is by far many more than what CL standard defines. I know that some of Emacs devs are lurking on Reddit behind pseudonims, I don't know if you are one of them, but there are also quite many users who consider Emacs to be quite bloated and would like many of some older parts to be expunded out of the core. Anyway, by the nature of Lisp, there are very few actual language concepts, and there are quite few additional concepts that CL offers that need support of the system that are not found in Emacs; but most of additions to the language are actually looking exactly like the language itself. The nice thing is that, when you write a defun in Lisp, it becomes part of the language itself, unlike languages like Java, C, C++ etc where users can not extend the language itself since the syntax has to be encoded in the compiler. In other words, it means, that even if you don't want it, people can extend it the way they like it, and cl.el was a proof. >> > best avoided. > >> Why are they best avoided? Is there some technical reason or is it >> psychological? > > It's because they are not needed. Bear in mind, Common Lisp is a massive I don't know if you agree with me or not, but in order to drive from Nuremberg to Berlin you certainly don't need AC in a car; but on a hot summer day, with 40 degrees (celsius) it is very nice to have AC in the car, isn't it? Sure, keyword arguments are not needed; but they are handy from time to time. Optional or rest arguments are not needed either, but they too are nice to have sometimes, aren't they? What makes keyword arguments more "clumsy" then? To be honest to you, I really didn't want to answer this mail, because I see just very same arguments I have seen many, many times before. I had very much, very same sentiment about C++ as you, and I didn't even know much of CL at all; I just thought it was big and bloated and didn't want to use it, untill not so long time ago. Untill perhaps a year or two ago, when I invested some time in learning more about CL and tried to understand why things are as they are, not just in CL, but in general; C++ very much included. > It's because they are not needed. Bear in mind, Common Lisp is a massiveI > language, much like C++ or PL/1 or Algol-68. With such a language, > nobody uses all of it (it's just too big), but everybody has her own > personal subset. This creates difficulty when somebody else has to > understand that first hacker's code. I totally understand you; but I believe this is a bit misguided. For the first, for the same argument as above, nobody uses the entire language because they don't need it; not because it is too big. Some parts target certain specialized domains which are needed by some groups and not by everyone. I think that is more true for C++ and less for CL, because CL is not that massive as you are trying to make it. CL is also a child of its time, just like Emacs, and some parts are probably in need of a revision, but it certainly stands the proof of time when it comes to core language principles. If we look at this: (defun directory-files (directory &optional full match nosort count) ...) When you call this function in the code; how easy is to remember the order and number of arguments? Was it 5 or 6 arguments? I had fortune to contribute the idea for the 5th argument, and yet I typed by a misstake the wrong number: CL-USER> (directory-files "./" nil nil nil nil 5) ; Debugger entered on # [1] CL-USER> ; Evaluation aborted on # CL-USER> (directory-files "./" nil nil nil 5) ("alloc.lisp" "buffer.lisp" "callint.lisp" "callproc.lisp" "casefiddle.lisp") CL-USER> If I only change &optional to &key: (defun directory-files (directory &key full match nosort count) ... ) I can now type: CL-USER> (directory-files "./" :count 5) ("#dired.lisp#" ".#dired.lisp" "alloc.lisp" "buffer.lisp" "callint.lisp") CL-USER> How "clumsy" is that? Honestly, I am not trying to be PITA or devil's advocate or anything like that; but I think that everyone will agree that the second one is both nicer, less error prone to type and puts less cognitive load on users to remember or lookup the information. Just as a remark: by just having it in CL I was able to just go to the code, and change "optional" for "key", C-x C-e in Sly and I changed the implementation of "directory-files", nice? For the record if you want to try it (just a fast hack for the demonstration purpose, needs cl-ppcre lib): (defun directory-files (directory &key full match nosort count) (let ((files (if full (mapcar #'namestring (uiop:directory-files directory)) (mapcar #'file-namestring (uiop:directory-files directory))))) (when match (let ((scanner (ppcre:create-scanner match)) matches) (dolist (filename files) (when (ppcre:scan scanner filename) (push filename matches))) (setf files matches))) (unless nosort (setq files (sort files #'string-lessp))) (when (and (numberp count) (> count 0)) (when (> count (length files)) (setf count (length files))) (setf files (subseq files 0 count))) files)) Observe also that I agree with you; keyword arguments are not needed, but are very nice to have. > CL is a niche language; it has not captured the hacker mindset. I think > it is just too big and too unwieldy. > >> > best avoided. All those keyword arguments! I intentionally excluded >> > tham from Emacs and I am not going to let them in. > >> I don't want to be impolite, but they are already in; via cl-lib.el. > > Yes. There was a time not so long ago when cl.el was banned from use in > our Lisp code, except for at compile time. Our Emacs Lisp was small, > simple to understand, and easy to learn. Now things in cl-lib.el get > used as if they are just a normal part of Emacs Lisp. Our language is > thus MUCH more difficult to understand, perhaps by a factor of somewhere > between 3 and 10. When perusing even established parts of Emacs I groan > inwardly every time I encounter one of these needless cl-lib features. > It stops me dead, forcing me to consult doc strings (which are often > missing and often inadequate even when they are present) or even manuals. "MUCH more difficult" for whom in which sense? What you are telling is that "good old times were so much better" which is just an emotional argument. You are actually just reinforcing the same sentiment that RMS expressed. I shared that sentiment myself, but I think it is misguided. We can certainly speak about "old ways", let us take the or-idiom or how should I call it: initialization of the default value for optional arguments: (defun foo (&optional who-am-I) (let ((who-am-I (or who-am-I "foo"))) (message "I am %s." who-am-I))) Is that really better than typing: (cl-defun foo (&optional (who-am-I "foo")) (message "I am %s." who-am-I)) The user has to learn the idiom, which uses operator "or" to perform something that visually has nothing to do with the intention of the code, and also has to type the additional let-form each and every time. Than the users who are not familiar with the idiom will perhaps come up with their own version, using setq or some other thing, and you will really have to think what the user wanted to say with their code if you had to debug it. Is it better than seing an initialiser and knowing directly what is the default value and everyone using uniform syntax? There was a discussion, perhaps a couple of years ago, I think on Emacs help list, I don't remember the detials, but I think something about car, cdr, cdar, cddr & co, and using "nth" instead of them. Monnier said a clever thing there: using those old functions is like writing in assembler, but without the benefit of additional speed (something in that sense). I think he was more than correct there. It is much more clear to say (nth N list), than to chain cars and cdrs together. A bit further, that really is about abstractions. We can for sure do lots of stuff manually, without higher-level abstractions; but higher level abstractions, like using initializer in a defun arguments, help us convey the meaning more clearly and concize, we can rationalize about abstractions, and they are probably easier to remember than teaching people how to use some common pattern or idiom. I also happened to read the CMUCL manual just yesterday. They have a nice writing about using structures instead of lists in CL: "Even if structures weren't more efficient than other representations, structure use would still be attractive because programs that use structures in appropriate ways are much more maintainable and robust than programs written using only lists. For example: (rplaca (caddr (cadddr x)) (caddr y)) could have been written using structures in this way: (setf (beverage-flavor (astronaut-beverage x)) (beverage-flavor y)) The second version is more maintainable because it is easier to understand what it is doing." https://cmucl.org/downloads/doc/cmu-user-2010-05-03/compiler-hint.html#toc189 > Were we to rewrite Emacs in Common Lisp, these things would get worse > fairly quickly. I think you are very, very wrong about that one; on the contrary we would get some tools that Emacs is lacking to manage the code complexity, but I don't think they are actually applicable on the existing code, so they don't matter much. But things certainly wouldn't get worse. That is just my opinion of course, you can think I am an idiot and I can be wrong, but at least give me a reason to change my mind that isn't based on subjective opinion.