You'd call someone a bad programmer just because they can't write straight HTML? You'd call someone a bad programmer just because they've never dealt with databases?
Interesting.
Interesting.
The obvious domain generalization is a much harder (but hardly impossible) statement to argue:
Yes, there are people out there who couldn't <use basic building block of their field> if they had to, and have never heard of <some atomic concept they implicitly use every day>. We call them bad programmers. Guess what: they're everywhere.
So the question becomes "if you only know how to function within some high level of abstraction are you effective at what you do?" I'd suggest that this holds pretty well if the level of abstraction you're using is too leaky. I don't have the slightest idea how to time an HD seek operation, but I can write to a file with a great deal of robustness. I think the op has a point though that if you operate mostly with RoR you might be ignorant to a non-trivial amount of detail which will relegate your work to being lower quality.
My personal belief is that "web frameworks" aren't a sufficiently compartmentalized level of abstraction. RoR holds the opposite philosophy (evidenced by marketing and the opaqueness of Active Record, for instance) which causes a great deal of impedance when you have to dive into lower level concepts which were supposed to have vanished via RoR. So I agree with the op in that if you can only create things using RoR abstractions, you'll probably be in trouble before too long.
</sarcasm>
I've seen some web development in the past that was absolutely horrid, and I hope that after that project not a single programmer has to EVER touch code like that again.
What's your point?
I should have finished that post, I just kinda left it hanging. Something else came into mind at the time and I mindlessly hit submit.
As far as I am concerned I like algorithmization better, but most jobs out there are mostly UI and database related, so I have to deal with that.
Talking to him about the most primitive constructs in computing: say, variables, or calling conventions, or the simplest data structures has been a teeth-pulling experience. One of the tricks he invented involved saving the registers for interruptible code to fixed locations in memory: he reasoned that saving X registers at Y clock-cycles would meet his soft-realtime requirements. He also kept an index, that stored the last instruction that was executing when the code was interrupted, so he can restore the "handler" later.
He "invented" this ~25 years ago.
Let that sink in.
My friend invented context-saving, all by his own, really, and there is no way in bloody hell to tell him that it EXISTED since before he was born.
I am mightly impressed by his work, all of it self-taught and wildly profitable. But it's just sad that I, a two-bit paper-hacker with nothing to his credit can look at his Magnum Opus and have a name for every invention, not to mention research references, and suggest alternatives.
Embedded hackers are competent, but FUCK, sometimes they need to see past board specs and stupid timings. College Freshmen can out produce them, and those kids are running 100% simulated stuff in Java and Flash. Something has to be said for rigor, depth, and breadth of knowledge, but most importantly abstraction. Who cares if you can operate industrial electronic equipment, if some kid with PLT Scheme can create a cycle-accurate simulator of your equipment in 2-weeks, and out-codes you after that?
But they've never written a web page, never bothered to look behind web pages, and don't know the syntax. I'm sure they'd be great if they chose to learn the syntax, grammar and elements, but they've no need.
They certainly know about mathematical logic, and almost certainly know the concept of an inner-join, but they've never dealt with relational databases, and certainly not SQL.
I'm pretty sure you can't be a good web developer without being about to write at least a little straight HTML, and without knowing the differences in use and performance of the different types of join, but even then I'm not convinced.
Just speaking from my experience. It seems to me that sweeping generalisations such as "Can't write HTML => bad programmer" says more about the speaker than the subject.
The "discussion" got out-of-hand, and it's too late to try to write something balanced and conciliatory.
I will yield to your experience, and certainly do not suggest that it is impossible to be good without a grasp of the two technologies.
My instinct, however, is that not knowing HTML (which I define as understanding the structure and basics, not complete mastery of XHTML 2 tags or something of the kind) shows an alarming lack of curiosity especially given how dominant web-based technologies have been in the last 6-7 years or so.
Understanding databases and SQL (again, no mastery needed), on the other hand, seems like an exceptionally useful thing to have in your toolbox. How do you evaluate data storage options without having some working knowledge of databases?
They are also both relatively cross-cutting for the field of software development, not specialised niches.
Now, the guys and/or gals you know probably are great programmers: but I think a very small time investment in the two subjects would be quite beneficial.
Edited for grammar and added 2nd last paragraph.
Seriously, I think people might be showing a certain myopia in this thread, believing that the subfield that they're working on is all there is, or at least all that matters. If you want someone to write an iterative eigenvalue solver for a large sparse matrix in Fortran, I'm your guy... but my HTML is at the level of circa 1997 "Look at my awesome <blink>web page</blink>".
The only thing it shows is a lack of interest in HTML. A lot of people take a problem-first approach to career development and will only learn a new technology if it helps them solve a particular class of problems. For all you know a programmer not interested in HTML could be dabbling in graphics or compiler writing in his spare time - domains where HTML or web technologies are not really needed.
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.
> ... the definition of a database is an organised
> collection of data. Ephemeral or transient data is
> still data.
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.