BIND segway -> python -> first-class ports

[Teske, Devin]

On Dec 8, 2013, at 9:13 PM, Daniel O'Connor wrote:

> 
> On 9 Dec 2013, at 11:22, Darren Pilgrim <list_freebsd at bluerosetech.com> wrote:
> 
>> 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.
>> 
>> Can you cite a real-world example of a general-purpose OS where this was beneficial?  Beneficial here means otherwise impossible functionality or automation gains without adding barriers for low-level diagnostics, tuning, corner-case configurations and other modes of advanced control.
> 
> It is not that parsing the human readable output of the tools is impossible, it's that it's tedious bullshit code that you shouldn't have to write in the first place.
> 
> I would kill for a way to be able to do something like..
> output=`somecmd -J`
> foo=`jsonextract -f some.field $output`
> bar=`jsonextract -f another.field.here $output`
> 
> Even nicer would be if the shell could do it internally so you didn't have to re-parse it all the time but it's a start :)
> 

+1 for identifying that:

	one_time_var=$( 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 supreme
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.
-- 
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.