Then I'll blame you. Next time I fail to provide status update on a project and get called on it, I'll say, "my failure to do so is a mistake on jellomizer's part."
No. It gets a bad rap because of the sheer amount of it included in processed foods.
You can be sure that if the main ingredient in sugary drinks and processed foods were cane sugar, you'd hear how bad cane sugar is.
Notice how ordinary table salt and sodium was targeted also some time ago by health food proponents as a bad thing. It was because processed foods were laden with it, not because anybody thought table salt was poison.
It's a simplified argument, sure, but it is intended to drive the point home.
I have a suspicion that people who tend to defend Java do so because it's the only language they know to some greater extent; they learned it in college and got stuck to it.
Oh, and because instruction in the language probably came with unqualified aspersions against other, more mature languages; like "C is eveeeel because it has pointers!," and "C++ is a rat's nest, stay away from it!"
No worries. I am one of those readers that does not know anything about phosphorylation states or what phosphorylation is at all. Nonetheless, I found the original article very interesting, though absolutely over my head.
Your comments seemed more level-headed than others, and actually put some of the things that I took from the article into perspective.
For instance, it did strike me as fantastic that they would suggest not only that these mechanisms support memory encoding, but actual functional logic signal processing. But what do I know.
When I saw your comment, it was buried under the fold with a score of 1; hence my call to moderators. I thought it deserved much higher prominence, and now I see others did too.
As someone who got stuck for a while coding in Delphi.Net 1.1 some time ago, I can attest that years of experience in Delphi and other compiled languages did not prepare me for the clusterfsck that was the.Net wrapper to the language.
It was so stilted, and the code felt just wrong. It still haunts me in my nightmares.
To me it is rather obvious that the.Net framework was designed to be used with C#, and that contorting any other language to conform to the framework is a bit like nailing a tack to the wall with your head: it'll probably work, but it will hurt like hell, and you'll leave behind a bloody mess.
If the software requires Swiss-precision timing and/or extensive and convoluted steps in order to get it to work, then it very much "has errors." Double that for a Web page.
Because, love them or hate them, Microsoft is a software company trying to apply engineering to diverse software problems.
Ultimately, they make their money through the sale of products, so their interests tend to align with their users'.
Google, on the other hand is an advertising company trying to apply engineering to, um, data mining algorithms; and acquiring start-up companies for the purpose of increasing data collection and improve the targeting of ads.
Ultimately, they make their money through better and more targeted advertising, so their interests tend to align with those of advertisers'.
They didn't miss that opportunity, they dismissed it. They went on the path of becoming a search appliance, back when they were trying to find a stable business model. The 20% was also a way to fund research and development into new or orthogonal markets, and it made their employees happy to boot.
For a while it all looked good and the strategy seemed solid.
Then the advertising money started flooding their profit margins. All of a sudden, it became clear which direction they should go.
From that day on, they became a one-trick pony.
It's not that they sucked at everything else, it's that nothing that they have produced so far could match the rate at which advertising fills their coffers. There was no way to return to being an engineering or technology company if by doing so they had to lower their profits.
It didn't matter if they could succeed, they needed to make more money!
Eventually, this brutal mentality trickled down to the engineers and the rest of the crew. It's clear to most people now that, for all their perks and occasional technical brilliance, Google is no longer a technology company.
No-one except you seems to be talking about just writing random shit, though. You've created this fantasy world where everyone else is somehow advocating completely arbitrary trial-and-error programming, but I don't see anyone else posting here that actually did that.
That's precisely what the video and some people in this forum are advocating.
The idea that code is this arcane, magical entity that cannot be understood beforehand and that needs to be traced, step-by-step, in your head or on the computer until its purpose is gleaned by discovery; is in fact risible.
Sure, computers are a better tool to do this than our own brains. That's not the argument here. Neither it is that an interactive debugger is not useful.
The argument is that it is fundamentally wrong to write code naively without properly understanding what it was doing to begin with. And a need to iterate through it interactively--not to find errors or omissions in its function, but to understand what it is doing--is irresponsible and reveals gross inexperience.
The debugger is a tool that helps you find errors in your program, and these indeed happen. It is not, however, intended to be a substitute for proper design, thought, or understanding of the problems you are trying to solve.
So now you show how little you know. The correct approach is the one "similar to logic and math on abstract objects" than to physics, precisely because programming is applied mathematics.
The scientific method is used for physics to discover and understand the world around you, i.e. the model.
Programming is the implementation of a model that solves a problem, one that by all measures should have been discovered and understood already. This is indeed done from abstract concepts and first principles.
If you are discovering and learning how to solve a business problem while typing away source code, then you are in the wrong trade and your code is doomed to fail.
I think the point is that finding a CPU or compiler bug is a more rare occurrence than finding a bug in your own higher-level code.
This is why people roll their eyes at you when you claim to have found a compiler bug. It's not a belief that such a thing is impossible. It's just that you must prove exhaustively that you have accounted for and discarded all other possibilities.
The same people will admire you and sing your praises when you show them thorough proof of your discovery.
Ah... 1995. I remember back then talking to my girlfriend (now wife) about how things "used to be back in the day."
One of the things I noted even then was the reliance on the Internet. I recall stating something like, "back in the 80s, I could spend an entire stretch of days at a time, stuck in my room writing stupid home-brewed programs in my Commodore 64, with very little sleep; I could always find something to do with that little machine without any network connectivity or external communications. Nowadays, I sit at my computer desk, and if the 'Net is down, can't check my e-mail, can't use my browser, can't log into the BBS... it's useless, and I turn the fucker off."
Today, if my cable-modem connection goes down, I just grab my iPad and play Bejeweled or some other game, watch a movie, or catch up on my reading.
My, how times change.
It is not that I've grown less reliant on my Internet connection. I think it's just that modern machines are much more pleasant to use for many other use cases.
You see, in the 80s I was discovering computers and every silly "GOTO 10" statement was an adventure. In the 90s, I was exploring the vast frontiers of the Internet, and while using a PC was a fscking pain, I endured it for the value of the network and communications.
Now, the device is not a pain to use, and I use it for many other things than just exploring the Internet or communicating with others. This is the actual progress of our technologies: Convivial machines to fit human lifestyles.
It is amazing what we have now. I truly feel like I live in The Future.
The setting in question is, from within the "Privacy" tab in the Safari Preferences window:
Block cookies:
From third parties and advertisers
Always
Never
By default, the first one is selected. What it does is make Safari reject any cookie not originating from the domain of the currently opened page URL. This includes requests from iframes, images, and any other resource requested from an external domain.
That's it. By design, this should prevent, say, a cookie from "webtrendslive.com" or from "googleanalytics.com" unless the user is at a site hosted by those domains.
This is a good default, for this would be what most users would be expecting. The assumption is that any resource hosted on an external URI is most likely for advertising and tracking purposes (which, as it turns out, is true).
It would be understandable if the work-around was applied to a web site that depended on third-party resources which required the setting of cookies from said party in order to function--admittedly a rare edge case.
However, it's the advertisers themselves that are working around this feature; and this shows their intent on ignoring user preferences.
The user can always change it to "Never" and receive cookies from any, all, and sundry.
Apple does not give one shit about making Apple products usable in a corporate setting, it's all but accidental or incidental to making a good consumer product. They not only don't give a hoot about the IT department, but they don't give a hoot about people trying to use it as a business tool at all.
And there is another insightful point that you are missing. There is nothing magical about "business tools." Humans are humans and have certain requirements and methods for interacting with machines. These interface can coincide whether you're applying them in a tool for business or leisure.
The same note-taking application that I use for capturing some random thing I saw on the TV, can support my creative outbursts at the office.
The e-mail and communications applications I use to chat with friends and the browser I use to look-up what movie to watch tonight, do not suddenly stop being useful when I apply them to my office communications or research.
The iPad and the iPhone offer an extensible platform that starts with a very usable interface to the machine's capabilities. The user feels comfortable with this environment and could be more productive if applied to other uses such as business work-flows.
For this, many developers of real business tools are using it for office and productivity applications.
So, you were very right, it is all accidental or incidental to making a good consumer product.
However, you missed the forest by the trees. This is precisely why it eventually is adopted to other purposes--because it is such a good consumer product, and humans are the same and operate with machines in the same way whether they do it for fun or profit.
Actually, that's how it works. Yes, where I worked executives, managers and employees started using whatever they wanted, mainly iPhones and iPads. This was in spite of IT's resistance, which then was forced to adapt.
Those executives, managers, and employees were the ones attempting to try to use the devices as a business tool; IT was resisting because the adopted standard for years were different. Not only that, there was a push to evaluate other seemingly "business friendly" platforms like MS tablets of yore, or even BlackBerry or HP tablet devices. Those efforts did not bare fruit in the face of employees doing real work on Apple devices and clamoring for support.
I hear this is how it started in many other work places.
I understand your frustration. It sucks and sometimes it hurts, but you must trust me when I say that it does get better.
I know how you feel, I've been there myself. Eventually, you'll just realize that it is really not all that important that your old perception towards something as insignificant as a technology product, was wrong; and that arguing against it is not only futile, but emotionally destructive.
It truly is not the end of the world, and with time you'll come to accept it and recover from it.
Apple cares not a hoot for the IT manager trying to integrate Apple devices into their infrastructure. They care about the end user of such devices, whom feel empowered and more productive using them.
So this integration is not happening "in spite of Apple," but precisely because Apple devices help the end users be more productive. The integration is the result of this adoption.
You can say that the integration is not Apple's focus. They don't care if you figure out how to integrate the devices into the corporate work-flow or infrastructure--because consumers are buying using the devices, and therefore it's happening whether you integrate or not.
Not only that, but Microsoft themselves have been there before. At the start of the decade, they were the ones pushing for "tablet computing" as a work-enabling tool.
Slashdot Mirror
Then I'll blame you. Next time I fail to provide status update on a project and get called on it, I'll say, "my failure to do so is a mistake on jellomizer's part."
-dZ.
No. It gets a bad rap because of the sheer amount of it included in processed foods.
You can be sure that if the main ingredient in sugary drinks and processed foods were cane sugar, you'd hear how bad cane sugar is.
Notice how ordinary table salt and sodium was targeted also some time ago by health food proponents as a bad thing. It was because processed foods were laden with it, not because anybody thought table salt was poison.
It's a simplified argument, sure, but it is intended to drive the point home.
dZ.
I have a suspicion that people who tend to defend Java do so because it's the only language they know to some greater extent; they learned it in college and got stuck to it.
Oh, and because instruction in the language probably came with unqualified aspersions against other, more mature languages; like "C is eveeeel because it has pointers!," and "C++ is a rat's nest, stay away from it!"
dZ.
You know that application developer does not necessarily mean "PC" or "microcomputer" developer, right?
No worries. I am one of those readers that does not know anything about phosphorylation states or what phosphorylation is at all. Nonetheless, I found the original article very interesting, though absolutely over my head.
Your comments seemed more level-headed than others, and actually put some of the things that I took from the article into perspective.
For instance, it did strike me as fantastic that they would suggest not only that these mechanisms support memory encoding, but actual functional logic signal processing. But what do I know.
When I saw your comment, it was buried under the fold with a score of 1; hence my call to moderators. I thought it deserved much higher prominence, and now I see others did too.
Regards,
-dZ.
Somebody, quick, mod this post Informational!!
dZ.
P.S. Thanks for the great overview and insightful perspective.
I have to stop reading after the first few paragraphs.
Is there a Microsoft Manual of Grammar available?
As someone who got stuck for a while coding in Delphi.Net 1.1 some time ago, I can attest that years of experience in Delphi and other compiled languages did not prepare me for the clusterfsck that was the .Net wrapper to the language.
It was so stilted, and the code felt just wrong. It still haunts me in my nightmares.
To me it is rather obvious that the .Net framework was designed to be used with C#, and that contorting any other language to conform to the framework is a bit like nailing a tack to the wall with your head: it'll probably work, but it will hurt like hell, and you'll leave behind a bloody mess.
-dZ.
That may be true, I have no idea. My comment was in response to the parent post regarding application errors and impatient users.
Mark me off-topic.
If the software requires Swiss-precision timing and/or extensive and convoluted steps in order to get it to work, then it very much "has errors." Double that for a Web page.
-dZ.
Because, love them or hate them, Microsoft is a software company trying to apply engineering to diverse software problems.
Ultimately, they make their money through the sale of products, so their interests tend to align with their users'.
Google, on the other hand is an advertising company trying to apply engineering to, um, data mining algorithms; and acquiring start-up companies for the purpose of increasing data collection and improve the targeting of ads.
Ultimately, they make their money through better and more targeted advertising, so their interests tend to align with those of advertisers'.
-dZ.
They didn't miss that opportunity, they dismissed it. They went on the path of becoming a search appliance, back when they were trying to find a stable business model. The 20% was also a way to fund research and development into new or orthogonal markets, and it made their employees happy to boot.
For a while it all looked good and the strategy seemed solid.
Then the advertising money started flooding their profit margins. All of a sudden, it became clear which direction they should go.
From that day on, they became a one-trick pony.
It's not that they sucked at everything else, it's that nothing that they have produced so far could match the rate at which advertising fills their coffers. There was no way to return to being an engineering or technology company if by doing so they had to lower their profits.
It didn't matter if they could succeed, they needed to make more money!
Eventually, this brutal mentality trickled down to the engineers and the rest of the crew. It's clear to most people now that, for all their perks and occasional technical brilliance, Google is no longer a technology company.
-dZ.
This response to your worthless online comment is likewise a waste of resources.
However, I think it captures rather well the intelligence of the reader.
Oh, wait, what?
Nice post, Eldavojohn; very insightful. I also agree.
I will point out one error, though:
I believe you meant "with little regard for others," which actually means with quite some measure of disregard.
Cheers! and thanks for the thoughtful comment.
-dZ.
That's because, while everybody else was going Web-two-point-oh-rounded-corners-kumbaya, Slashdot looked like a remnant from Geocities.
Slashdot has always been ugly and pedestrian, if extremely functional.
-dZ.
That's precisely what the video and some people in this forum are advocating.
The idea that code is this arcane, magical entity that cannot be understood beforehand and that needs to be traced, step-by-step, in your head or on the computer until its purpose is gleaned by discovery; is in fact risible.
Sure, computers are a better tool to do this than our own brains. That's not the argument here. Neither it is that an interactive debugger is not useful.
The argument is that it is fundamentally wrong to write code naively without properly understanding what it was doing to begin with. And a need to iterate through it interactively--not to find errors or omissions in its function, but to understand what it is doing--is irresponsible and reveals gross inexperience.
The debugger is a tool that helps you find errors in your program, and these indeed happen. It is not, however, intended to be a substitute for proper design, thought, or understanding of the problems you are trying to solve.
-dZ.
So now you show how little you know. The correct approach is the one "similar to logic and math on abstract objects" than to physics, precisely because programming is applied mathematics.
The scientific method is used for physics to discover and understand the world around you, i.e. the model.
Programming is the implementation of a model that solves a problem, one that by all measures should have been discovered and understood already. This is indeed done from abstract concepts and first principles.
If you are discovering and learning how to solve a business problem while typing away source code, then you are in the wrong trade and your code is doomed to fail.
-dZ.
I think the point is that finding a CPU or compiler bug is a more rare occurrence than finding a bug in your own higher-level code.
This is why people roll their eyes at you when you claim to have found a compiler bug. It's not a belief that such a thing is impossible. It's just that you must prove exhaustively that you have accounted for and discarded all other possibilities.
The same people will admire you and sing your praises when you show them thorough proof of your discovery.
-dZ.
Ah... 1995. I remember back then talking to my girlfriend (now wife) about how things "used to be back in the day."
One of the things I noted even then was the reliance on the Internet. I recall stating something like, "back in the 80s, I could spend an entire stretch of days at a time, stuck in my room writing stupid home-brewed programs in my Commodore 64, with very little sleep; I could always find something to do with that little machine without any network connectivity or external communications. Nowadays, I sit at my computer desk, and if the 'Net is down, can't check my e-mail, can't use my browser, can't log into the BBS... it's useless, and I turn the fucker off."
Today, if my cable-modem connection goes down, I just grab my iPad and play Bejeweled or some other game, watch a movie, or catch up on my reading.
My, how times change.
It is not that I've grown less reliant on my Internet connection. I think it's just that modern machines are much more pleasant to use for many other use cases.
You see, in the 80s I was discovering computers and every silly "GOTO 10" statement was an adventure. In the 90s, I was exploring the vast frontiers of the Internet, and while using a PC was a fscking pain, I endured it for the value of the network and communications.
Now, the device is not a pain to use, and I use it for many other things than just exploring the Internet or communicating with others. This is the actual progress of our technologies: Convivial machines to fit human lifestyles.
It is amazing what we have now. I truly feel like I live in The Future.
-dZ.
The setting in question is, from within the "Privacy" tab in the Safari Preferences window:
By default, the first one is selected. What it does is make Safari reject any cookie not originating from the domain of the currently opened page URL. This includes requests from iframes, images, and any other resource requested from an external domain.
That's it. By design, this should prevent, say, a cookie from "webtrendslive.com" or from "googleanalytics.com" unless the user is at a site hosted by those domains.
This is a good default, for this would be what most users would be expecting. The assumption is that any resource hosted on an external URI is most likely for advertising and tracking purposes (which, as it turns out, is true).
It would be understandable if the work-around was applied to a web site that depended on third-party resources which required the setting of cookies from said party in order to function--admittedly a rare edge case.
However, it's the advertisers themselves that are working around this feature; and this shows their intent on ignoring user preferences.
The user can always change it to "Never" and receive cookies from any, all, and sundry.
-dZ.
And there is another insightful point that you are missing. There is nothing magical about "business tools." Humans are humans and have certain requirements and methods for interacting with machines. These interface can coincide whether you're applying them in a tool for business or leisure.
The same note-taking application that I use for capturing some random thing I saw on the TV, can support my creative outbursts at the office.
The e-mail and communications applications I use to chat with friends and the browser I use to look-up what movie to watch tonight, do not suddenly stop being useful when I apply them to my office communications or research.
The iPad and the iPhone offer an extensible platform that starts with a very usable interface to the machine's capabilities. The user feels comfortable with this environment and could be more productive if applied to other uses such as business work-flows.
For this, many developers of real business tools are using it for office and productivity applications.
So, you were very right, it is all accidental or incidental to making a good consumer product.
However, you missed the forest by the trees. This is precisely why it eventually is adopted to other purposes--because it is such a good consumer product, and humans are the same and operate with machines in the same way whether they do it for fun or profit.
-dZ.
Actually, that's how it works. Yes, where I worked executives, managers and employees started using whatever they wanted, mainly iPhones and iPads. This was in spite of IT's resistance, which then was forced to adapt.
Those executives, managers, and employees were the ones attempting to try to use the devices as a business tool; IT was resisting because the adopted standard for years were different. Not only that, there was a push to evaluate other seemingly "business friendly" platforms like MS tablets of yore, or even BlackBerry or HP tablet devices. Those efforts did not bare fruit in the face of employees doing real work on Apple devices and clamoring for support.
I hear this is how it started in many other work places.
-dZ.
I understand your frustration. It sucks and sometimes it hurts, but you must trust me when I say that it does get better.
I know how you feel, I've been there myself. Eventually, you'll just realize that it is really not all that important that your old perception towards something as insignificant as a technology product, was wrong; and that arguing against it is not only futile, but emotionally destructive.
It truly is not the end of the world, and with time you'll come to accept it and recover from it.
Peace, my friend, and good luck.
-dZ.
You didn't get it, did you?
Apple cares not a hoot for the IT manager trying to integrate Apple devices into their infrastructure. They care about the end user of such devices, whom feel empowered and more productive using them.
So this integration is not happening "in spite of Apple," but precisely because Apple devices help the end users be more productive. The integration is the result of this adoption.
You can say that the integration is not Apple's focus. They don't care if you figure out how to integrate the devices into the corporate work-flow or infrastructure--because consumers are buying using the devices, and therefore it's happening whether you integrate or not.
-dZ.
Not only that, but Microsoft themselves have been there before. At the start of the decade, they were the ones pushing for "tablet computing" as a work-enabling tool.
I'm sure you know how that ended.
-dZ.