wsprague
1. I think buttons with relief are easier to use, but other than that I am always surprised at how worked up people get about theming (but then I prefer a terminal based emacs...).
2. Tcl/Tk has some GREAT ideas that are not implemented anywhere else: the built-in event handler, trivial to write callbacks, and the everything is a string philosophy (which is strangely like a self-evaling lisp approach)
3. Tcl/Tk had some really bad luck. This weekend at opensqlcamp, someone asked Selena Deckleman why PostgreSQL has not had a tenth the market share as MySQL. She said (paraphrasing): in 1999 a lot of the core devs thought the internet was just a fad -- whoops... Same mistakes maybe happened with Tcl/Tk -- it was there just a little too early.
4. Tcl/Tk demands C to be a really full platform, and C is scary to a lot of the new breed of scripters.
Au Contraire -- Murray and Strout understand fully, but as employees of the public school system, Murray and Strout are paid to teach their students to follow pointless rules with docility and even joy (or at least the feeling that they are doing the right thing).
(Edit -- I consider it a compliment that I get upvoted and downvoted so often. Teenage rebel gives me a point... humorless school principal takes it away...)
data.gov is fundamentally flawed, and won't be anything but annoying until it is reworked into something along the lines of what I suggest. Or so I think...
If you want metadata, a well written narrative paragraph along with a code book is INFINITELY better than embedding the metadata in the data.
Furthermore, a lot of supposed metadata in XML is just dross like "<column>blah</column>".
Finally, all the crap in XML way ups the signal/ noise ratio; if you do need something that maps to a complex data structure use JSON or something rational. Such needs are not very common in data analysis, in contrast to web applications; data analysts use multiple tables and are usually pretty close to relational databases and SQL (even if they don't call it that).
1. Fiction: Data doesn't require lots of work to make it useable, so we can just upload whatever we have and it will be useful to somebody. Fact: the big useable datasets (census, ipums, nlsy, all the private marketing datasets) have armies of people cleaning and integrating them. It costs money, it takes time, and it is easy to screw up.
2. Fiction: Links are worth something. Fact: links are worthless.
3. Fiction: XML adds values. Fact: aascii tab delimited in consistent formats add value, while XML SUBTRACTS value.
4. Fiction: a good dataset is easy to use. Fact: even a good dataset (google IPUMS for an example) takes a lot of work to get to know how to manipulate, presuming one can use some sort of statistical programming language in the first place.
5. Fiction: simple summaries of common data data are useful. Fact: everybody has already done the simple summaries. (This is just a bonus item, and doesn't apply to data.gov, but does apply to faulty thinking about data in general.)
6. Fiction: Federated data is just fine. Fact: Data that is curated, cleaned, and integrated into one big monolithic package is FAR better, because an analyst can then learn the conventions and names and such in one piece, and parallel categories are more likely to align.
7. Fiction: Good data is easy for a layperson to use. Fact: good data still requires a lot of skill. Well, maybe in nations with decent public schools a layperson can do something with data, but not in the US.
What I WOULD like is the following (taken from another post, now deleted):
An ideal data.gov would have a lot of staff who put together a few integrated and curated datasets from the agencies. These would be hierarchies of data in a few formats (shp, txt, raster, SQL text dump, and ...?), along with well written codebooks and narrative READMEs. They would be distributed using git or subversion. The staff would have the expertise to make such nice data packages for you and me, and they would have the political oomph to demand that the agencies release the data to them. The staff would also give classes on how to use the data along in some open source statistical packages to do useful work. Good examples of curated data that I know are IPUMS and the Portland Metro's RLIS (both google-able).
1. It mixes format with logic. Don't we all know this is one of the greatest evils one can commit?
2. Indentation is a bitch to parse compared with braces. Violates occam's razor of software of engineering -- simpler is better. Unnecessary complexity is the second greatest evil in software engineering.
3. Indentation is neither symmetrical nor logically unique. Therefore you can't delete all the formatting from a python program and expect a formatter to get it right. With symmetric braces a formatter always knows exactly what logical level it should be on by counting the number of closed braces; not possible with python's goofy system.
4. All that tiresome debate and worry over tabs versus spaces.
5. One can't really say "braces are redundant not indents" or "indents are redundant not braces". Redudency is commutative. I would say braces are for computers, indents are from human; it is simple to go from braces to indents but not so in the other direction.
Just a note -- I will always pick Python over any other scripting language. I just think the indentation is a serious mistake; there are so few other bad choices it tends to irk me that much more.
Plus, I would hesitate to naturalize the idea of intellectual property as if it were a "thing" just like a cheese sandwich. Some of your argument seems to rest on protecting IP which (somehow) exists; a lot of people would doubt that IP is a valid concept or exists at all.
His book "Tristes Tropiques" was also so well written that it would have been awarded the Prix Goncourt except that it was non-fiction.
Probably one of the ten most important thinkers of the 20th century, though not nearly so important today.
http://www.guardian.co.uk/science/2009/nov/03/claude-levi-st...
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns# xmlns:dcterms="http://purl.org/dc/terms/>; <rdf:Description rdf:about="urn:x-states:New%20York"> <dcterms:alternative>NY</dcterms:alternative> </rdf:Description> </rdf:RDF>
hehe. That's funny...
This emptiness stems from the fact that you consciously wonder who you are ("consciously" meaning with words in your head), and, in the long term, no final answer seems to be forthcoming, even though you may tell yourself otherwise, or go to church to hear someone else tell you, etc. The emptiness is part of the human condition and can't actually be fixed or filled. We all feel it very deeply, and there is a huge industry around making us feel sure of ourselves, and/ or keeping us so busy in the world that we don't have time to contemplate the ever-present internal void.
The only "authentic" (Heidegger's term) way forward is to just embrace the "uncanniness", and quit wasting time worrying about how you can't "just enjoy life" or "live always in the moment". I think of this as the way of life that is "un-selfconsciously selfconscious" (tm). Look for my new book in the Self Help section soon!
Or, one could also say that Nietszche, Heidegger, and Kierkegaard just had A LOT of bad days and wrote some books about it...
... but perhaps Karl Marx was correct when he said that (basically) the essence of capitalism is in the systematic skimming of "surplus production" by the controllers of capital. In other words, EVERY employee is not paid according to their production.
I also think that this commenter has really swallowed the ideology (ie, is clueless): not every boss wants production from their underlings. Perhaps the owners want production, but managers don't necessarily -- changes in production might make them look bad, it might reset the expected quota level for their department, it might upset next years budget, etc. The interests of employees <> interests of owners, and managers are employees.
The Linux / BSD driven revival of Unix happened, un-fortuitously, just when object-orientation, graphics, UML, patterns, etc, were hitting their peak, largely because they were super successful in dealing with problems in graphic interface design. So these oo approaches became dominant in curriculums and paradigms far beyond their applicability, and no one bothered to study the classics of the previous generation like APUE etc.
Smalltalk and C++ begat Java, begat Ruby/ Python, and now we have a whole bunch of server-side programmers who know how to inherit from multiple base classes but don't know what fork() really does; when these young people (ahem) discover how well their grandfather's Unix addresses many of their current server-side problems, well, they are thrilled.
Let's just say it's the same thing as a twenty something discovering Sly and the Family Stone vinyl in the basement... Yeah, it rocks.
Because idiot MBA managers have heard of MySQL but not Postgres. (Sorry -- I couldn't resist.)
The longer answer:
When the internet took off, MySQL was a lot better than Postgres in terms of stability and speed, though not in terms of features. It grabbed marketshare and "mindshare" then, and it has retained them, even though now Postgres is its superior in terms of features, concurrency, and stability. Because of the marketshare snowball effect, it also remains far easier to hire a MySQL tech and to explain MySQL to a non-technical manager.
MySQL also continues to lead in the realm of simple andd effective replication, which Postgres does not have yet, though they are working on it (furiously).
:)
There is nothing more I can say -- I am so in awe...