I've been noticing the time machine effect the article mentions using Clojure. A couple weeks ago, I needed a GUI to update whenever an agent's value changed, and it turned out that watchers had been added to the language only a few days before.
I think the effect is what PG was talking about when he discussed the difference between languages designed for the designer to use and languages designed for other people.
XML is not the answer. It is not even the question.
I have a question for the Python hackers in the audience: what file format(s) do you use for configuration files? I've been using INI style files up until now, but I've been thinking of switching to XML for more complicated formats. For example, what about something like the following example. What format would you use to store this type of configuration data for a Python application?
There's another problem. YAML is so simple, you don't need to read the damn manual for it. That example already taught you 80%. Ok, the easy 80%. But if you come from the Java (and XML) world, reading the manual is what you do just to get started.
Reading the manual once (at least the part with the examples) is indeed a good idea to get an overview of the possible constructs but once you have them down it quickly becomes a no-brainer. Under the hood YAML is surprisingly complex (can do full blown object serialization if you want to) but the everyday stuff is just perfect for typing it into an editor without thinking about it - and without matching up braces all the time like in JSON.
Disclosure: I write very little code targeted at non-technical endusers, in fact most my code is for my own use. These facts strongly influence my config file solution.
If find the need for a config file (I tend to like command line options better) 95% of the time I use python code and import.
The benefits are many; zero work required, known syntax, powerful syntax, arbitrarily complex, no parsing required, nice traceback/errors with screwed up syntax.
#file config.py
debug = True
directories_to_backup = [
# path exclude these subdirs
("/media/programming", ("log_files","temp_files")),
("/media/documents", ("archive",)),
]
# or, if you relish verbosity
directory_info = dict
directories_to_backup = [
directory_info(path="/media/programming", exclude=("log_files","temp_files")),
directory_info(path="/media/documents", exclude=("archive",)),
]
# the options are as endless as your knowledge of Python
Usage
import config
for path, excludes in config.directories_to_backup:
garbleblaster(path, excludes)
Ideally we should use the right tool for the job, but sometimes time constraints pressure us to try to use the tool we know best for any job, and the next thing you know we're using a wrench to twist a nail into the wall. We might get it in there, but it's ugly, crooked, and likely to fall apart with little weight, and all because we didn't have, or didn't want to take, the time to learn to use a hammer.
To be fair, one equally shouldn't try to program in Java with python on the brain, it's going to turn out just as hideous and slow, and the developer will probably be more furious at the number of recompilations caused because approach the problem with the right mindset.
For those that like to join the downmod mob, I read the article and to expand a bit on my one line statement, anybody that will try to shoehorn language constructs from one language into another without first properly learning that language is going to be making these exact mistakes.
It's patently obvious.
Languages are different for a reason, and if you wish to do meaningful work in a language you would do well to familiarize yourself with the core constructs of a language before embarking on a major project, especially if you have a lot of expertise in some other language, because you may have to unlearn a few things.
I think the effect is what PG was talking about when he discussed the difference between languages designed for the designer to use and languages designed for other people.