Draft PEP on RSON configuration file format

[Steve Howell]

On Mar 3, 7:46 am, mk <mrk... at gmail.com> wrote:
> Paul Rubin wrote:
> > Patrick Maupin <pmau... at gmail.com> writes:
> >> One of my complaints.  If you had read the document you would have
> >> seen others.  I actually have several complaints about YAML, but I
> >> tried to write a cogent summary.
> > Yaml sucks, but seems to have gotten some traction regardless.
> > Therefore the Python principle of "there should be one and only one
> > obvious way to do it" says: don't try to replace the existing thing if
> > your new thing is only slightly better.  
>
> With all due respect, Paul, and with thanks for all the help you've
> given me, I have to disagree here: this is a really, really complicated
> matter and I think there is a case even for making things slightly better.
>
> I think this is a matter of "investment period", so to speak: is it
> short or long? In short term, it absolutely makes no sense to produce
> even slight improvement.
>
> But in the long run it will almost certainly pay off to switch to smth
> even somewhat better implementation (say, imaginary "20%" if you get my
> drift): suppose we stay with sucky format for 10 years. Wouldn't it make
> sense to implement a new one and be "in red" in terms of effort expended
> versus saved for 3 years, but then be "in black" for the following 7 years?
>

I think ten years is about the right horizon to be looking down.
Anything further than ten years is probably so speculative as to have
lots of diminishing returns, although I admire people who have really
BIG ideas and are starting on them now.  (The particular context of
this thread doesn't lead to big ideas, unless I just lack
imagination.)

I think it's wrong, though, only to look five years ahead.  If the
only goal was to make software development easier in 2015, then I'd
say, by all means, let's pick the current best-of-breed tools and
simply perfect them as much as we can.  This is a worthwhile goal
regardless of your ultimate time horizon, and that effort tends to
happen anyway, since so many people rightly live in the here and
now.

Somewhere in the 2020s, though, I predict that a lot of technologies
are either going to finally die off, or at least be restricted to the
niches that they serve well.  Take Java, for example.  I think it will
be still be used, and people will still even be writing new programs
in it, but it will be rightly scorned in a lot of places where it is
now embraced.  Some of this won't actually be due to technological
advances, but just changes in perception.  For example, I predict lots
of programs that people now write in Java will be written in Python,
even if the core language of Python remains fairly stable.

Beyond just changing mindsets, though, I think evolution is
inevitable.  Some subset of Python tools will almost certainly develop
features that are more friendly to the Java mindset, but work in
Python, and this will help move folks from Java to Python.  I also
think that Java will be supplanted for lots of use cases by some
languages invented after 2000.  Maybe Scala will become more
mainstream.  Maybe Go will turn into more of an enterprise-y
platform.  Who knows?

With regard to XML, I think at a bare minimum, folks will stop using
XML for use cases that YAML, JSON, and maybe even RSON serve better
today.  I bet that at least one of YAML and JSON survives in some
form, and my money is on JSON, but I bet there will also be some new
competing formats.  I also think that we'll still have multiple
formats that are only marginally better than each other for general
use cases, but which people will still choose for specific reasons.
Developers *love* good tools almost as much as they hate confusion--
there will always be tension between having too many choices and not
enough.

Going back to Paul's statement, I agree that "there should be one and
only one obvious way to do it" in Python, but I don't think the
philosophy applies to the greater ecosystem of software development.
In our generation I think we have the live with the confusion and
chaos that comes from a plethora of tools, and that's just part of
progress.  Ironically, I think the tools that survive will be very
focused in their own right; it's just that we'll still have many to
choose from.

Going back to XML, I found myself using it last night for a completely
inappropriate use case.  It so happens that it would have been about
100% better if it had simply been written in JSON, so there was no
compelling need for yet another alternative.  But if the inventers of
JSON had been complacent about XML, we wouldn't even have that as an
option.  And, of course, there is nothing radical at all about JSON--I
am pretty sure it was just a common sense realization about the
inadequacies of current technologies that led to its development, and
I'm sure early versions of it were pretty raw.  Without having looked
into RSON, I am sure it's the same mindset that drives its invention--
current tools exist that can get the some done, but we can do better.
Whether RSON is really an improvement or not is an orthogonal issue to
whether we should strive for improvement.