Draft PEP on RSON configuration file format
in [Python]
|
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 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.
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. +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
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 benefit. > http://myarch.com/why-xml-is-bad-for-humans > http://www.ibm.com/developerworks/xml/library/x-sbxml.html You might like this one too: http://www.schnada.de/grapt/eriknaggum-xmlrant.html > > 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 alternatives. > > 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 > benefit. > 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. -- Greg |