From owner-freebsd-stable@FreeBSD.ORG Mon Dec 9 05:39:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDDF175A; Mon, 9 Dec 2013 05:39:20 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9C90514E9; Mon, 9 Dec 2013 05:39:20 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id rB95dILG008074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 8 Dec 2013 23:39:18 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.7]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.03.0158.001; Sun, 8 Dec 2013 23:39:17 -0600 From: "Teske, Devin" To: "Daniel O'Connor" Subject: Re: BIND segway -> python -> first-class ports Thread-Topic: BIND segway -> python -> first-class ports Thread-Index: AQHO9EPVAMsIQg72sUSzcf93F1B7uw== Date: Mon, 9 Dec 2013 05:39:16 +0000 Message-ID: <5C28ECE3-CE0C-44A9-A7CD-08A01C714594@fisglobal.com> References: <529E8C53.6020208@freebsd.org> <20131204060246.GV2951@home.opsec.eu> <52A12843.3010204@freebsd.org> <0BFC927B-D72E-4926-BB3D-2C000F310BDD@fisglobal.com> <7271C4C4-7BAB-4DA7-9E10-49D5B2DB8964@mu.org> <52A51438.4090200@bluerosetech.com> <8D54491D-5A1C-4D30-AD48-12336D0726DC@gsoft.com.au> In-Reply-To: <8D54491D-5A1C-4D30-AD48-12336D0726DC@gsoft.com.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D09FED28E69D4448F8CF0C939C69742@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.72, 1.0.14, 0.0.0000 definitions=2013-12-08_02:2013-12-06,2013-12-08,1970-01-01 signatures=0 Cc: Devin Teske , Alfred Perlstein , "freebsd-stable@freebsd.org Stable" , "Teske, Devin" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Devin Teske List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 05:39:20 -0000 On Dec 8, 2013, at 9:13 PM, Daniel O'Connor wrote: >=20 > On 9 Dec 2013, at 11:22, Darren Pilgrim w= rote: >=20 >> On 12/8/2013 11:02 AM, Alfred Perlstein wrote: >>> So if I were going to task the talented Devin Teske with something, >>> remember you just asked my opinion, then it would be to look at >>> putting Lua in the boot loader, getting python into base, or working >>> on making our utilities be able to output standard machine readable >>> formats such as yaml, XML and json. >>=20 >> Can you cite a real-world example of a general-purpose OS where this was= beneficial? Beneficial here means otherwise impossible functionality or a= utomation gains without adding barriers for low-level diagnostics, tuning, = corner-case configurations and other modes of advanced control. >=20 > It is not that parsing the human readable output of the tools is impossib= le, it's that it's tedious bullshit code that you shouldn't have to write i= n the first place. >=20 > I would kill for a way to be able to do something like.. > output=3D`somecmd -J` > foo=3D`jsonextract -f some.field $output` > bar=3D`jsonextract -f another.field.here $output` >=20 > Even nicer would be if the shell could do it internally so you didn't hav= e to re-parse it all the time but it's a start :) >=20 +1 for identifying that: one_time_var=3D$( one_time_fork ) is bad for performance and is undesirable. Further +1 for identifying that the proper design is to focus efforts on "data acquisition and import" tp be done as atomically as possible. That is why I designed "struct.subr". You see, I sat down one day (ok, more like a few years), and tried to decide what was better... A. Embrace the quintessential highest-level language that had the most safety-belts and provided for RAD (aka "Rapid Application Development"). *or* (a second choice that was only borne of wisdom through experience) B. Teach our old languages some new efficiency modeling that would add a safety harness while at the same time... break the limitations (perceived or otherwise) of shell as being a "weak" language. > (I don't care if it's JSON, XML or smoke signals just so long as it isn't= hideously slow). I'd like to think I'm still young. I'm only 31 now. I've picked up as many computer languages in that time, and I whole heartedly agree... The language isn't important. What's most important is the... Reach of the language. There are few languages that can compete with the portability of /bin/sh + = awk. But as you say... making sh code that runs as fast as a native C program is= ... Challenging. A challenge that took me perhaps 15 years to best... but the end-result is = that nearly any system running UNIX can utilize your code. But keep in mind... The real power is not in shell, the real power is in POSIX. I have the supr= eme pleasure of having developed C programs that can compile on: + Windows using MinGW + Mac OS X using ... gcc + Mac OS Classic using SIOUX NB: Simple Input/Output User eXchange + Linux, Unix, BSD, AIX, OSF1, Amiga, etc. All with a single source package. It's the power of POSIX. So whenever I've made a choice to target "/bin/sh" as a platform, it's always *only* ever been based on the decision of "reach". Shell quite often doesn't cut it. Prior to shell, I spent my time trying building libraries used to abstract higher functionality for cross-platform compatibility. And, until now, that's primarily been in C -- shell is only a recent excursion because I feel I've *finally* nailed the right recipes for that. I'm actually a bit worried that Python and Lua don't have the reach that C = does, let alone shell. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.