From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10658 invoked from network); 9 Dec 2020 17:07:49 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 9 Dec 2020 17:07:49 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id DF29B93D34; Thu, 10 Dec 2020 03:07:39 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 1DEFB93D5C; Thu, 10 Dec 2020 03:07:20 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=iitbombay-org.20150623.gappssmtp.com header.i=@iitbombay-org.20150623.gappssmtp.com header.b="sMEtgmrl"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id A955393D5C; Thu, 10 Dec 2020 03:07:17 +1000 (AEST) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) by minnie.tuhs.org (Postfix) with ESMTPS id 553C6944FF for ; Thu, 10 Dec 2020 03:07:15 +1000 (AEST) Received: by mail-oi1-f178.google.com with SMTP id o25so2455107oie.5 for ; Wed, 09 Dec 2020 09:07:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=5OPtE5MohykDY3SfiRU+0YmozBcO1ttqV+zhp/tVAyk=; b=sMEtgmrlFk7xkgMTr92sPSrEJnPyvp3KsuCZQw+nXG2+kFbVO6evXPXziZpOsREYbm 4WPzkhZd+6bkOELF4vTRgxAzruuXeojlA0sK8UMJLZgtJXJEEi89aswtEhuhXKC4Sh2x sMkPamQdozbWeh7/It5bl8kAhFhqVBE8dZlR7i+0xzaPOp1lz9z1OmWlNXGvO9FH352H +bH9lyAhhPbGNk4lyN5cBd2sGP0B7hx+TtD6ZBQCWvL6FRg9mjhLNsVvkNUIewPHKoyK c6pSgg70cIaw6lHfDCH+6iV0Ibx4+zYU5Qy7A3YvXQIMkPzfylfxZAau1cLBxnDrCb2y tZ2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=5OPtE5MohykDY3SfiRU+0YmozBcO1ttqV+zhp/tVAyk=; b=XXWaYaBeQnOGHxz06PdIqMUQPmIGz3tiT6+uTEBA3JroIvfrjdTXs/e0BGE9Mq74/V s7xM2pOT+S3PIjg3ROk9Hkv6aQZmeAp1t/57E/USHE6wGfuShy7d9/ZLCLhtJ4v1Btp0 ZzTy7D4+PFmB1hKobJ+B3cdaPVebXZqT0vELBdQwS3J3K0OfkvSREl0zVtlB6n7HNQHV KZJDckFijX2LgFVO3VoWecVinkHj40I1tNSw8yt3g6yLxE5gNT9tPhbZV4kquk8tTag3 tMvcQ7ZzbpcNeIUUJDkg3sJTXyb/VErqaOMmffY6cVHxStUnCfgINT2xowds1SaCOBAt 4jRQ== X-Gm-Message-State: AOAM533VIKxz8dGpxjD4Kuo2Du+wNMJwqDrFr2Nn2+MN5LyACzKRM1fV 0M5+NEJnfC5wISxgn6atbwb95A== X-Google-Smtp-Source: ABdhPJyC6Stt0grFggPmCVw6D1bFt7j4UQm+TpIpUKpUvfYzqvuCoiHfXvlGeQYtCKHg+03BQyiEnQ== X-Received: by 2002:a05:6808:2c4:: with SMTP id a4mr2526080oid.114.1607533634576; Wed, 09 Dec 2020 09:07:14 -0800 (PST) Received: from ?IPv6:2600:1700:42f2:310:a9e3:d1ff:e921:6cbf? ([2600:1700:42f2:310:a9e3:d1ff:e921:6cbf]) by smtp.gmail.com with ESMTPSA id g21sm489802otj.77.2020.12.09.09.07.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 09:07:13 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-79AA2E9C-C237-46C3-AF31-7523BD2C2028 Content-Transfer-Encoding: 7bit From: Bakul Shah Mime-Version: 1.0 (1.0) Date: Wed, 9 Dec 2020 09:05:43 -0800 Message-Id: References: In-Reply-To: To: Clem Cole X-Mailer: iPad Mail (18B92) Subject: Re: [TUHS] Were cron and at done at the same time? Or one before the other? 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" --Apple-Mail-79AA2E9C-C237-46C3-AF31-7523BD2C2028 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ah .. but I don=E2=80=99t know if they did! The implication that Pascal folk= s like complexity seems strange as Pascal is far simpler than C++ (not much l= arger than C) and C++ is no more type safe than C (both are less type safe t= han Pascal). Anyway I will stop now!=20 > On Dec 9, 2020, at 8:11 AM, Clem Cole wrote: >=20 > =EF=BB=BF > Ah .. but all the Pascal folks got on the C++ bandwagon when it was clear C= had won. Frankly, the death of C++ IMO was all the crap added too it, but w= e have moved in COFF territory and off of Unix and Unix philosophy I think. >=20 >> On Wed, Dec 9, 2020 at 11:01 AM Bakul Shah wrote: >> please don=E2=80=99t blame c++ on pascal folks. stroustrup had nothing to= do with pascal. =20 >>=20 >>>> On Dec 9, 2020, at 7:41 AM, Clem Cole wrote: >>>>=20 >>> =EF=BB=BF >>> Amen Doug. >>>=20 >>>> On Tue, Dec 8, 2020 at 11:36 PM M Douglas McIlroy wrote: >>>> To paraphrase John Cocke (speaking about Fortran): one must understand >>>> that Unix commands are not a logical language. They are a natural >>>> language--in the sense that they developed by organic evolution, not >>>> "intelligent design". >>> But I offer a suggestion that another dimension that should be forgotten= in time scale and the economics within. >>>=20 >>> When things evolve they do so on different clocks that are not necessari= ly linear. i.e. what was 'better' (winning) today, but might not be consid= ered so tomorrow, however could yet prove otherwise sometime later. I use p= rogramming languages as a great example... There was a huge C vs Pascal de= bate, that C 'won' - but I've always said the rise of C++ came from the Pasc= al folks that could say "C didn't win." =46rom the ashes of C++ we have Jav= a, Go, and Rust.=20 >>>=20 >>> My point is that "intelligent design" doesn't necessarily guarantee go= odness or for that matter,complete logical thinking. >>>=20 >>> My own take on this is what I call "Cole's Law" Simple economics alway= s beats sophisticated architecture. >>> What you call organic evolution is what I think of what makes the best e= conomic sense for the user and that is a function of the time scale and avai= lable resources at the time of creation/deployment. >>>=20 >>> Clem >>>=20 --Apple-Mail-79AA2E9C-C237-46C3-AF31-7523BD2C2028 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ah .. but I don=E2=80=99t k= now if they did! The implication that Pascal folks like complexity seems str= ange as Pascal is far simpler than C++ (not much larger than C) and C++ is n= o more type safe than C (both are less type safe than Pascal). Anyway I will= stop now! 

On Dec 9= , 2020, at 8:11 AM, Clem Cole <clemc@ccc.com> wrote:

=EF=BB=BF
Ah .. but all the Pascal folks got on the C++ bandwagon when it was clea= r C had won.  Frankly, the death of C++ IMO was all the crap added too i= t, but we have moved in COFF territory and off of Unix and Unix philosophy I= think.

On Wed, Dec 9, 2020 at 11:01 AM Bakul Shah <bakul@iitbombay.org> wrote:
please don=E2=80=99t blame c++ on pascal folks. stroustrup had nothing to d= o with pascal.  

On= Dec 9, 2020, at 7:41 AM, Clem Cole <clemc@ccc.com> wrote:

=EF=BB=BF
Amen Doug.

On Tue, Dec 8, 2020 at 11:36 PM M Douglas McI= lroy <m.douglas.mcilroy@dartmouth.edu> wrote:
To par= aphrase John Cocke (speaking about Fortran): one must understand
that Unix commands are not a logical language. They are a natural
language--in the sense that they developed by organic evolution, not
"intelligent design".
But I offer a suggestion that another dimension that should be forgotten in= time scale and the economics within.

When th= ings evolve they do so on different clocks that are not necessarily lin= ear.   i.e. what was 'better' (winning) today, but might no= t be considered so tomorrow, however could yet prove otherwise sometime late= r.  I use programming languages as a great example...   There= was a huge C vs Pascal debate, that C 'won' - but I've always said the rise= of C++ came from the Pascal folks that could say "C didn't win."&= nbsp; =46rom the ashes of C++ we have Java, Go, and Rust. 

My point is that   "intelligent design" doesn't= necessarily guarantee goodness or for that matter,complete logical thi= nking.

=
My own take on this is what I call "Co= le's Law"   Simple economics alw= ays beats sophisticated architecture.<= /i>
What you call organic evol= ution is what I think of what makes the best economic sense for t= he user and that is a function of the time scale and available resources at t= he time of creation/deployment.

Clem

= --Apple-Mail-79AA2E9C-C237-46C3-AF31-7523BD2C2028--