Prolly referred to this. (And her character's last name was "Swanson", not "Samsonite" -- GP needs to get his facts straight before posting to Slashdot, like everyone else around here always does.;)
And this is where the problem seems to lie, with the group stating that 'whenever possible the CCIF will emphasize the use of open, patent-free and/or vendor-neutral technical solutions.'
One can be for interoperability without having to be against proprietary solutions. The latter is a political choice of that group's, not a technology one. They're basically saying eff you MS, we really don't want your kind in our little group, so it's no wonder MS and Amazon et al. oppose it.
Presumably you are arguing that concious thought makes pain worse.
And maybe therein lies what should be the standard. Lots of things feel pain, for a wide range of definitions of "feeling pain". Pain is an everyday part of nature. But why then are we such pussies about it? I would argue because of the psychological effect. My dog has had some level of pain, such as after a surgery, and she's shrugged it off, because her mind just doesn't think about it. But *we* need pain meds, cuz otherwise sitting there in throbbing agony would make us lose our minds! So, maybe the criterion should be not just the capability of feeling pain, but also mental distress over it. Whereby pain causing not just an avoidance reaction, but demonstrated mental distress, would be labeled unethical.
I was doing Java work to connect to a web service written in C#. We were the first people to start using their web service and we were giving them advice on what needed to be fixed. One of the few issues we found with it were that their WSDL was full of errors.
I had a similar experience writing a C++ web service to connect to another group's Java one. They had no idea what all that "wizdelly stuff" was, all they knew was that it worked Java<->Java (or rather whatever library they were using worked when the exact same one was used on both sides). I had to explain to them that one of the whole points of web services was programming language and platform agnosticism. The point is, I think any VM'ed language like Java or C# or VB can attract those with insular attitudes ("all I need is my own little world") and less technical ability and interest.
95% of what you are going to see in commercial software is "lowest common denominator" code. For a C++ project, for instance, that means, it will look like C with classes.
C with classes with all public members. I.e. no object-oriented design/use of polymorphism, and basically no C++. You're right, by the time C++ became popular, most C programmers were married and had kids, and they weren't about to learn another language, they just wanted to put it on their resume (usually listed as "C/C++"). My advice is learn C++ if one wants to, but don't expect to ever run across an actual programmer of it, at least in meatspace.
(1) using, as much as you can, every language feature that distinguishes C++ from C, or (2) using the language features that tend to lead to good, maintainable code and eschewing the rest.
From what I've seen, (2) is just code for the opposite of (1). I.e. I've worked in C++ jobs for 13 years and have never really worked with another actual C++ programmer, because they all seemed to pretty much draw the line at about operator++. I.e. your whole attitude that there really *are* any features that don't lead to good, maintable code. (Vs. just ones you don't know how to use in good, maintainable ways.) For such people, I recommend to them Java.
Indeed. Something that stood out to me (from that scatter graph) is: * If you don't want to spend more than $100 on a CPU, AMD wins. * If you don't want to spend more than $150 on a CPU, AMD wins. * If you don't want to spend more than $200 on a CPU, AMD wins. * If you don't want to spend more than $250 on a CPU, AMD wins. * If you don't want to spend more than $300 on a CPU, Intel's (cheapest) i7 wins by far.
The catch, of course, is that once you graduate you don't get to keep the tools.
Please define "don't get to keep". Do the tools for example require annual reactivation via the Dreamwhatever program or they stop working or something?
There needs to a fuckedboss.com, disguised as a professional networking site for managers of technical people, where whacked PHB's like you can sign up so that when we're looking for a job, we can look up the hiring manager's name to see if we should even show up for the interview.
It could also be that MS outsources the work on their web sites. I was a web developer once for a company that had about 30 of us. We were working on building web sites of a certain kind for the company's customers, and I was shocked one day to find out that work on our own company web site was not done in-house. It must've made perfect sense to someone in upper mgmt., tho.
While testing a socket helper class I was writing about a year and a half ago, I noticed that the Google homepage's entire direct content (i.e. excluding content like their logo, which the browser fetches in a separate request (and which will be cached for visits thereafter)) always arrived in a single TCP/IP packet. I assumed that this was on purpose, by the following reasoning:
This bypasses the possibility of the rendering of a partially downloaded web page. A user who sees part of the page there but it's still not yet in a state where they can begin to use it will likely think it's due to slowness on that web site's end. (I.e. they'll be mad at Google.)
In any delay in loading that first packet, even if on the web site end, because users don't see anything yet, they're likely to assume they're just experiencing a slow connection for some indeterminate reason, and assign blame to their ISP or the Internet in general.
So if all of Google's main page content still fits in the 1500 or so byte limit, then they prolly indeed are dropping characters here and there and violating standards, as long as it still renders properly, to maintain that snappy response we're used to when going to Google. In other words, I think Google's characteristically spartan home page was not only about the look, but the look and feel. Pretty smart.
TFA writer pats himself on the back too hard -- it's not a major defeat for this social conservative. Even tho I don't believe in evolution, I find what you said to be utterly, perfectly reasonable. Start the course with "BTW, we're going to talk about things this semester in science class as if they're proven fact. But remember, it doesn't work that way. Now, open your books to page 1 and let us begin."
But here's where you're wrong: You're trying to feed dog food to my cat, which is uncool. You care about fish and I care about unicorns, and they don't get along, so I win. <rolls eyes>
If my disallowing, via restrictions, your use of my software "restricts what you can do with your computer", then so does my not writing the software in the first place.
Many organizations are horrifically inefficient yet survive just fine, such as on sheer inertia.
A wasteful company might very well pay *more* than market (waste the wages budget too). How well a company's doing affects how many people they can hire, not what they can pay them.
If you're at a place that does IT "right", such as for example the redundancy and the attitude to always keep email available during office hours, you've probably found the holy grail, as most people will never see such an organization. Same for the area of software development, my field -- I've worked at 5 places so far, 3 small and 2 ginormous, and nowhere has it been done "right", or even close to it. Companies just don't care that much about the technology parts to spend much attention making sure they're done in near optimal fashion.
Pay levels for occupations are not related to IT efficiencies, so that's a red herring. And I don't believe organizations' actual surviveability are based in any significant part on their IT costs. Any more than it does their accounting costs. IT is just an infrastructure/support dept., and is no more special than any other.
Providing basic desktop PC's for office workers is not "coddling" them.
And office workers do care about what it's like using the systems they have to use everyday. At my first job our bug-tracking system required using a 3270 terminal emulator. No one likes dinosaur systems. No one likes the awkward and primitive UI's, and lag and lack of interoperability. Web apps are better, but are still pitiful in terms of the richness of UI controls and responsiveness of a desktop application. And no one wants to be dead in the water when the network goes down or a server goes down or is overloaded. These things are typically stressed, and catastrophically fail much more often than a single PC, that spends most of its life loafing. The negatives of undiversifying by undistributing failure points needs to be weighed against the positives of easier control. Seems to me like it's mainly trading one kind of risk for another, and pissing everyone off in the process.
GP prolly meant copying a path from somewhere in the Windows GUI, say the address bar in Windows Explorer or the properties dialog for a file, and then pasting into a C or C++ source file. Then you either have to manually convert them all to forward slashes or double-up all the backslashes.
So basically your response, in summary, is yes, you agree, things should go back to the 70's, but for good business (economic) reasons. I see your point on the economic reasons, it's just that no one wants that, so good luck with that happening in 10 years. E.g. every manager is gonna want a real PC, not a dumb terminal. Professional-level people will favor working for companies that provide them real PC's instead of dumb terminals. It won't fly. It also prolly makes economic sense to make salaried workers punch in and out every day like McDonald's workers, to make sure they're not cheating on hours. Except the only people who will work in subpar working conditions are subpar people, and attracting and retaining only subpar people is probably not good business sense.
You're forgetting that it [Netscape 4] just simply didn't support anywhere near as much of the specs as Internet Explorer 6.
Are you attacking a strawman here? My only purpose for bringing up the things that I did is to say that I avoided known problem areas and to concede that it's possible that I unknowingly avoided some of the alleged bugginess by virtue of the kind of web development that I was doing.
So what you're saying is that as long as you don't count all the buggy bits of Internet Explorer 6, it isn't so buggy?
I'm saying that I don't count something as being super-buggy if it was no problem to develop for. If you developed for Netscape 4 and thought it wasn't so bad, then you must've not been doing any DHTML. I wasn't asking Navigator to do something it didn't intend to support, in the way it intended to support it, I was using Netscape's own online docs (which were very good, I might add), and their POS browser at every turn didn't work like they said. Things would wind up positioned all over the place (esp. after a resize), phantom layers appearing in the page source that mirrored your divs but that were all fucked up, and constant bombing out. Netscape 4 was one of the two most frustrating development experiences, by far, that I've had in my career so far (the other being developing for Java 1.0 and 1.1), and I practically had to write completely different code for it from IE4. Developing for IE6 and FF1.5/2.0 was a total pleasure in comparison, so to me that makes it not so buggy.
Slashdot Mirror
Prolly referred to this. (And her character's last name was "Swanson", not "Samsonite" -- GP needs to get his facts straight before posting to Slashdot, like everyone else around here always does. ;)
One can be for interoperability without having to be against proprietary solutions. The latter is a political choice of that group's, not a technology one. They're basically saying eff you MS, we really don't want your kind in our little group, so it's no wonder MS and Amazon et al. oppose it.
Presumably you are arguing that concious thought makes pain worse.
And maybe therein lies what should be the standard. Lots of things feel pain, for a wide range of definitions of "feeling pain". Pain is an everyday part of nature. But why then are we such pussies about it? I would argue because of the psychological effect. My dog has had some level of pain, such as after a surgery, and she's shrugged it off, because her mind just doesn't think about it. But *we* need pain meds, cuz otherwise sitting there in throbbing agony would make us lose our minds! So, maybe the criterion should be not just the capability of feeling pain, but also mental distress over it. Whereby pain causing not just an avoidance reaction, but demonstrated mental distress, would be labeled unethical.
The only people I've been told eat babies have all been Republican politicians -- when were you in office? ;)
I was doing Java work to connect to a web service written in C#. We were the first people to start using their web service and we were giving them advice on what needed to be fixed. One of the few issues we found with it were that their WSDL was full of errors.
I had a similar experience writing a C++ web service to connect to another group's Java one. They had no idea what all that "wizdelly stuff" was, all they knew was that it worked Java<->Java (or rather whatever library they were using worked when the exact same one was used on both sides). I had to explain to them that one of the whole points of web services was programming language and platform agnosticism. The point is, I think any VM'ed language like Java or C# or VB can attract those with insular attitudes ("all I need is my own little world") and less technical ability and interest.
95% of what you are going to see in commercial software is "lowest common denominator" code. For a C++ project, for instance, that means, it will look like C with classes.
C with classes with all public members. I.e. no object-oriented design/use of polymorphism, and basically no C++. You're right, by the time C++ became popular, most C programmers were married and had kids, and they weren't about to learn another language, they just wanted to put it on their resume (usually listed as "C/C++"). My advice is learn C++ if one wants to, but don't expect to ever run across an actual programmer of it, at least in meatspace.
(1) using, as much as you can, every language feature that distinguishes C++ from C, or (2) using the language features that tend to lead to good, maintainable code and eschewing the rest.
From what I've seen, (2) is just code for the opposite of (1). I.e. I've worked in C++ jobs for 13 years and have never really worked with another actual C++ programmer, because they all seemed to pretty much draw the line at about operator++. I.e. your whole attitude that there really *are* any features that don't lead to good, maintable code. (Vs. just ones you don't know how to use in good, maintainable ways.) For such people, I recommend to them Java.
Indeed. Something that stood out to me (from that scatter graph) is:
* If you don't want to spend more than $100 on a CPU, AMD wins.
* If you don't want to spend more than $150 on a CPU, AMD wins.
* If you don't want to spend more than $200 on a CPU, AMD wins.
* If you don't want to spend more than $250 on a CPU, AMD wins.
* If you don't want to spend more than $300 on a CPU, Intel's (cheapest) i7 wins by far.
You mean like the kind who'd write with a straight face "the new Web 2.0 world of script-based PHP"?
The catch, of course, is that once you graduate you don't get to keep the tools.
Please define "don't get to keep". Do the tools for example require annual reactivation via the Dreamwhatever program or they stop working or something?
There needs to a fuckedboss.com, disguised as a professional networking site for managers of technical people, where whacked PHB's like you can sign up so that when we're looking for a job, we can look up the hiring manager's name to see if we should even show up for the interview.
It could also be that MS outsources the work on their web sites. I was a web developer once for a company that had about 30 of us. We were working on building web sites of a certain kind for the company's customers, and I was shocked one day to find out that work on our own company web site was not done in-house. It must've made perfect sense to someone in upper mgmt., tho.
I've never been paid to code web pages to standards, my bosses have always told us to make it work in this and this browsers.
While testing a socket helper class I was writing about a year and a half ago, I noticed that the Google homepage's entire direct content (i.e. excluding content like their logo, which the browser fetches in a separate request (and which will be cached for visits thereafter)) always arrived in a single TCP/IP packet. I assumed that this was on purpose, by the following reasoning:
So if all of Google's main page content still fits in the 1500 or so byte limit, then they prolly indeed are dropping characters here and there and violating standards, as long as it still renders properly, to maintain that snappy response we're used to when going to Google. In other words, I think Google's characteristically spartan home page was not only about the look, but the look and feel. Pretty smart.
Yup, that's what I saw at first glance. And then instantaneously the next thought that popped into my head was: Finally, an explanation!
TFA writer pats himself on the back too hard -- it's not a major defeat for this social conservative. Even tho I don't believe in evolution, I find what you said to be utterly, perfectly reasonable. Start the course with "BTW, we're going to talk about things this semester in science class as if they're proven fact. But remember, it doesn't work that way. Now, open your books to page 1 and let us begin."
There are more deaths by automobile; maybe we should ban driving as it is clear that owning a car means you are prone to killing.
I wonder what makes old people especially so bloodthirsty about this? Did they have Doom on the abacus back then?
But here's where you're wrong: You're trying to feed dog food to my cat, which is uncool. You care about fish and I care about unicorns, and they don't get along, so I win. <rolls eyes>
If my disallowing, via restrictions, your use of my software "restricts what you can do with your computer", then so does my not writing the software in the first place.
Many organizations are horrifically inefficient yet survive just fine, such as on sheer inertia.
A wasteful company might very well pay *more* than market (waste the wages budget too). How well a company's doing affects how many people they can hire, not what they can pay them.
If you're at a place that does IT "right", such as for example the redundancy and the attitude to always keep email available during office hours, you've probably found the holy grail, as most people will never see such an organization. Same for the area of software development, my field -- I've worked at 5 places so far, 3 small and 2 ginormous, and nowhere has it been done "right", or even close to it. Companies just don't care that much about the technology parts to spend much attention making sure they're done in near optimal fashion.
Pay levels for occupations are not related to IT efficiencies, so that's a red herring. And I don't believe organizations' actual surviveability are based in any significant part on their IT costs. Any more than it does their accounting costs. IT is just an infrastructure/support dept., and is no more special than any other.
Providing basic desktop PC's for office workers is not "coddling" them.
And office workers do care about what it's like using the systems they have to use everyday. At my first job our bug-tracking system required using a 3270 terminal emulator. No one likes dinosaur systems. No one likes the awkward and primitive UI's, and lag and lack of interoperability. Web apps are better, but are still pitiful in terms of the richness of UI controls and responsiveness of a desktop application. And no one wants to be dead in the water when the network goes down or a server goes down or is overloaded. These things are typically stressed, and catastrophically fail much more often than a single PC, that spends most of its life loafing. The negatives of undiversifying by undistributing failure points needs to be weighed against the positives of easier control. Seems to me like it's mainly trading one kind of risk for another, and pissing everyone off in the process.
GP prolly meant copying a path from somewhere in the Windows GUI, say the address bar in Windows Explorer or the properties dialog for a file, and then pasting into a C or C++ source file. Then you either have to manually convert them all to forward slashes or double-up all the backslashes.
So basically your response, in summary, is yes, you agree, things should go back to the 70's, but for good business (economic) reasons. I see your point on the economic reasons, it's just that no one wants that, so good luck with that happening in 10 years. E.g. every manager is gonna want a real PC, not a dumb terminal. Professional-level people will favor working for companies that provide them real PC's instead of dumb terminals. It won't fly. It also prolly makes economic sense to make salaried workers punch in and out every day like McDonald's workers, to make sure they're not cheating on hours. Except the only people who will work in subpar working conditions are subpar people, and attracting and retaining only subpar people is probably not good business sense.
Are you attacking a strawman here? My only purpose for bringing up the things that I did is to say that I avoided known problem areas and to concede that it's possible that I unknowingly avoided some of the alleged bugginess by virtue of the kind of web development that I was doing.
I'm saying that I don't count something as being super-buggy if it was no problem to develop for. If you developed for Netscape 4 and thought it wasn't so bad, then you must've not been doing any DHTML. I wasn't asking Navigator to do something it didn't intend to support, in the way it intended to support it, I was using Netscape's own online docs (which were very good, I might add), and their POS browser at every turn didn't work like they said. Things would wind up positioned all over the place (esp. after a resize), phantom layers appearing in the page source that mirrored your divs but that were all fucked up, and constant bombing out. Netscape 4 was one of the two most frustrating development experiences, by far, that I've had in my career so far (the other being developing for Java 1.0 and 1.1), and I practically had to write completely different code for it from IE4. Developing for IE6 and FF1.5/2.0 was a total pleasure in comparison, so to me that makes it not so buggy.
The 70's called, they want their dumb terminals and ideas back.