Definition of Programming
-
So I was just reading a post up in "coding help" related to how to deal with a project using a database that suddenly (big surprise!) had a requirements change and needed more data.
Got me waxing philosophic about the distinction, if there even is one, between "programming" and "data abstraction/storage/representation." For instance, is the design of a database programming, or is it a tool used by programming? Is something like static HTML, or even CSS or XML "programming" or is that just data management?
Is "programming" only the small bit of computer interaction that says "what to do with data"? Put perhaps another way, for something that involves computers to be "programming," does it have to be an activity which specifies operations on data?
This is probably not a materially important distinction at the end of the day, but sadly my brain will be churning the concepts for a while now.
-
Programming dictates behaviour. If you have syntax to do something based on input, then it's programming. Otherwise it's data definition.
HTML is a data syntax to define a hierarchical structure.
CSS is descriptive syntax designed to assign key/value pairs to objects (in this case, HTML elements) through the use of selectors. Selectors are not commands, but again descriptive of the kind of object you want.
No programming language can exist without some syntax to define data structures, of course. If a language had no way of describing data, it would be dead box of gears. Even string and number literals are data.
Data languages do not possess commands, save for the one that's implicit when you feed it to a program: "Do it like this."
Additionally, you could write down both HTML and CSS in the form of Javascript object literal notation, with the catch that JS is more generic than HTML/CSS, so you'd require agreement on what structure to use, as they both already intrinsically define some key-value pairs:
HTML: parent/child and attribute/value
CSS: selector/propertylist and property/value.SQL falls somewhat in the middle. Basic data-grabbing, joining and ordering isn't programming, it's defining the contents and structure of the data you want retrieved. It's just phrased as a command, with verbs. Throw variables, IF statements and loops in the mix, and you gain syntax to perform actions based on input, and then it's programming again.
I personally prefer to write code that's as much as-is as possible; with a control point that falls through the code according to the path I've laid out for its shape. I have something of a dislike for if statements. I also strictly separate the phases of getting data, performing operations and writingoutput as much as possible. This is something some of my cowokers don't seem to grasp. If I can't draw a fat line between the active bit of a program and the part where it generates output, I've done it wrong.
-
For a long time, probably around 20 years or so, people have occasionaly floated the idea that programmers should be licensed, in much the same way that we require it of other proffessions (nurses, pilots, dentists, etc). It's not a completely terrible idea, but the whole thing always falls apart because of one thing -- how do you define "programmer" and "programming". On the surface it seems fairly simple and obvious, but when you actually try to come up with a definition that would be suitable for a law, it turns out to be quite difficult and controversial.
-
@El_Heffe said:
For a long time, probably around 20 years or so, people have occasionaly floated the idea that programmers should be licensed, in much the same way that we require it of other proffessions (nurses, pilots, dentists, etc). It's not a completely terrible idea, but the whole thing always falls apart because of one thing -- how do you define "programmer" and "programming". On the surface it seems fairly simple and obvious, but when you actually try to come up with a definition that would be suitable for a law, it turns out to be quite difficult and controversial.
Programmers fall under the same umbrella of professions as any other type of engineer. For vital/critical applications, such as those dealing with medical equipment, banking software, aircraft software, and the like, you have industry standards to follow and it's up to the company as a whole to meet that criteria. In turn, these employers look for the right engineers to help them meet that criteria in an efficient manner, and that's usually accomplished by a simple resume reading and a well-done interview. Most large companies that require strict safety or security standards will use apprenticeships and very thorough review processes and quality assurance testing to make sure their product is safe and robust.
I'd have to say, for the most part, that setup has worked relatively well. Most failures in software that result in loss of life are no less or more frequent than failures due to flaws in other aspects of engineering.
-
@RHuckster said:
I'd have to say, for the most part, that setup has worked relatively well. Most failures in software that result in loss of life are no less or more frequent than failures due to flaws in other aspects of engineering.
Look up Therac 25. It was a medical device that went from mechanical controls to software controls. This case shows that until very recently, none of the controls that are put in place for product safety applied to the software portion of the product. People died as a result and no one was ever held accountable. I have a mechanical engineering degree and I am shocked at the difference in the way a programmer approaches his job vs. an engineer. Licensed Professional Engineers know that their professional livelihood rests on their projects not hurting the public. Many Professional Engineers have had their licenses suspended or revoked for screwing up, even if the screw up was not directly their fault. I have never heard of a programmer being held to a higher standard than anyone else who interacts with the public.@RHuckster said:
...it's up to the company as a whole to meet that criteria...
Contrast this with an actual engineer. If the company doesn't meet the criteria, the engineer is held personally responsible for it. This is one of the reasons that, in Texas and Canada, programmers are legally not allowed to call themselves engineers.
-
@Jaime said:
@RHuckster said:
I'd have to say, for the most part, that setup has worked relatively well. Most failures in software that result in loss of life are no less or more frequent than failures due to flaws in other aspects of engineering.
Look up Therac 25. It was a medical device that went from mechanical controls to software controls.Uh, and the Therac incident overdosed 6 (known) people. Engineering failures kill more people than that every week. If anything, RHuckster was really, really exaggerating. I would wager that the total number of people killed due to software failure is still less than the number killed from a single large engineering failure like, say, the Titanic disaster. (Not counting deliberate acts of sabotage, like that Russian gas pipeline.)
@Jaime said:
This case shows that until very recently, none of the controls that are put in place for product safety applied to the software portion of the product. People died as a result and no one was ever held accountable.
Why would they be held accountable? Every party involved was acting in good faith. It's not like the Therac programmers were sitting there in a basement with a fluffy white cat on their laptop, wringing their hands and trying to come up with a way to murder people without being caught.
I hate to break this to you, but sometimes? Sometimes shit happens and it's nobody's fault. The flaw was fixed, and won't re-occur in future x-ray machines; that's the best we can do.
@Jaime said:
I have a mechanical engineering degree and I am shocked at the difference in the way a programmer approaches his job vs. an engineer.
And yet, the end result is that software engineering is doing pretty goddamned good, safety-wise. So maybe your concerns are overblown.
@Jaime said:
Many Professional Engineers have had their licenses suspended or revoked for screwing up, even if the screw up was not directly their fault.
How "indirect" are we talking about? If you're placing fault for genuine accidents, that doesn't make anybody safer-- but does make it a lot less likely people will report problems they come across.
Compare how the NTSB operates with how France's BEA operates... the Concorde crashes, and there are *manslaughter* investigations? Why the hell would any maintainence engineer with Air France (or even in France in general) report a possible problem if they know they would face a jury for manslaughter?
@Jaime said:
I have never heard of a programmer being held to a higher standard than anyone else who interacts with the public.
What strange parallel universe do you live in where most programmers interact with the public?
@Jaime said:
@RHuckster said:
...it's up to the company as a whole to meet that criteria...
Contrast this with an actual engineer. If the company doesn't meet the criteria, the engineer is held personally responsible for it. This is one of the reasons that, in Texas and Canada, programmers are legally not allowed to call themselves engineers.Yes, yes, look you paid a lot of money and got a certification and now you get to put this neat framed piece of paper on the wall. That doesn't mean everybody who follows a different path is incompetent, or doing anything unsafe, or (even) that the Engineering profession is doing the right thing.
-
@blakeyrat said:
@Jaime said:
The case study we learned about in Engineering Ethics class (yes, we had that), was a small company that produced structural steel for the building industry. The engineer drew plans for roof trusses for a new mall. When the welder assembled the trusses, he welded some of the rectangular braces oriented horizontally instead of vertically, as the plans called for. That winter, the mall roof collapsed, killing several people. The engineer lost his license for not inspecting the work before it shipped.Many Professional Engineers have had their licenses suspended or revoked for screwing up, even if the screw up was not directly their fault.
How "indirect" are we talking about?
-
@blakeyrat said:
@Jaime said:
My engineering degree cost less than my Microsoft certifications, but the training was a hell of a lot more thorough. At least the Engineering profession has a code of ethics and the possibility to be tossed out if they are violated. Engineers are essentially the protectors of public safety in the construction industry. There is no "right thing", rather Professional Engineers are held professionally responsible for every decision they make, independent of their employee-employer relationship.@RHuckster said:
Yes, yes, look you paid a lot of money and got a certification and now you get to put this neat framed piece of paper on the wall. That doesn't mean everybody who follows a different path is incompetent, or doing anything unsafe, or (even) that the Engineering profession is doing the right thing....it's up to the company as a whole to meet that criteria...
Contrast this with an actual engineer. If the company doesn't meet the criteria, the engineer is held personally responsible for it. This is one of the reasons that, in Texas and Canada, programmers are legally not allowed to call themselves engineers.@blakeyrat said:
That doesn't mean everybody who follows a different path is incompetent, or doing anything unsafe
I never said they were. Stating that one group has strong ethics and public accountability does not imply that others groups do not. However, the Therac 25 programmers certainly were both incompetent and unsafe, even if they only succeeded in killing a few people. At least one of the mistakes they made was deserving of the front page of this site.
-
@Jaime said:
Look up Therac 25. It was a medical device that went from mechanical controls to software controls. This case shows that until very recently, none of the controls that are put in place for product safety applied to the software portion of the product. People died as a result and no one was ever held accountable. I have a mechanical engineering degree and I am shocked at the difference in the way a programmer approaches his job vs. an engineer. Licensed Professional Engineers know that their professional livelihood rests on their projects not hurting the public. Many Professional Engineers have had their licenses suspended or revoked for screwing up, even if the screw up was not directly their fault. I have never heard of a programmer being held to a higher standard than anyone else who interacts with the public.
Generalize much? You seem to regard programmers as heartless, careless, antisocial, and inept... and don't even care. My experience has been quite a bit more optimistic than whoever you've known as programmers. The ones I've known generally take pride in their work, are embarrassed when something goes wrong on production code, and while I haven't really been involved with code that people's lives depended on, you better know damn well that I, and the folks I've worked with over the years, would do everything in their power to ensure their code will be robust and not fail: personal liability or not.
It's important to note that the software that controls medical devices, airplane FMC's, and other vital equipment is a small part of the whole software industry. I'd actually be all for having some kind of system in place that ensures the programmers involved in the software and all aspects of these devices are competent and qualified to do so, whether it's certification or licensing, if studies proved them to be necessary. Requiring an all-encompassing license for any software development, however, would be overkill and would be completely unneccessary.
-
@Jaime said:
However, the Therac 25 programmers certainly were both incompetent and unsafe, even if they only succeeded in killing a few people.
Dude. I said this before, but I guess you didn't get the point:
Sometimes. Shit. Just. Happens.
Unless you have *any* evidence that the programmers of that machine weren't doing their jobs to the best of their ability, then please stop talking as if they're fuciking mini-Hitlers walking around free, ok? Shit happens. Sometimes it's nobody's fault.
-
@RHuckster said:
I'd actually be all for having some kind of system in place that ensures the programmers involved in the software and all aspects of these devices are competent and qualified to do so, whether it's certification or licensing, if studies proved them to be necessary.
Actually, that's already been done. The case is 20 years old; root causes have a lot to do with bad design and insufficient/incorrect testing. We've come quite a long way as an industry since then. That's not to say it couldn't happen today, and anyone working on mission critical systems or financial systems knows that, just like anyone working on engineering projects knows what could go wrong. Which is why we now routinely work with codereviews, QA, external audits, standards committees and certifications, ISO, etc.
However, I don't think revoking a license (after the fact) is going to stop anyone writing bad code or designing a bad roof. If you don't have the mindset that you're working with people's lives, nothing will help you.
-
@blakeyrat said:
@Jaime said:
The Therac 25 incident was primarily caused by a bug where a flag was set by incrementing it instead of setting it to one. It was a byte in size, so once every 256 times it was set, it would actually be un-set. This wasn't shit happening, this was code that was never properly reviewed. There are mountains of case studies in the Therac 25 incident and all of them conclude that a simple code review would have prevented it.However, the Therac 25 programmers certainly were both incompetent and unsafe, even if they only succeeded in killing a few people.
Dude. I said this before, but I guess you didn't get the point:Sometimes. Shit. Just. Happens.
Unless you have *any* evidence that the programmers of that machine weren't doing their jobs to the best of their ability, then please stop talking as if they're fuciking mini-Hitlers walking around free, ok? Shit happens. Sometimes it's nobody's fault.
-
@RHuckster said:
I am a programmer, these observations come from the inside. I would really like to know how my description of one incident and my lauding of the Engineering profession got translated to the villification of all programmers. I certainly believe that the quality of work produced by my profession is lower than many older professions and I think we need to work hard to improve it, but I never came remotely close to calling programmers "heartless, careless, antisocial, and inept", those are your words.@Jaime said:
Look up Therac 25. It was a medical device that went from mechanical controls to software controls. This case shows that until very recently, none of the controls that are put in place for product safety applied to the software portion of the product. People died as a result and no one was ever held accountable. I have a mechanical engineering degree and I am shocked at the difference in the way a programmer approaches his job vs. an engineer. Licensed Professional Engineers know that their professional livelihood rests on their projects not hurting the public. Many Professional Engineers have had their licenses suspended or revoked for screwing up, even if the screw up was not directly their fault. I have never heard of a programmer being held to a higher standard than anyone else who interacts with the public.
Generalize much? You seem to regard programmers as heartless, careless, antisocial, and inept... and don't even care.
-
@Jaime said:
The Therac 25 incident was primarily caused by a bug where a flag was set by incrementing it instead of setting it to one. It was a byte in size, so once every 256 times it was set, it would actually be un-set. This wasn't shit happening, this was code that was never properly reviewed. There are mountains of case studies in the Therac 25 incident and all of them conclude that a simple code review would have prevented it.
And yet, the guy who put in the bug still isn't Hitler. Despite how much you want him to be a volcano-dwelling super-villain, he's just not, ok? Just stop it already.
Would a code review have prevented it? Maybe, maybe not. (Anybody who says it certainly would is a liar.)
Here's what we, as an industry, do when something like this happens:
1) We identify the cause of the problem
2) We identify processes that reduce the risk of the problem re-occurring
3) We begin using those processesNote that this is the same strategy that the NTSB uses, and jet travel is simultaneously the fastest, and safest, form of travel in history, so we know the strategy works.
Note what's not a part of this strategy: blame. Blaming people doesn't help. Most of the time, firing people doesn't help (other than maybe making you feel better.)
We don't do what you engineers do. I'm sorry. But please *just get over it*.
-
@Jaime said:
I would really like to know how my description of one incident and my lauding of the Engineering profession got translated to the villification of all programmers.
I apologize for the knee jerk reaction, although I guess it was these sentences that especially sounded like you considered programmers as careless:
@Jaime said:
I have a mechanical engineering degree and I am shocked at the difference in the way a programmer approaches his job vs. an engineer. Licensed Professional Engineers know that their professional livelihood rests on their projects not hurting the public.
All I'm saying is programmers come in all forms: beginners, advanced, good, bad, white hat, black hat, social butterflies, basement dwellers, and everything in between. Although I can't say with 100% certainty, judging by the quality and robustness of the software and the process involved, Boeing, NASA, General Motors, Raytheon, and any other major corporation that engineers complex equipment that require some level of programming don't hire Paulas and if they did, they'd find out pretty soon and correct the situation.
Giving us anecdotes on Therac 25 and anything else does nothing to promote a case for or against programmers. To Therac 25 I can easily come up with many preventable non-software-engineering disasters such as the Challenger Explosion, The Big Dig, or, most recently, the Metrodome, each of which didn't seem to hold the engineers individually responsible, but the contractors as a whole. Just by referencing Therac 25, you've shown that it's a case-study in software engineering that is taught in universities and its aftermath did, in fact, change some of the ways we approach programming vital software.
As a final note, software engineering is indeed different than programming. A software engineer differs from a programmer in that they are part of a defined process similar to other engineering fields in that there is a project manager, a well-defined requirements document, subject matter experts, a quality assurance department, and a standard which must be followed to consider software to be ready for distribution. While a lot of companies do not do this kind of due diligence, all major companies which must meet criteria and pass inspection must use a lot of this sort of red tape to ensure the product won't take lives or injure people. If you go to the offices of Raytheon, Boeing, or Ford, and compare the software department with the mechanical engineering department, and I'm quite sure you'll see a lot of similarities in how they approach the process and ensure their product is safe and reliable.
-
@Jaime said:
I certainly believe that the quality of work produced by my profession is lower than many older professions
Yes, but can you prove it is? Do you have data? People "believe" a lot of wrong things.
@Jaime said:
and I think we need to work hard to improve it
I think it's safe to say we all do. Except IBM programmers. And the guys who designed GIMP's UI.
@Jaime said:
but I never came remotely close to calling programmers "heartless, careless, antisocial, and inept", those are your words.
You're certainly coming across that way, because I'm reading your posts the same way. There's a big, "oh I'm an engineer, we're so much better than you people" vibe to it, too.
But what's bother me is: assigning blame doesn't help make software safer. But all you've talked about is assigning blame for the problem. I don't think you're ever going to get us to agree to that, so just switch tracks.
-
@blakeyrat said:
There's a big, "oh I'm an engineer, we're so much *better* than you people" vibe to it, too.
But I'm not an engineer. Every response seems to have been triggered as a defense to a statement never made or intended. I happen to know a lot about engineers because I have an engineering degree and I went halfway through the process of becoming a Professional Engineer (I passed the New York State Engineer in Training exam almost twenty years ago).
-
@Jaime said:
@blakeyrat said:
There's a big, "oh I'm an engineer, we're so much better than you people" vibe to it, too.
But I'm not an engineer. Every response seems to have been triggered as a defense to a statement never made or intended. I happen to know a lot about engineers because I have an engineering degree and I went halfway through the process of becoming a Professional Engineer (I passed the New York State Engineer in Training exam almost twenty years ago)."But I'm not an engineer! [description of traits that define you as an engineer]"
Ok, ok, fine, you're not an engineer.
-
@blakeyrat said:
@Jaime said:
@blakeyrat said:
"But I'm not an engineer! [description of traits that define you as an engineer]"There's a big, "oh I'm an engineer, we're so much *better* than you people" vibe to it, too.
But I'm not an engineer. Every response seems to have been triggered as a defense to a statement never made or intended. I happen to know a lot about engineers because I have an engineering degree and I went halfway through the process of becoming a Professional Engineer (I passed the New York State Engineer in Training exam almost twenty years ago).Ok, ok, fine, you're not an engineer.
He didn't say that he was ever responsible for the mechanical operation of a train.
-
(For want of a better parent to reply to given the therac stuff...)
Where software actually matters there are procedures in place. My last job was in the petrochemical industry. Rigs, refineries etc. Our software measured the stuff going through, and controlled the hardware that let it through (and calibration of equipment, and... I won't bore you.) We needed cetification for the software that was put in for both purposes. On each project (certs defined by the country taking our stuff.) Certification was via extensive testing before it got anywhere near the place of operation.
Individual certification isn't here yet, but for the 'new' systems put in place? Where certification matters, it (generally) happens.
-
@blakeyrat said:
"But I'm not an engineer! [description of traits that define you as an engineer]"
Ok, ok, fine, you're not an engineer.
Coming into this late, but in VA (at least) you can not legally call yourself an engineer unless you have a valid Professional Engineer license (which requires continual updates to keep current)
And as for screw ups .. you should all read the Risks List .. that site is dedicated to presenting genuine screwups whether they be hardware, software or people. Where as this site plays screwups up for laughs, Risks List presents the serious side of things.
