From TFA: "Other professions, like medicine, the law, and engineering, have values and a professional ethic, where certain things are valued for their own sake." Evidently the author is unfamiliar with common law, in which the law evolves over time via practical application, much as programming languages evolve and mutate. This is contrast to statutory law, which is created from whole cloth, much as one might create a new programming language which has roots in other languages but is fundamentally different from any of them.
If the analogy is apt, "warts" presumably appear in the law. Lawyers, judges, or legislators might wish to remove them. However, practical considerations such as disruption of some existing body of law might prevent that. Also, warts are, by definition, subjective. So, one man's wart might be another man's treasure.
Going back to programming, the use of pointers in C++ is both a wart inherited from C, and a useful feature that can't be removed without fundamentally changing the language. Thus, we have C++ templates for smart pointers, which seek to ameliorate the wart without actually expurgating it.
Many years ago, I attended a lecture at my university that was given by William Shockley who received a Nobel prize along with others for their invention of the transistor. It was striking to me how the faculty reacted to him. They were truly in awe, and treated him with something close to reverence. I've always imagined that they received him that way because he received the Nobel prize, not because he invented the transistor, though it's just a feeling.
Shockley was a controversial figure toward the end of his life, including when I saw him, for his views on the relationship between intelligence and genetics, which were (are) considered racist. I didn't know anything about his views about that in advance. But before the lecture started, a group of minority students entered the lecture hall very dramatically and stood in front of the podium with arms crossed, facing the audience, staring straight ahead. Of course, they were peacefully expressing their displeasure about his views. A buzz went around, and folks like me who didn't know what was going on soon heard an explanation from someone nearby who did.
Shockley didn't speak at all about those views, and instead focused on the transistor and other appropriate topics. Suddenly, in the middle of the lecture, I noticed that the body language of students who were standing up front had changed. Instead of silently expressing their disdain for his views, their posture had softened and they were listening to his lecture with interest, just as I was. Except they were standing at the front rather than sitting in the seats.
If it weren't for his invention of the transistor - and possibly his receipt of the Nobel Prize - the world would little note nor long remember Shockley's views on the relationship between intelligence and genetics. Which, to be honest, seem kindda dumb for a man of his breeding.
Sure, but what if a red LED is a natural evolution while blue LED, once thought impossible is the true revolutionary idea?
Exactly right. A (high-brightness) blue LED must have been desired shortly after the red one was invented in 1962, but it wasn't until 1993 that one was created. So, it must have been a pretty difficult physics problem to solve.
That said, since blue LEDs are a variation on a theme, they seem more like an "invention" than a fundamental breakthrough, like other Nobel prize winners such as the transistor. For example, is a blue LED as fundamentally different from a red LED as a transistor is from a vacuum tube?
Finally! Wi-Fi enabled thermostats have found a set of customers who have a genuine need for them: security researchers. But if the thermostats were truly secure, even that small market would dry up. After all, who wants to play a game that can never be won?
Personally, rather than buy a Wi-Fi thermostat, I've been training my cat to adjust the thermostat just before I come back after three-day weekends. In all honesty, I haven't had much luck with that so far, but I'll get the cat trained eventually, I know I will. Just gotta keep trying.
Now that you mention it, though, I've really thought through the security implications of owning such a highly trained cat...
Not all FOSS project names are as crappy as possible. But one is. Have you heard about the new "Crappy" project: "Crappy's really a praiseworthy project, yutz".
I think you're onto something. Perhaps *that's* why the secret formula for Coke has never been open-sourced, but remains locked in a vault in Atlanta to this very day. Likewise for the secret Krabby-patty formuler. Just think what havoc Pepsi and Plankton could wreak with the TrueCrypt code...
If DRM and copy prevention mechanisms worked, how do you explain the fact that each and every one has been bypassed?
Oh, and also voluntarily abandoned by Apple - at least in the case of music. In fact, as I understand it, Steve Jobs himself eventually succeeded in badgering the record industry into allowing the removal of DRM from music distributed by iTunes. Evidently, he thought he could sell more music that way.
Which means most independent observers have long concluded the Castros like the embargo, because it allows them to claim everything that is wrong with the country is Evil Foreign Gringo's fault.
Indeed. I believe Br'er Rabbit used a similar tactic to retain control over the briar patch.
Righteo. It's long been my habit to never use an elevator when stairs will do - which is always the case where I go. And I've recently adopted the habit at work of going to the restroom in an adjacent building once or twice a day rather than just always using one just down the hall. These things may seem like a hardship at first but they soon become easy, and - if the need isn't too urgent - relaxing.
A related form of exerlaxation is running up the down escalator at a shopping mall. Oh, and don't worry about the dirty looks from old ladies - they somehow always manage to get back up before the end of the escalator, so long as you start when they're somewhere near the top.
Anyone who has worked extensively with the stuff will tell you it is NOT safe unless you are careful.
Right. As someone who has had several skin issues successfully medically treated by having them burned off with liquid nitrogen, dumping it on your head seems like a *very* bad idea - even for somebody who knows what they're doing. In my case, small drops of it on a Q-tip, held in place for a few seconds (no Leidenfrost effect here), were powerful enough to freeze and ultimately destroy the skin underneath, as intended.
Many years ago, in the old DOS days, I loved a nice little game that most folks probably have never heard of called Chip's Challenge. Anybody remember that?
Evidently, a modern imitation of it called "Tile World" is available. Maybe I'll have to try that sometime.
TWC's customer service reps are reportedly a bit overwhelmed by call volume at the moment
Hopefully, their remaining customers, who evidently are willing to wait on hold for at least two hours under normal circumstances, will understand and will patiently wait on hold for ten hours for the privilege of being told "We're looking into it but there's nothing we can do right now."
Luckily, TWC has competition in my area. Every time I see an ad from them that seems cheaper than what I'm paying to their competitor, I remember the horrifying customer service, and the urge to save money goes away.
1) You'll spend as much or more time fixing code than you do writing it. Therefore, anything you can do early in the process to reduce those is time well spent, even though it may seem like a waste of time: - Single-step through every line of newly written code - Do a little personal code review of all code you write - Develop module tests as you write code - Test every line of code in some way, either informally or formally. - Write comments and documentation, even if just for your own benefit. Your future self may not understand what you've done as well as your present self does. - Make changes to working code sparingly, and take steps to make sure that every change is for the better. (See above.) 2) Write code in small pieces, get the pieces working well, and stitch them together. Don't write something giant all at once that may never work. 3) Approach debugging on a data-driven basis. Most problems can be solved best by instrumenting what's happening in some way, e.g., via a debugger or a simulation. Though the trial-and-error method often is appealing for instant gratification, it's usually inefficient. 4) Read a few very good books: "Writing Solid Code", "Code Complete", "The Mythical Man Month", "The C Programming Language". 5) Learn several languages, including Python. Every language you learn makes you better at the other languages you already know.
Thanks for your comment. FWIW, here's what really happened. The function took a std:string as a parameter. The nominal use of it was to put in a char * literal which would get automatically converted to a string, so the parameter couldn't be passed by reference. While trying to step into the function, I stepped through the string constructor, which made several small function calls. When I replaced the parameter declaration with "char *", all that went away, and I was able to step directly into the function.
To be fair, the actual runtime overhead of the std:string constructor might be minimal, and could potentially be avoided by using a reference in many cases - though not this one. So, my concern about bloat when using template classes was anecdotal and might be overblown. As with any tool, you should use the right one for the job, and the string class does have some advantages, notably the ability to magically grow as needed. In this case, though, a char * would have worked just fine, so I contend that the original programmer didn't choose the right tool for this job.
I've used STL classes over the years, primarily vector and string, but I've had many experiences like this where something that C provided was a better fit for what I was trying to do. For example, a file name parameter probably doesn't need to magically grow, so a char * works just fine for that. That sort of experience, combined with having to repeatedly consult the documentation about STL functions because they aren't very intuitively named, has led me to prefer C constructs when I could potentially use either. That's what I meant in my original post when I said "many programmers minimize their use of templates".
Then again, I'm from the "less is more" school of programming. Some folks like to impress themselves and/or their friends by using as many fancy constructs as possible, in order to be judged a "*good* programmer" - as another commenter in this thread evidently does.
Though my original post was perhaps a bit overstated (for your entertainment), I actually do use the STL, but only at a very basic level, and only where it explicitly solves a problem. I think I would be a lot warmer to it if C++ templates and the STL itself were better designed. For example, I much prefer Python's string functions and MFC's "CString" class to std:string.
But even if templates and the STL were better, good-old-fashioned C still can meet most such needs very nicely. And as Tim Peters said, "Beautiful is better than ugly." (BTW, I wonder if Dr. Stroustroup thinks his template baby is beautiful? - maybe he'll tell us.;-)
...but I do at least make an effort to understand the language that I'm using.
Unlike us "bad" programmers...
My basic point in the original point was that C++ templates are so complex as to be nearly impossible for most of us to *fully* understand. Don't you think that implies at least some sort of effort to understand them? In retrospect, though, my failure to fully understand them can only be attributed to my own abilities, not to the design of templates themselves. My bad...
Thanks. Please forgive my idocy. I think I got fooled the other day when I stepped through several std:string functions that were involved in passing a std:string parameter into a function. Then I replaced the parameter with a char *, and there was nothing to step through anymore. Apparently, though, all that std::string stuff would magically disappear in the release version. I forget whether the string parameter was passed by reference or not - somebody else wrote that part.
So what if you used a set of powerful templates to create a complex layered system rather than writing a simple one by hand? For an example, compare the STL string class to C's string library. It's not about the use of templates, per se, it's about the design of the systemthat the use of templates may lead you to. In effect, the major benefit of templates - their ability to create large, reusable systems - is a major drawback if you're looking for something fast and small.
Likely true, but the benefit of C that I'm highlighting is that it gives you very little rope to hang yourself with in terms of creating a system composed of layer-upon-layer of classes. In contrast, I once worked with someone who loved to create class-upon-inherited-class for the simplest things in C++. Everyone who looked at his code wondered "where's the beef?", that is, the part that did something useful. The code worked, so the useful part must have been in there somewhere. But it sure wasn't easy to locate. I think he had tiny bits of useful stuff cleverly hidden in most of his classes. As best I could tell, though, some did nothing at all.
Basically, I regard C's inability to create a large complex hierarchy of objects, together with its ability to support objects in a basic way via pointers to structures, as a primary selling point that explains its persistence in a world where a "better" superset has long been available. That's not to say that the C++ approach of layering inherited classes is bad or wrong, just that its lack in C can prevent a certain category of problems.
Slashdot Mirror
From TFA: "Other professions, like medicine, the law, and engineering, have values and a professional ethic, where certain things are valued for their own sake." Evidently the author is unfamiliar with common law, in which the law evolves over time via practical application, much as programming languages evolve and mutate. This is contrast to statutory law, which is created from whole cloth, much as one might create a new programming language which has roots in other languages but is fundamentally different from any of them.
If the analogy is apt, "warts" presumably appear in the law. Lawyers, judges, or legislators might wish to remove them. However, practical considerations such as disruption of some existing body of law might prevent that. Also, warts are, by definition, subjective. So, one man's wart might be another man's treasure.
Going back to programming, the use of pointers in C++ is both a wart inherited from C, and a useful feature that can't be removed without fundamentally changing the language. Thus, we have C++ templates for smart pointers, which seek to ameliorate the wart without actually expurgating it.
Many years ago, I attended a lecture at my university that was given by William Shockley who received a Nobel prize along with others for their invention of the transistor. It was striking to me how the faculty reacted to him. They were truly in awe, and treated him with something close to reverence. I've always imagined that they received him that way because he received the Nobel prize, not because he invented the transistor, though it's just a feeling.
Shockley was a controversial figure toward the end of his life, including when I saw him, for his views on the relationship between intelligence and genetics, which were (are) considered racist. I didn't know anything about his views about that in advance. But before the lecture started, a group of minority students entered the lecture hall very dramatically and stood in front of the podium with arms crossed, facing the audience, staring straight ahead. Of course, they were peacefully expressing their displeasure about his views. A buzz went around, and folks like me who didn't know what was going on soon heard an explanation from someone nearby who did.
Shockley didn't speak at all about those views, and instead focused on the transistor and other appropriate topics. Suddenly, in the middle of the lecture, I noticed that the body language of students who were standing up front had changed. Instead of silently expressing their disdain for his views, their posture had softened and they were listening to his lecture with interest, just as I was. Except they were standing at the front rather than sitting in the seats.
If it weren't for his invention of the transistor - and possibly his receipt of the Nobel Prize - the world would little note nor long remember Shockley's views on the relationship between intelligence and genetics. Which, to be honest, seem kindda dumb for a man of his breeding.
Sure, but what if a red LED is a natural evolution while blue LED, once thought impossible is the true revolutionary idea?
Exactly right. A (high-brightness) blue LED must have been desired shortly after the red one was invented in 1962, but it wasn't until 1993 that one was created. So, it must have been a pretty difficult physics problem to solve.
That said, since blue LEDs are a variation on a theme, they seem more like an "invention" than a fundamental breakthrough, like other Nobel prize winners such as the transistor. For example, is a blue LED as fundamentally different from a red LED as a transistor is from a vacuum tube?
You don't understand...my cat has a *LOT* of time on her paws...
There's probably no good reason. But there's probably somebody out there who is at least as malicious as my cat.
If this does anything your unit is morbidly oversized.
Look, let's just leave the size of his unit out of this...
Exactly right. Give me mercury or give me death!
Thanks for sticking up for me, but I didn't actually have much to lose. My philosophy is: when life throws you tomatoes, make tomato paste.
Finally! Wi-Fi enabled thermostats have found a set of customers who have a genuine need for them: security researchers. But if the thermostats were truly secure, even that small market would dry up. After all, who wants to play a game that can never be won?
Personally, rather than buy a Wi-Fi thermostat, I've been training my cat to adjust the thermostat just before I come back after three-day weekends. In all honesty, I haven't had much luck with that so far, but I'll get the cat trained eventually, I know I will. Just gotta keep trying.
Now that you mention it, though, I've really thought through the security implications of owning such a highly trained cat...
Not all FOSS project names are as crappy as possible. But one is. Have you heard about the new "Crappy" project: "Crappy's really a praiseworthy project, yutz".
I think you're onto something. Perhaps *that's* why the secret formula for Coke has never been open-sourced, but remains locked in a vault in Atlanta to this very day. Likewise for the secret Krabby-patty formuler. Just think what havoc Pepsi and Plankton could wreak with the TrueCrypt code...
If DRM and copy prevention mechanisms worked, how do you explain the fact that each and every one has been bypassed?
Oh, and also voluntarily abandoned by Apple - at least in the case of music. In fact, as I understand it, Steve Jobs himself eventually succeeded in badgering the record industry into allowing the removal of DRM from music distributed by iTunes. Evidently, he thought he could sell more music that way.
Which means most independent observers have long concluded the Castros like the embargo, because it allows them to claim everything that is wrong with the country is Evil Foreign Gringo's fault.
Indeed. I believe Br'er Rabbit used a similar tactic to retain control over the briar patch.
Righteo. It's long been my habit to never use an elevator when stairs will do - which is always the case where I go. And I've recently adopted the habit at work of going to the restroom in an adjacent building once or twice a day rather than just always using one just down the hall. These things may seem like a hardship at first but they soon become easy, and - if the need isn't too urgent - relaxing.
A related form of exerlaxation is running up the down escalator at a shopping mall. Oh, and don't worry about the dirty looks from old ladies - they somehow always manage to get back up before the end of the escalator, so long as you start when they're somewhere near the top.
Anyone who has worked extensively with the stuff will tell you it is NOT safe unless you are careful.
Right. As someone who has had several skin issues successfully medically treated by having them burned off with liquid nitrogen, dumping it on your head seems like a *very* bad idea - even for somebody who knows what they're doing. In my case, small drops of it on a Q-tip, held in place for a few seconds (no Leidenfrost effect here), were powerful enough to freeze and ultimately destroy the skin underneath, as intended.
Many years ago, in the old DOS days, I loved a nice little game that most folks probably have never heard of called Chip's Challenge. Anybody remember that?
Evidently, a modern imitation of it called "Tile World" is available. Maybe I'll have to try that sometime.
TWC's customer service reps are reportedly a bit overwhelmed by call volume at the moment
Hopefully, their remaining customers, who evidently are willing to wait on hold for at least two hours under normal circumstances, will understand and will patiently wait on hold for ten hours for the privilege of being told "We're looking into it but there's nothing we can do right now."
Luckily, TWC has competition in my area. Every time I see an ad from them that seems cheaper than what I'm paying to their competitor, I remember the horrifying customer service, and the urge to save money goes away.
1) You'll spend as much or more time fixing code than you do writing it. Therefore, anything you can do early in the process to reduce those is time well spent, even though it may seem like a waste of time:
- Single-step through every line of newly written code
- Do a little personal code review of all code you write
- Develop module tests as you write code
- Test every line of code in some way, either informally or formally.
- Write comments and documentation, even if just for your own benefit. Your future self may not understand what you've done as well as your present self does.
- Make changes to working code sparingly, and take steps to make sure that every change is for the better. (See above.)
2) Write code in small pieces, get the pieces working well, and stitch them together. Don't write something giant all at once that may never work.
3) Approach debugging on a data-driven basis. Most problems can be solved best by instrumenting what's happening in some way, e.g., via a debugger or a simulation. Though the trial-and-error method often is appealing for instant gratification, it's usually inefficient.
4) Read a few very good books: "Writing Solid Code", "Code Complete", "The Mythical Man Month", "The C Programming Language".
5) Learn several languages, including Python. Every language you learn makes you better at the other languages you already know.
Thanks for your comment. FWIW, here's what really happened. The function took a std:string as a parameter. The nominal use of it was to put in a char * literal which would get automatically converted to a string, so the parameter couldn't be passed by reference. While trying to step into the function, I stepped through the string constructor, which made several small function calls. When I replaced the parameter declaration with "char *", all that went away, and I was able to step directly into the function.
To be fair, the actual runtime overhead of the std:string constructor might be minimal, and could potentially be avoided by using a reference in many cases - though not this one. So, my concern about bloat when using template classes was anecdotal and might be overblown. As with any tool, you should use the right one for the job, and the string class does have some advantages, notably the ability to magically grow as needed. In this case, though, a char * would have worked just fine, so I contend that the original programmer didn't choose the right tool for this job.
I've used STL classes over the years, primarily vector and string, but I've had many experiences like this where something that C provided was a better fit for what I was trying to do. For example, a file name parameter probably doesn't need to magically grow, so a char * works just fine for that. That sort of experience, combined with having to repeatedly consult the documentation about STL functions because they aren't very intuitively named, has led me to prefer C constructs when I could potentially use either. That's what I meant in my original post when I said "many programmers minimize their use of templates".
Then again, I'm from the "less is more" school of programming. Some folks like to impress themselves and/or their friends by using as many fancy constructs as possible, in order to be judged a "*good* programmer" - as another commenter in this thread evidently does.
Though my original post was perhaps a bit overstated (for your entertainment), I actually do use the STL, but only at a very basic level, and only where it explicitly solves a problem. I think I would be a lot warmer to it if C++ templates and the STL itself were better designed. For example, I much prefer Python's string functions and MFC's "CString" class to std:string.
But even if templates and the STL were better, good-old-fashioned C still can meet most such needs very nicely. And as Tim Peters said, "Beautiful is better than ugly." (BTW, I wonder if Dr. Stroustroup thinks his template baby is beautiful? - maybe he'll tell us. ;-)
...but I do at least make an effort to understand the language that I'm using.
Unlike us "bad" programmers...
My basic point in the original point was that C++ templates are so complex as to be nearly impossible for most of us to *fully* understand. Don't you think that implies at least some sort of effort to understand them? In retrospect, though, my failure to fully understand them can only be attributed to my own abilities, not to the design of templates themselves. My bad...
"I'm not bad. I'm just drawn that way." --Jessica Rabbit
Gee, Wally, if I use as many templates and template libraries as possible, do ya figure I can become a *good* programmer like you? ;-)
Thanks. Please forgive my idocy. I think I got fooled the other day when I stepped through several std:string functions that were involved in passing a std:string parameter into a function. Then I replaced the parameter with a char *, and there was nothing to step through anymore. Apparently, though, all that std::string stuff would magically disappear in the release version. I forget whether the string parameter was passed by reference or not - somebody else wrote that part.
To be fair, my complaint about portability was due to a very bad experience I had over 10 years ago. Maybe it's gotten better since then. ;-)
So what if you used a set of powerful templates to create a complex layered system rather than writing a simple one by hand? For an example, compare the STL string class to C's string library. It's not about the use of templates, per se, it's about the design of the systemthat the use of templates may lead you to. In effect, the major benefit of templates - their ability to create large, reusable systems - is a major drawback if you're looking for something fast and small.
Likely true, but the benefit of C that I'm highlighting is that it gives you very little rope to hang yourself with in terms of creating a system composed of layer-upon-layer of classes. In contrast, I once worked with someone who loved to create class-upon-inherited-class for the simplest things in C++. Everyone who looked at his code wondered "where's the beef?", that is, the part that did something useful. The code worked, so the useful part must have been in there somewhere. But it sure wasn't easy to locate. I think he had tiny bits of useful stuff cleverly hidden in most of his classes. As best I could tell, though, some did nothing at all.
Basically, I regard C's inability to create a large complex hierarchy of objects, together with its ability to support objects in a basic way via pointers to structures, as a primary selling point that explains its persistence in a world where a "better" superset has long been available. That's not to say that the C++ approach of layering inherited classes is bad or wrong, just that its lack in C can prevent a certain category of problems.