From owner-freebsd-questions@freebsd.org Tue Oct 17 20:45:29 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50BCAE472E1 for ; Tue, 17 Oct 2017 20:45:29 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 213B282F7B for ; Tue, 17 Oct 2017 20:45:28 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.15.2/8.15.2) with ESMTPS id v9HKj2ha045397 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Oct 2017 14:45:02 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.15.2/8.15.2/Submit) with ESMTP id v9HKj2p9045394; Tue, 17 Oct 2017 14:45:02 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 17 Oct 2017 14:45:02 -0600 (MDT) From: Warren Block To: "Frank Leonhardt (m)" cc: Paul Pathiakis , Paul Schmehl , Polytropon , "freebsd-questions@freebsd.org" Subject: Re: Scripting problem In-Reply-To: <5D3BAA54-3229-4472-8A4D-A10D3F3F07D9@fjl.co.uk> Message-ID: References: <7AB396F429EEB6890100F082@Pauls-MacBook-Pro.local> <8C8E7D66788801594EC0FC4C@Pauls-MacBook-Pro.local> <20171008100017.30ab5987.freebsd@edvax.de> <88D321A2CCD516AEF39DE8C3@Pauls-MacBook-Pro.local> <1984508980.4145408.1507553196491@mail.yahoo.com> <5D3BAA54-3229-4472-8A4D-A10D3F3F07D9@fjl.co.uk> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (wonkity.com [127.0.0.1]); Tue, 17 Oct 2017 14:45:03 -0600 (MDT) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 20:45:29 -0000 On Tue, 17 Oct 2017, Frank Leonhardt (m) wrote: > > Interesting debate this. Personally I have always regarded sh as a Job Control Language. Probably showing my age. I've noticed that job control languages try to fill in for weaknesses in the programming languages available on the same system. Somtimes these are just perceived weaknesses. > As such it's intended for controlling jobs written in 'C' (being Unix). All it had to do is put the data in the right place for input, and arrange for the output to end up where it should. In no way should it be used for implementing an algorithm. > > Now people are trying to write programs in it. Why? I suspect its because people haven't invested the time to learn a programming language, as it's quicker to find some cunning way of perverting the JCL one problem at a time. > > Do spreadsheet macros count as programming? I've seen complete business management systems written in Excel macros. Unmaintainable and flaky, but I'm in awe that anyone did it. > > And if I get too sniffy about the use of structured "proper" languages, I think back to the days of assembler and even machine code. Do the primitive building blocks of assembler count as programming? It's hard to argue otherwise, so therefore the > primitive building blocks of sh have to count too. > > That said, I was really happy when I could start using 'C' in the early 1980's. The perfect blend of convenience and control of the CPU. > > You do need to invest the time to learn a compiled language like 'C'. Friendly interpreted languages are considered cheaper to use because the staff need less training - or assumed to be. I'm not so sure. C is really just glorified macro assembler. Look closely and you'll see the bytes. Like any tool, it is built to do certain things. It can sometimes be used for other things, but does not necessarily do those things well. Writing a program is not that hard. Modifying one, especially one you didn't write, can be a lot harder. As maintenance can be, and most programs require ongoing maintenance. Higher-level constructs make for less code, which generally makes it easier to see on a screen and understand. And when it's easier to understand, it's easier to maintain. There have been some efforts to polish off the roughest C warts. Google and Apple have done this lately, although it looked to me like they kept the ugliest parts and polished around them. The sad thing is that we have a bunch of high-quality open-source languages available for free, and people should be picking the language based on the problem domain. It's difficult to change mindspace to match radically different languages. But it often leads to clearer expressions of the algorithm. That makes it easier to debug and maintain. And it can also give the programmer different ways of looking at problems. That is valuable no matter which language you end up using.