From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 313b64e7 for ; Sun, 12 Jan 2020 21:04:25 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id C23A19BD57; Mon, 13 Jan 2020 07:04:24 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id BEDDB9BD14; Mon, 13 Jan 2020 07:03:56 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="key not found in DNS" (0-bit key; unprotected) header.d=kev009.com header.i=@kev009.com header.b="Ns57iH65"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id A10649BD14; Mon, 13 Jan 2020 07:03:53 +1000 (AEST) Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) by minnie.tuhs.org (Postfix) with ESMTPS id 593669BD0F for ; Mon, 13 Jan 2020 07:03:51 +1000 (AEST) Received: by mail-il1-f172.google.com with SMTP id c4so6207504ilo.7 for ; Sun, 12 Jan 2020 13:03:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kev009.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hnI1/SQTYGe+NpvrLnERHVIy4sp72EcNJaPBk2y73q4=; b=Ns57iH65B0HfMRnygMSdFWG1J/sAbZz1wdbcPs+kqHFMLAOxKWfUHthTcbtaeBtAjC VwmPknO8IPC9KOL0xAnQqRxWZkwNlU7emwn5AJa6XIqMz9kbUhorlUOBLpivyd5nlqLD Q5Ja63vPgEr6kqaI8lu1IKwoQOi/pnZEqPCo4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hnI1/SQTYGe+NpvrLnERHVIy4sp72EcNJaPBk2y73q4=; b=Bw4rC5qUd65+XWnTF2KJXKSWixgqJGK6lHYySqmK1YxjYoWfhGb6iEW1T61OGu0q9w 4dT0N1PF1YynlJJWKDZuV4LtXJlH/B9NISmdTAfYGc2/Gdg/2vtvkl9Ju4hMcicPA05p qJMvlr18BC5Yna2utdWEP/REvJ0Fs89cUw9KsUjae8QxL44d365Gb+gjerL4vvN5QTws au8dsSWx+DpMHXBGtEH+SXbP4v3qG1gfDlDRNYyWLoRm9Wg+79lOW4VTCwwpIU0lBroI fE+mArH1kf/T6Ldz8q9fwO/L7FOaptvxavGJLMATxkBY8q2G3ldT9TV/1epcnJu6Hlvl A6Ag== X-Gm-Message-State: APjAAAVyF5nrMuYPkCIdbtUDzqSbjiruF+SFaKATVW7+qhc52apwMKnQ IzFrXGzn5d+54C5L78LWO3h0IqTH/AOIp1fLm+DxCWzHRDQ= X-Google-Smtp-Source: APXvYqyC5zoCEO/nrDBT07u5NC1IzXBm2OArHHUPznjKDf8rVQgMuF0IfCkR6L3Ngp4hC+mFBZ/iyfCB0lI7dyKk47A= X-Received: by 2002:a92:3a02:: with SMTP id h2mr12438184ila.236.1578863030557; Sun, 12 Jan 2020 13:03:50 -0800 (PST) MIME-Version: 1.0 References: <202001121343.00CDhYHK132101@tahoe.cs.Dartmouth.EDU> <202001122034.00CKYQ39571239@darkstar.fourwinds.com> <202001122044.00CKiUNV573279@darkstar.fourwinds.com> In-Reply-To: <202001122044.00CKiUNV573279@darkstar.fourwinds.com> From: Kevin Bowling Date: Sun, 12 Jan 2020 14:03:39 -0700 Message-ID: To: Jon Steinhart Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] Tech Sq elevator (Was: screen editors) X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On Sun, Jan 12, 2020 at 1:45 PM Jon Steinhart wrote: > > Kevin Bowling writes: > > I honestly can't tell if this is genius level snark :) in case you're > > sincere we generally go to great lengths to build up data types and > > structures (in C lingo) when programming only to tear those useful > > attributes off often at inopportune times. Basically type > > systems/type safety have been too expensive or too difficult to use > > through history. > > > > Think of sitting at an SQL prompt as a counterpoint. You can pretty > > easily get at the underlying representation and relationships of the > > data and the output is just a side effect. Not saying SQL is the > > ultimate answer, just that most people have a bit of experience with > > it and UNIX so can mentally compare the two for themselves and see the > > pros and cons to preserving the underlying representations. > > > > Regards, > > Kevin > > > > On Sun, Jan 12, 2020 at 1:34 PM Jon Steinhart wrote: > > > > > > Kevin Bowling writes: > > > > This is kind of illustrative of the '60s acid trip that perpetuates in > > > > programming "Everything's a string maaaaan". The output is seen as > > > > truth because the representation is for some reason too hard to get at > > > > or too hard to cascade through the system. > > > > > > > > There's a total comedy of work going on in the unix way of a wc > > > > pipeline versus calling a length function on a list. Nonetheless, the > > > > unix pipeline was and is often magnitude easier for a single user to > > > > get at. This kind of thing is amusing and endearing to me about our > > > > profession in modern day. > > > > > > > > Regards, > > > > Kevin > > > > > > Can you please elaborate? I read your post, and while I can see that it > > > contains English words I can't make any sense out of what you said. > > > > > > Thanks, > > > Jon > > I wasn't being snarky. You said > > "The output is seen as truth because the representation is for some > reason too hard to get at or too hard to cascade through the system." > > I honestly have no idea what that means. If the SQL prompt example did not clarify you are welcome to go one on one if this is something you think is curious to you, I think I've explained the point I was making adequately for a general audience. > > Likewise, > > "There's a total comedy of work going on in the unix way of > a wc pipeline versus calling a length function on a list." > > I just don't know what you mean. > Reason through what happens in a shell pipeline, the more detail the better. A quick nudge is fork/exec, what happens in the kernel, what happens in page tables, what happens at the buffered output, tty layer etc. Very few people actually understand all these steps even at a general level in modern systems. If you had a grocery list on a piece of paper would you a) count the lines or read it directly off the last line number on the paper if it is numbered b) copy each character letter by letter to a new piece of equipment (say, a word processor), until you encounter a special character that happens to be represented as a space on the screen, increment a counter, repeat until you reach another special character, output the result and then destroy and throw away both the list and the word processor equipment. This kind of thing doesn't really matter in the small or at all for performance because computers are fast. But most programming bugs in the large eventually boil down to some kind of misunderstanding where the representation was lost and recast in a way that does not make sense. Regards, Kevin