On Mar 3, 7:46 am, mk <mrk...@gmail.com> wrote: > Paul Rubin wrote: > > Patrick Maupin <pmau...@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. -- http://mail.python.org/mailman/listinfo/python-list
