Draft PEP on RSON configuration file format

[mk]

Steve Howell wrote:
> 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.

A friend of mine, and a good Java programmer, says caustically: "Java is 
COBOL of the future".

Where I work we develop a huge application in Websphere (IBM Java-based 
application server). The problems with legacy code made project manager 
joke "perhaps we should rewrite this in Python". Perhaps some day it 
will not be a joke anymore?

Personally, I chose to stay away from Java, even though it would 
temporarily help me: the amount of time & effort it takes to master the 
necessary toolset is *huge*, and my scarce time is better spent 
elsewhere, on more productive tools, and I really, really do not want 
lots of my limited time to go down the drain in a few years.

Take EJB for example: even its creators realized they've overdone it 
with EJB 2 and simplified somewhat EJB 3 and switched to annotations 
instead of gazillion XML formats. But still I dread the thought of 
having to spend so much time learning it before I can do a few lines of 
productive work in it.

In a way it's horrible: all this gargantuan effort in a few years will 
be completely wasted, down the drain. All those developer hours and 
dollars wasted.. In a way, C wasn't as bad as Java has been: at least 
many of C libs, with new bindings, still live on and do work.

> 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.

+1

Note that when it comes to bigger tools or frameworks, even in the world 
of Python things are not "one obvious way", e.g. Django for quick and 
dirty and small apps, and Pylons for big and powerful apps. There may be 
"one obvious way to do it" in a very, very narrow context, but when 
contexts widen, like, say: "what is web framework I should choose?" the 
answers diverge, because answer has to be variation of "it depends on 
your situation".

> Whether RSON is really an improvement or not is an orthogonal issue to
> whether we should strive for improvement.

+1

Regards,
mk