From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id wOZRB5XB7V/yMgAA0tVLHw (envelope-from ) for ; Thu, 31 Dec 2020 12:18:29 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id iNsgA5XB7V9nTQAA1q6Kng (envelope-from ) for ; Thu, 31 Dec 2020 12:18:29 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 29D54940149 for ; Thu, 31 Dec 2020 12:18:28 +0000 (UTC) Received: from localhost ([::1]:50792 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kuwuQ-0005wA-31 for larch@yhetil.org; Thu, 31 Dec 2020 07:18:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40658) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kuwtx-0005u7-8u for emacs-orgmode@gnu.org; Thu, 31 Dec 2020 07:17:58 -0500 Received: from basilikum.nobis-admin.de ([89.238.71.130]:53164) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kuwtq-0007aI-Ko for emacs-orgmode@gnu.org; Thu, 31 Dec 2020 07:17:56 -0500 Received: from bohne (p200300cd670bea00118f49b30e48892c.dip0.t-ipconnect.de [IPv6:2003:cd:670b:ea00:118f:49b3:e48:892c]) by basilikum.nobis-admin.de (Postfix) with ESMTPSA id D79376D80C9B for ; Thu, 31 Dec 2020 13:17:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snobis.de; s=default; t=1609417063; bh=4dmhAfCVD9E2O65w2afP8YR3h1rwxmJiN1SGuu0IyPw=; h=From:To:Subject:References:Date:In-Reply-To:From; b=g67tlNiaa4LRqUqykMnMCxkIuvWQhfUYTh0jmqj8T4RjGY0E2rgOCzRBOKQHr3Yl7 rmI5zxRmE39aWU6KDaseeEwN33i23JWLQPdmPX3kEUSoFf+Wqk2eILwbhIox0cqz/T laAGjCNWRGfrHxXd5/T0tf5RiKhzLuAXc7ip1gV8= From: Stefan Nobis To: emacs-orgmode@gnu.org Subject: Re: Microsoft Excel spreadsheet editing directly from within emacs. References: <69f2606a-105d-75e8-61aa-e4df82c9f445@grinta.net> Mail-Followup-To: emacs-orgmode@gnu.org Date: Thu, 31 Dec 2020 13:17:43 +0100 In-Reply-To: (Jean Louis's message of "Thu, 31 Dec 2020 01:19:49 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=89.238.71.130; envelope-from=stefan-ml@snobis.de; helo=basilikum.nobis-admin.de 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.53 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=snobis.de header.s=default header.b=g67tlNia; dmarc=pass (policy=reject) header.from=snobis.de; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 29D54940149 X-Spam-Score: -1.53 X-Migadu-Scanner: scn1.migadu.com X-TUID: PmKFuvjuR6kv Jean Louis writes: > You speak of a programming language and what is possible with > programming language. That's not the point. Org table is integrated with Calc and Calc is a Computer Algebra System. That is something like Excel combined with Mathematica (with a little less GUI stuff) - that is powerful integration to me. Lisp is nice and for me as a programmer a helpful tool. But the main point is Calc. Just putting data in a tabulated form is seldom the interesting part. It starts to get interesting when you try to do something with the data, e.g. make some calculations. At this point it is significant, how many calculations you can do out-of-the box (without much programming). I did not count, but I assume that Calc has more calculations to offer than Excel and even for a wider range of topics (even symbolic math). Therefore, from this point of view of core functionality, I would say Org tables with Calc are more powerful that MS Excel. And thinking of the many quirks and bugs in MS Excel, I still say: Excel is the toy software and Emacs + Org + Calc is more mature and more professional and the file format much more future proof (yes, nowadays Excel uses XML, but the definition and documentation is lacking and too complex; it seems not possible to re-implement it fully). I emphasize this, because you wrote: "In comparison to all major known spreadsheets Org tables is not powerful and not even comparable." And "powerful" for me means core features, i.e. calculations. And in this respect, I think the statement is wrong. > In a spreadsheet program I may visually and nicely presented see a > slice of a whole table. I may move from slice to slice to other > pieces of the whole table of data. Moving from cell to cell is > pretty easy and there are no screen distortions. If your point of view is, that the main feature are the visual interactions (hiding/revealing rows/columns, sorting, filtering data etc.) then yes, maybe Org lacks a bit in these areas (but I think not quite as much, as you imply; e.g. Org can show labels for rows and columns and there are ways for hiding, sorting and filtering). On the other hand: I do find GUI spreadsheets also quite lacking in this regard (e.g. regex pattern are seldom easy to use). If I need to tinker with data, explore it, I would put it into a database (or into R or Julia or - depending on the size of the data - using R/Julia from within Emacs via Org tables). That's much faster, maintainable and reproducible. > Spreadsheet user interface is integrated, it does not require user > to remember much, or maybe nothing, just use a mouse. Nice try: There are tons of books about the question what are the best user interfaces. I have seen people working with computers with exactly this mindset: "I do not need to learn/remember anything, it should be easy, just clicking a bit with my mouse". At this level, it just does not work. So, yes, a very text-oriented UI is not the best solution for every task. But then a GUI is also not the best solution for every task. > Org mode is bringing us back into the era before Doug Engelbart. > Back to history. That's IMHO a very simplistic and ignorant view on UX. The problem is much more complex and yes, in quite some cases are text-based interfaces even one of the best solutions (and next to never exists a single best solution, UX always depends very strongly on context and details). > Combining various sheets is standard spreadsheet feature. Examples > you have shown are cryptic for spreadsheet users. I once showed rather simple Excel sheet to an Excel user and he was overwhelmed and did not understand how to create such a structure (2-3 tables with formulas across tables). So Excel is cryptic for spreadsheet users, too. :) With other words: No tool is simple, you need to learn at least a little bit - in all cases. I only showed the final result, not the way how it has been created. Emacs and Org have ways to ease some of the seemingly complicated parts, just as Excel tries to help formulate complicated calculations. And then comes habit. I fully understand that a tool like Excel at least seems to be easier for the first steps. But that does not mean that it is a given fact, that it is easier and better suited for any task that is spreadsheet like (you already mentioned databases - I would say for the typical spreadsheet users databases are even more cryptic that Emacs and Org). >> Maybe advanced visual presentation of the data is easier with GUI >> Spreadsheets -- then again, it is so easy to combine Org tables with >> the power of Gnuplot, R, Python, Julia, TeX etc. to create >> astonishing visuals, that I prefer this way in many situations. > That is like saying to a user to switch from Emacs to C programming > language as it gives user far more capabilities No, quite the contrary. I think, this is the main point, you seem not to understand. Emacs with Elisp is much more expressive than C. Org with Calc is (for calculations) more expressive than Excel. And this expressiveness can help in efficiency and maintainability. Is this the one and only solution for everyone? No, of course not. But you seem to imply, because some data viewing aspects and the very first steps with spreadsheet programs may(!) be easier with tools like Excel, everyone who needs some spreadsheet-like tools should always only look at Excel or LibreOffice. With this argument you could also say that no one should use CAD tools - with Paint you can draw everything and 3D modelling with CAD is too complex and has a very steep learning curve. We talk about Org users and therefore Emacs users. Not every Emacs user knows about Calc, but some do and other may benefit from learning about it. And for users already comfortable with Emacs and Org, Calc and the combination of Org tables with Calc may be even easier to handle than Excel or LibreOffice. That's the point: GUI spreadsheets have some disadvantages (and some advantages) when compared to Org tables; maybe not many, maybe not relevant for everybody - but they exist. Thus GUI spreadsheets are not the best tool for everybody and all tasks. And I never said, that Org tables should strive for world domination (hmmm... maybe it would be a better world). I just questioned your statement, that Org tables are a toy and not really up to real tasks that Excel et. al. can handle and that only GUIs provide good UX. BTW: I know quite some people missing good old mainframe UIs. A simple text based mask with only a couple of actions to be executed via F-keys. And todays mobile apps are rather a revival of those simple mainframe screens (more shiny and with touch instead of F-keys) rather than a copy of complex desktop GUIs. > Users need integration, they don't mind of the mentioned powers. > They want to enter rows, columns and click button and get a chart. This is possible with Org tables - besides the point that not every user is the same. I fully understand that Emacs is not the tool for everyone, neither is Org. In my younger days I often tried (sometimes very hard) to convince people to use LaTeX or Linux (or both). I learned my lessons. :) But just because there are some or even a majority of people that prefer tool A does not mean that you should advocate tool A to everyone. There might be quite some people that would much more benefit from using tool B or C. I've been a teacher for adult evening classes, I know a little bit about how Jane or Jo User struggles with computers. But I've also seen how some of these everyday users are able to use complex tools. It's just not as simple and black-and-white as you picture it. As a loose analogy: See how Maker spaces are flourishing nowadays. There are many people that are eager to understand, how the world is build (at least some parts of it). Yes, that is not true for everyone, but do not underestimate curiosity and the fun to tinker. Even nowadays new, young users discover Emacs and love to use it (despite all the shiny sparkling GUI and web-based tools out there). -- Until the next mail..., Stefan.