Date: Mon, 9 Dec 2013 05:39:16 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: Devin Teske <dteske@freebsd.org>, Alfred Perlstein <bright@mu.org>, "freebsd-stable@freebsd.org Stable" <freebsd-stable@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com> Subject: Re: BIND segway -> python -> first-class ports Message-ID: <5C28ECE3-CE0C-44A9-A7CD-08A01C714594@fisglobal.com> In-Reply-To: <8D54491D-5A1C-4D30-AD48-12336D0726DC@gsoft.com.au> References: <mailman.313.1386119137.1390.freebsd-stable@freebsd.org> <529E8C53.6020208@freebsd.org> <Pine.GSO.4.64.1312032238220.15897@sea.ntplx.net> <20131204060246.GV2951@home.opsec.eu> <CAN6yY1udd1GbQVK4YR-yxNe7vqX3S1refQwch2cafRnMv=W4mA@mail.gmail.com> <CAFHbX1K1AgZ4FaEjP_vvnfiwDWsj6M3ysEVn4taX_4_p%2B1Z8Nw@mail.gmail.com> <CAN6yY1tjS=uk1Qr-sBN0PT73xpP%2BBxL8wLt9aosYfWf751rC5A@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 8, 2013, at 9:13 PM, Daniel O'Connor wrote: >=20 > On 9 Dec 2013, at 11:22, Darren Pilgrim <list_freebsd@bluerosetech.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5C28ECE3-CE0C-44A9-A7CD-08A01C714594>