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=MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18386 invoked from network); 6 Feb 2022 18:37:36 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 Feb 2022 18:37:36 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id DF0AD9D3DC; Mon, 7 Feb 2022 04:37:30 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 85D439D02E; Mon, 7 Feb 2022 04:37:02 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 666849D02E; Mon, 7 Feb 2022 04:36:58 +1000 (AEST) Received: from darkstar.fourwinds.com (fourwinds.com [63.64.179.162]) by minnie.tuhs.org (Postfix) with ESMTPS id 881779D02D for ; Mon, 7 Feb 2022 04:36:57 +1000 (AEST) Received: from darkstar.fourwinds.com (localhost [127.0.0.1]) by darkstar.fourwinds.com (8.16.1/8.15.2) with ESMTP id 216IauGb3502693 for ; Sun, 6 Feb 2022 10:36:56 -0800 Received: from darkstar.fourwinds.com (jon@localhost) by darkstar.fourwinds.com (8.16.1/8.15.2/Submit) with ESMTP id 216IatiC3502688 for ; Sun, 6 Feb 2022 10:36:56 -0800 Message-Id: <202202061836.216IatiC3502688@darkstar.fourwinds.com> From: Jon Steinhart To: TUHS main list In-reply-to: <20220206141558.GO3045@mcvoy.com> References: <1644006490.2458.78.camel@mni.thm.de> <20220206005609.GG3045@mcvoy.com> <21015c2c-2652-bbc3-dbd7-ad3c31f485a2@gmail.com> <20220206141558.GO3045@mcvoy.com> Comments: In-reply-to Larry McVoy message dated "Sun, 06 Feb 2022 06:15:58 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3502686.1644172615.1@darkstar.fourwinds.com> Date: Sun, 06 Feb 2022 10:36:55 -0800 X-JON-SPAM: local delivery Subject: Re: [TUHS] more about Brian... [ really GC vs malloc/free languages ] 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: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Larry McVoy writes: > Let's keep it civil and non-personal, I don't think Rob was pointing > at anyone, I think he was pointing at some not so forward thinking. > > I have to side with Rob on this one, even though I'm squarely in the > I like C best camp. > > While I _can_ do all the malloc/free stuff myself (and have decades of > working code to prove it), it's become harder and harder to find other > people who can. Younger programmers just sort of stare at you with a > "I have to do what?" look. They think you are a dinosaur for working > like that when other reasonable languages do that work for you. > > When I did little-lang.org, granted, not widely used but we used it a > lot, it did all the memory management behind the scenes, used reference > counting so you never had the big GC sweep that some languages used, > worked great. And super pleasant to not have to do all that memory > management. > > Having the languages do more for you, and put up guard rails so people > can't make stupid mistakes, seems to be the way of the future. It's > not my future, I love C, it does what I want and I can live with what > it needs me to do to have working code. But I'm a dinosaur and I > know it. I'm not trying to push C where people don't want it. I look at this from a different perspective. The world needs a lot of programmers these days. It takes a lot of work to have internet-connected refrigerators push advertising, to make washers and dryers sing about their work, to have Bixby piss off Samsung phone users, to ensure that IoT devices are insecure, and of course to leak personally identifying information on government web sites. This is critical work and there just aren't enough "good" programmers to go around. I view people that programming for Android, making web pages unusable, and so on, as if they're using domain-specific languages. The difference is that while many of us grew up loving domain-specific "little languages" these languages are huge. While I'm not an expert here, I'm sure that being an expert in the Android, IOS, Java, or WWW ecosystems involves more "learning" than many of us had to do when we learned our craft. A big problem with our profession is that we have no agreed on terminology to distinguish among practitioners. A story told to me by a co-worker in the '80s illustrates this well. Ken had gone home for Christmas with his family. One of his uncles took him aside and asked something like "Hey, you're a computer guy. Can you help me with this .COM and .BAT stuff?" Ken replied "Don't have a clue what you're talking about." When Ken related this story to me, he said "The funny thing about it was that we both walked away thinking that the other person didn't know anything about computers." I think some of what we're debating here is whether or not "programmers" need to understand fundamentals. Many of us think that they do, but we're not the ones working on a subscription model for starting your car. I replaced my deck last summer. Had to do a lot of contractor interviewing. I didn't choose one who said "I can do it" and showed me photos of work he had done. I chose one who said "I can do it" and looked around and said "You know, won't be able to tell until I get the old one removed but I think that there some things that need fixing underneath." Another example, because I'm also a hardware engineer. Many digital circuit designers think that digital is an isolated domain. There was a time a few decades ago when an analog engineer couldn't get a job. But then there was an awakening when folks realized that everything was analog at its core and all of a sudden "full stack hardware engineers" were writing their own tickets. Sure, many digital designers said "Why do I need to know this stuff? Nobody uses Rubylith anymore and the DRC (design rule checker) software takes care of stuff for me. Analog designers bail those people out when things don't work. To me, a big problem with what I'll call domain-specific programmers is that they get involved in standards and specifications and aren't trained in how to abstract. So standards are produced that result in enlarged, more complex domains. One of the best examples is CSS, a standard that is too complex to be documented. I have no clue as to how many CSS properties exist anymore. It's not cleanly designed, and of course with the addition of each new property the interaction matrix grows exponentially. And the increasing number of mode-switching properties is growing the number of interaction matrices. There are literally thousands of things a CSS "programmer" needs to know, yet people still ask question like "How do I vertically center something" because it's still hard to do. Even the worst programming language is orders of magnitude simpler than CSS. But hey, CSS isn't "programming" so of course it's better. Bottom line to me is that people with serious expertise are always going to be needed. Someone has to design the hardware, someone has to make the tools used to design the hardware, someone has to implement programming languages and operating systems and all that. But that's a different domain than what the majority of the world wants today. Jon