Hmm. I write safety-critical software for embedded processes and distributed systems. Perhaps I should be concerned at your judgement.
After a week or two of getting to know the system, for clarification I asked: "You mean this entire sophisticated system is just some Perl, with a database that keeps track of the flat files?"
The most interesting example I saw of this was a company that had an automated process to add a header with time/date/source and check it into code control (subversion I think). The nightly batch job checked what it needed out and did all the processing including generating some control spreadsheets.
I do read and write persistent data stores, I've just never had to use SQL or a relational database. I've just gone and looked it up. I do know the concepts of inner, outer, left and right joins, and I use similar constructions every day.
But this is counter-productive. I've made my point that there are areas of programming that don't use SQL or relational-databases or web technologies. Making sweeping statements about the competence of programmers based on their knowledge of technologies they don't use is blinkered.
Yes, programmers who work in web development most likely should know about databases and HTML. If they don't, then they are most likely either inexperienced or limited in their capabilities. It may yet be that the code they write is clear, clean, well-designed and bug-free, but databases and HTML are strongly correlated with productivity in this field.
Huh. Well, you've been programming for longer than I've been alive, so you're almost certainly a better programmer than I am.
There are also many programmers out there who claim 30 years of experiences, but who actually have 1 year of experience 30 times over.
At its heart I think we'd all agree that narrow definitions and narrow judgements don't do anyone much good. There are more programmers than just web programmers, or embedded programmers, or kernel programmers, or simulation programmers, etc.
We should all do each other the courtesy of recognising each others' skills and knowledge.
I think you're letting your experience of development cloud your view over what software development involves.
http://news.ycombinator.com/item?id=1829481
in which it was said:
> Yes, there are people out there who ... have never
> heard of an inner join. We call them bad programmers.
You said: > ... the definition of a database is an organised
> collection of data. Ephemeral or transient data is
> still data.
That's not the point. Your sense of "a database" being "an organised collection of data" is actually more commonly (in my experience) referred to as "a data structure." Usually it's not "a database" until it gets some sort of query language or manipulation primitives.Yes, people refer to a collection of data as "a database," but I return to my original objection to the original comment requiring that not being a bad programmer requires that you know about inner-joins.
As I said earlier, we have, to some extent, been talking past each other.
I don't think that something has to have inner-join, select, etc. to be a database, it's just that the most common do. Similarly I don't think something has to have 4 wheels, an internal combustion engine and a sunroof to be car - it's just that most of them do.
I once worked for a company that had a version control system where they checked in all the data by project. You could go in an see the history of a project by reviewing the documents (emails, spreadsheets, CSV files, etc) or binary data files that were associated with the project. At the time for checking something in, you were asked to classify the data being checked in. You had options like "Document", "Text file", "Spreadsheet", and one of the options was "Database". Much to the dismay of the programmers who had to deal with the data, users insisted on checking in spreadsheets and CSV files and classifying them as "Database". No form of rational discussion would persuade the users to classify the documents correctly (like I said, there were classifications that covered Spreadsheet/CSV directly). In their mind, a spreadsheet was a database, and it was just stupid that the programmers insisted that it was not. In the end, the programmers just gave up trying to persuade them, and we just grumbled to ourselves every time we came across it.