12 ms·

Well, not HTML, but I would maintain that any programmer who hasn't dealt with databases is either a newbie or a bad programmer. Any web programmer who can't wr

by donaq 16y ago

Well, not HTML, but I would maintain that any programmer who hasn't dealt with databases is either a newbie or a bad programmer. Any web programmer who can't write straight HTML is most definitely a bad one.

RiderOfGiraffes 16y ago
OK, so I'm either a newbie or a bad programmer. I've been programming since 1978, so I guess I'm a bad programmer. Hmm. I write safety-critical software for embedded processes and distributed systems. Perhaps I should be concerned at your judgement.
- donaq 16y ago
  I think you have misread me. And while my knee-jerk reaction was to meet snark with snark, I shall resist the temptation. If none of your software has ever read from or written to a source of persistent data, I think you should be concerned. :)
  - kranner 16y ago
    Plain old files are perfectly valid sources and sinks for persistent data, if you don't need all the other features of a database.
    - philipkimmey 16y ago
      I interned this summer in a genetics lab, and was shocked the extent to which this is the case. Both the input and output files are absurdly huge, so I'm not sure anything else would've been viable, but still, at least as a student it always seemed like there should be "some other way." 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?"
      - protomyth 16y ago
        A lot of companies still do all the processing on text files as a nightly run (particularly those companies getting once a day data files (e.g. credit card rewards processors)). Some put it in an actual database, but you can really churn through text files faster than a lot of relational databases can do their queries. 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.
  - RiderOfGiraffes 16y ago
    My comment wasn't intended to be snarky, but when someone questions my credentials, albeit inadvertantly and through ignorance, I find it a little hard to be entirely objective. 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.
    - donaq 16y ago
      My comment wasn't intended to be snarky, but when someone questions my credentials, albeit inadvertantly and through ignorance, I find it a little hard to be entirely objective. Huh. Well, you've been programming for longer than I've been alive, so you're almost certainly a better programmer than I am.
      - RiderOfGiraffes 16y ago
        I suspect that largely we've been talking (arguing?) past each other. My point was/is that there are areas of programming that really, really don't need SQL or relational databases, and don't touch web interfaces. I've just been talking with a friend who does financial simulations as well, and he's heard of joins, but never used them. He's also never written HTML, but has got a clue about it. 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.
ig1 16y ago
Plenty of developers work on embedded systems, libraries, GUIs, adapters, etc. that never need to touch a database. Not to mention many developers may work on applications where data is provide by middleware layers or data services rather than databases directly. I think you're letting your experience of development cloud your view over what software development involves.
- donaq 16y ago
  I think you're letting your experience of development cloud your view of what a database is. Almost every program imaginable requires one.
  - protomyth 16y ago
    No, most embedded programmers will never deal with any form of database unless you stretch the definition of database so far as to include lookup tables. I am pretty sure arrays are not databases.
    - donaq 16y ago
      I don't need to stretch the definition for that to be included, since the definition of a database is an organised collection of data. Ephemeral or transient data is still data.
      - kranner 16y ago
        By that definition a JPEG file is a database.
      - RiderOfGiraffes 16y ago
        But, for example, a dictionary in python, while containing data, is not usually referred to as "A Database". It doesn't have inner-join, outer-join, left or right join, select, etc. It's data, it's not what most people would call a database.
        16y ago
gte910h 16y ago
There are loads of applications which have no need for databases. There are loads of application DOMAINS where you never THINK of using databases. Lots of embedded stuff, especially. Drivers. OS work. Any of those, you can easily carve out a career without a single database write.

by donaq 16y ago

RiderOfGiraffes 16y ago

OK, so I'm either a newbie or a bad programmer. I've been programming since 1978, so I guess I'm a bad programmer. Hmm. I write safety-critical software for embedded processes and distributed systems. Perhaps I should be concerned at your judgement.

donaq 16y ago
I think you have misread me. And while my knee-jerk reaction was to meet snark with snark, I shall resist the temptation. If none of your software has ever read from or written to a source of persistent data, I think you should be concerned. :)
- kranner 16y ago
  Plain old files are perfectly valid sources and sinks for persistent data, if you don't need all the other features of a database.
  - philipkimmey 16y ago
    I interned this summer in a genetics lab, and was shocked the extent to which this is the case. Both the input and output files are absurdly huge, so I'm not sure anything else would've been viable, but still, at least as a student it always seemed like there should be "some other way." 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?"
    - protomyth 16y ago
      A lot of companies still do all the processing on text files as a nightly run (particularly those companies getting once a day data files (e.g. credit card rewards processors)). Some put it in an actual database, but you can really churn through text files faster than a lot of relational databases can do their queries. 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.
- RiderOfGiraffes 16y ago
  My comment wasn't intended to be snarky, but when someone questions my credentials, albeit inadvertantly and through ignorance, I find it a little hard to be entirely objective. 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.
  - donaq 16y ago
    My comment wasn't intended to be snarky, but when someone questions my credentials, albeit inadvertantly and through ignorance, I find it a little hard to be entirely objective. Huh. Well, you've been programming for longer than I've been alive, so you're almost certainly a better programmer than I am.
    - RiderOfGiraffes 16y ago
      I suspect that largely we've been talking (arguing?) past each other. My point was/is that there are areas of programming that really, really don't need SQL or relational databases, and don't touch web interfaces. I've just been talking with a friend who does financial simulations as well, and he's heard of joins, but never used them. He's also never written HTML, but has got a clue about it. 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.

ig1 16y ago

Plenty of developers work on embedded systems, libraries, GUIs, adapters, etc. that never need to touch a database. Not to mention many developers may work on applications where data is provide by middleware layers or data services rather than databases directly. I think you're letting your experience of development cloud your view over what software development involves.

donaq 16y ago
I think you're letting your experience of development cloud your view of what a database is. Almost every program imaginable requires one.
- protomyth 16y ago
  No, most embedded programmers will never deal with any form of database unless you stretch the definition of database so far as to include lookup tables. I am pretty sure arrays are not databases.
  - donaq 16y ago
    I don't need to stretch the definition for that to be included, since the definition of a database is an organised collection of data. Ephemeral or transient data is still data.
    - kranner 16y ago
      By that definition a JPEG file is a database.
    - RiderOfGiraffes 16y ago
      But, for example, a dictionary in python, while containing data, is not usually referred to as "A Database". It doesn't have inner-join, outer-join, left or right join, select, etc. It's data, it's not what most people would call a database.
      - 16y ago

gte910h 16y ago

There are loads of applications which have no need for databases. There are loads of application DOMAINS where you never THINK of using databases. Lots of embedded stuff, especially. Drivers. OS work. Any of those, you can easily carve out a career without a single database write.