Prev: [ANNC] pynguin-0.1 (python-based turtle graphics application)
Next: Detecting new removable drives in Linux
From: Steve Howell on 3 Mar 2010 11:37
On Mar 3, 7:46 am, mk <mrk...(a)gmail.com> wrote:
> Paul Rubin wrote:
> > Patrick Maupin <pmau...(a)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
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
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
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
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.
From: mk on 3 Mar 2010 14:21
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.
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
> Whether RSON is really an improvement or not is an orthogonal issue to
> whether we should strive for improvement.
From: Paul Rubin on 4 Mar 2010 03:52
mk <mrkafk(a)gmail.com> writes:
> OK, but how? How would you make up e.g. for JSON's lack of comments?
Modify the JSON standard so that "JSON 2.0" allows comments.
> OTOH, if YAML produces net benefit for as few as, say, 200 people in
> real world, the effort to make it has been well worth it.
Not if 200,000 other people have to deal with it but don't receive the
You might like this one too:
> I also have to maintain a few applications that internally use XML as
> data format: while they are tolerable, they still leave smth to be
> desired, as those applications are really slow for larger datasets,
I thought we were talking about configuration files, not "larger datasets".
> There are demonstrable benefits to this too: I for one am happy that
> ReST is available for me and I don't have to learn a behemoth such as
> DocBook to write documentation.
DocBook is so far off my radar I'd have never thought of it. I just now
learned that it's not Windows-only. There is already POD, Pydoc,
Texinfo, a billion or so flavors of wiki markup, vanilla LaTeX, and most
straightforwardly of all, plain old ascii. ReST was another solution in
search of a problem.
From: Steve Howell on 5 Mar 2010 00:12
On Mar 4, 12:52 am, Paul Rubin <no.em...(a)nospam.invalid> wrote:
> mk <mrk...(a)gmail.com> writes:
> > OK, but how? How would you make up e.g. for JSON's lack of comments?
> Modify the JSON standard so that "JSON 2.0" allows comments.
If you don't control the JSON standard, providing a compelling
alternative to JSON might be the best way to force JSON to accomodate
a wider audience. It might just be that the people behind JSON
deliberately avoid comments, because it's not in the scope of the
problem they are trying to solve. Hence another need for
> > OTOH, if YAML produces net benefit for as few as, say, 200 people in
> > real world, the effort to make it has been well worth it.
> Not if 200,000 other people have to deal with it but don't receive the
How many hundreds of thousands of people have had to deal with XML
without receiving its benefits? Do well-established standards get an
exemption from the rule that software is not allowed to annoy non-
willing users of it?
From: Gregory Ewing on 5 Mar 2010 00:36
Paul Rubin wrote:
> ReST was another solution in search of a problem.
I think the basic idea behind ReST is quite good, i.e.
understanding as markup various typographical conventions
that make sense in plain text, such as underlined
headings, bullets, numbered paragraphs.
Unfortunately it went overboard with a slew of cryptic
codes for footnotes, hyperlinks, etc. that nobody would
naturally think to use in a plain text document.