Worse, an increasing proportion of what's being written is on electronic media, known for its longevity in neither technology nor formatting. http://en.wikipedia.org/wiki/Digital_dark_age
The claim that history has no relevance has a long history of being proven wrong. Superficials change. The basics don't: people die, and information decays.
I used to think gamification was an interesting idea which might lead somewhere: especially when dealt with as kudos, since monetary rewards so easily can lead to really counterproductive behaviours. Then I realized it had already been tried: in Soviet Russia, no less, under names such as 'socialist competition'. http://www.kmjn.org/notes/soviet_gamification.html
Now, the fact that the idea is not new is not an automatic rejection of the idea; but its history should be carefully considered to avoid replicating failure. Can gamification be managed so as to 1) reward both short and long term objectives, 2) avoid acting at cross purposes to monetary rewards 3) make it serious enough to affect sufficient numbers of employees, and 4) still be fun? I don't think I'm smart enough to setup such a system. Good luck to those who try: it'll be interesting to see any results.
What's worse, human vision is still limited to about 10 million nuances and can't even take advantage of 24 bits. Time for an upgrade!
I disagree. Do you really believe that human vision is limited to seeing just a paltry 256 values for the entire range of light to dark? Not even close.
That's not how RGB works. It's rather far from an accurate model of human visual perception, though, so it's not really the bit depth per se you should be bemoaning, but rather the colour model itself. Our visual colour bandwidth remains constrained to a smidgen below 24 bits, nonetheless. And let's not even start to discuss the horrible lack of resolution outside the yellow spot which forces our eyes to saccade constantly -- what a kludge!
I love the column on video, where the 1995 columns says "24-bit", and the 2012 column...oh wait, we're still 24-bit. Everything else has advanced by several orders of magnitude, but we're still limited to just 8 bits per color channel (RGB = 24 bits in total) going out over the DVI cable (and the display itself). Sure, now you can drop a few G's on a 10-bit (30 total) monitor (if your software can even make use of it), but it's kind of sad that progress has been so slow.
What's worse, human vision is still limited to about 10 million nuances and can't even take advantage of 24 bits. Time for an upgrade!
I've seen mainframes used at Insurance companies and Banks, but the rest of the world seems to favour the the cloud ways of Elastic Cloud and what not.
I've heard mainframes have high IO thoroughput, but what about their equivalent Cloud solutions and scalability especially?
Thanks.
Latency. Confidentiality. Reliability. But most of all: sunk costs and proprietary software embodying key business knowledge. Replacing mainframes requires a large enterprise to start not only major software procurement or development (or both, as in ERP), but also business process reengineering... none of which is particularly fun, cheap or in themselves something that helps capture greater market share.
Cool, I thought, some prior art. Then I actually looked: Workplace Shell is about traditional GUI applications programming, not shell scripting, and at least from your link did nothing to even support passing objects around in a pipes-and-filters design (much less propose object based pipes-and-filters as the primary design principle). Nope, until further notice, Redmond is still officially innovative.
Again, try it out. Text manipulation has its strengths, but the more tools you are able to use, the more problems you are able to solve.
I sit corrected. This is great news -- I think I checked last autumn.
What irregularities? Could you give some examples, please. Honest question here - I'm not claiming that PowerShell is perfectly regular and I would appreciate any insights.
Sorry, I may just be rumour-mongering. Something I read over at StackOverflow, I think... and can't find it now. Confession: I've mostly been admiring the idea of PS rather than cutting my teeth on any serious hacking around.
Half of the power in Bash is the ability of the various commands to not only output to text but to take their input as common text from standard in or a file. Usually the text is passed around and filtered between several discrete commands before whatever it is you are doing is accomplished. In PowerShell, can text be passed around, piped, grepped, sorted, etc. as well as in Bash?
As I said, take a look at it. With three decades of use and development behind it, I'd expect Unix to have several tools which haven't been replicated for PS. Yet. But there's nothing can't be done (since everything also is text), and quite a number of things that can be done a great deal more easily and robustly, thanks to being one level of abstraction higher than raw text.
Take a look at Windows PowerShell. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object'
The big advantage of the Unix philosophy is that plain text is human readable. 'Objects' have this terrible problem that you always need a specific program to read and write them.
...
I don't think powershell offers any advantage over the way Unix has been working for forty years.
You know, check it out. Everything actually has a text representation as well, which anyone who doesn't understand a particular object-with-values can drop back to. Despite what you may think, sometimes Redmond actually can innovate, and do it well.
Well,,, apart from the language still having no formal specification and (therefore?) some unfortunate irregularities in the implementation. That's one thing they really didn't have to copy off other shell languages!
So why is this not widely known? Because people tend to not look beyond the headline spin, the parent post being a good example thereof. But also because industry-funded studies tend to generate biased results http://www.seattlemag.com/article/nerd-report/nerd-report which are then touted as "proof" that there is no ill effect.
The rule of thumb is that the velocity at aphelion for a parabolic trajectory is Sqrt(2) times the circular orbital velocity. Check e.g. Wikipedia, the fount of all that is true and notable...:-)
To escape the solar system from Earth, you need dv=42km/s, whereas the Earth's orbital velocity is 30km/s. Unless you can get dv from flybys, you're looking at pretty much same ballpark in terms of delta-v to go into the Sun as to leave the solar system starting from Earth.
...except that we could, you know, actually fire it off in the direction the Earth is already moving, at just 12 km/s delta-vee. Much cheaper. If still horribly expensive with chemical propulsion systems.
Errrr... Java debuted in 1995, and 2000 saw J2SE 1.3... it's almost 2011 now, does that count as a decade?
It most certainly does. C/C++, Java and C# are going to be around for quite a while yet: the odds are favourable for any language that has survived for long enough, and in which a sufficient number of people are capable if not proficient, whatever the technical merits of the languages in question (which shouldn't be scorned).
I was attempting being facetious about FuckingNickName's (what an elegant nick!) assertion that newer (or, in his/her/its terms, 'more high level') languages are always the better option. In engineering, you always have to deal with tradeoffs. Language elegance or expressiveness is far from the only factor to consider.
Meanwhile, people doing real low-level or time-critical work use assembler/C/C++, and people doing real high-level work don't go for a primitive imperative language which looks like C/C++ with training wheels.
Riiiiight. I wonder, where do people go who want to be able to find people to maintain their software for, say, a decade? Except for COBOL, of course... and that's going to get seriously expensive. (God, I really wish I was kidding about COBOL.)
Wake me up when one of the 'real high level' languages (whichever is your personal poison) has found a significant market and mind share. Meanwhile, I'll stick with whatever language fits the problem, instead of fitting the problem to my favourite language.
So if someone says "___ costs too much", "voila - cost is now zero. Next objection?"
Um... we just don't have the manpower to support any device at the drop of a pin, and even if we got the money to hire or subcontract them, we'd run into other problems (finding the right skills, keeping the organization manageable, predicting popular devices before the fit hits the shan). Sorry if I misapprehend your point, but I just don't see how you can handwave those costs away. It's not just a question of savings: it's a question of where we can get the best value for time and money spent.
My prediction for what it's worth: company IT departments insisting on controlling exactly what devices are used to deal with company business will find themselves sidelined and either restructured or outsourced, in favour of alternate solution providers focusing on the real issues. The problem isn't what exact hardware people are using. The problem is ensuring they are able to use it (with reasonable IT support costs) to access company information (with reasonable guarantees of confidentiality). Speccing the model numbers they are allowed to purchase was the only viable answer ten or even five years back, but isn't enough when demand and technology keeps changing rapidly.
Actually for us it's a business concern. We were evaluating whether or not to allow Android device to connect to our corporate intranet and decided against it for that very reason./.../
With the iPhone, we can force users to upgrade to the latest OS version, and give them a time window to comply./.../
Yes, we (as an internal IT company) used to think along those lines.. but to us, the iOS family itself is fast becoming the last straw to the perimeter security model, where we controlled what devices are permitted inside, and trusted them completely. This isn't going to fly much longer. First of all, without infeasible expansion in IT staffing, we are unable to match the quick evolution in the mobile segment: count on no more than 18 months' lifecycles for mobile devices, before being replaced by something which would have to be re-integrated with our standards and network security. Second, the devices aren't company provided any more: the ugly 'consumerization' word is rearing its equally ugly head. People (for now, top management and early adopters) want to bring their own devices, be they smartphones or laptops, to work. We've been fighting a holding action against that trend, mostly on the grounds of security, and to some extent supportability, but few of us think that battle can be ultimately won.
Instead of restricting end users' devices to perpetually out-dated models, our integration, provisioning and security model is tenatively moving towards focusing on their interfaces (communications protocols, information standards), and reducing trust towards devices. For the near future, we'll have to restrict access to confidential information to company-approved devices, and setup network malware and DoS protection as part of the open segments of our internal company networks. In the mid-to-longer term (2+ years), we hope to see increased maturity in virtualization, allowing us to push out a trusted virtual desktop/smartphone image, to which users can switch when sensitive information has to be processed. You can understand our happiness over this announcement, happening a bit faster than we were expecting (even if they aren't at the product stage yet).
and any programmer will be guilty of most of them if put under sufficient time pressure.
"Any programmer" can mess up implementation if he is in a hurry. Bad design is a sign of stupidity and ignorance.
Also, as a wise man observed, housebreaking a pet by killing the puppy the first time it pees on the rug is a bit inefficient.
There are huge organizations called "schools" made specifically for the purpose of educating people. Once someone works as a programmer, it's too late to tolerate idiotic crap from him.
OK... I'll just... back away quietly. Here, have some candy and coffee. Would it bother you terribly to stop pointing that bazooka at me?
The only common mistake I see is not firing the programmer who makes any of those "common" mistakes. There is absolutely no reason for any of this shit to be "common" unless "programmers" who make them are uneducated dumbasses who should never be allowed anywhere near software development.
Hardly these mistakes, surely? Most of these 'mistakes' are judgment calls, and any programmer will be guilty of most of them if put under sufficient time pressure.
Also, as a wise man observed, housebreaking a pet by killing the puppy the first time it pees on the rug is a bit inefficient.
Slashdot Mirror
But most of what's printed right now won't last more than a hundred years since the paper will crumble. http://www.loc.gov/preservation/resources/care/deterioratebrochure.html
Worse, an increasing proportion of what's being written is on electronic media, known for its longevity in neither technology nor formatting. http://en.wikipedia.org/wiki/Digital_dark_age
The claim that history has no relevance has a long history of being proven wrong. Superficials change. The basics don't: people die, and information decays.
Really? I believed India seceded from the British Empire, but remained in the Commonwealth.
don't the put the laptop in checkered bags easy way for it to get lost, broken, or stolen
Yep, the lst plaid suitcase I had got stomped on by an irate baggage handler. Apparently, they prefer stripes.
I used to think gamification was an interesting idea which might lead somewhere: especially when dealt with as kudos, since monetary rewards so easily can lead to really counterproductive behaviours. Then I realized it had already been tried: in Soviet Russia, no less, under names such as 'socialist competition'. http://www.kmjn.org/notes/soviet_gamification.html
Now, the fact that the idea is not new is not an automatic rejection of the idea; but its history should be carefully considered to avoid replicating failure. Can gamification be managed so as to 1) reward both short and long term objectives, 2) avoid acting at cross purposes to monetary rewards 3) make it serious enough to affect sufficient numbers of employees, and 4) still be fun? I don't think I'm smart enough to setup such a system. Good luck to those who try: it'll be interesting to see any results.
[Citation needed]
Yes.
What's worse, human vision is still limited to about 10 million nuances and can't even take advantage of 24 bits. Time for an upgrade!
I disagree. Do you really believe that human vision is limited to seeing just a paltry 256 values for the entire range of light to dark? Not even close.
That's not how RGB works. It's rather far from an accurate model of human visual perception, though, so it's not really the bit depth per se you should be bemoaning, but rather the colour model itself. Our visual colour bandwidth remains constrained to a smidgen below 24 bits, nonetheless. And let's not even start to discuss the horrible lack of resolution outside the yellow spot which forces our eyes to saccade constantly -- what a kludge!
I love the column on video, where the 1995 columns says "24-bit", and the 2012 column...oh wait, we're still 24-bit. Everything else has advanced by several orders of magnitude, but we're still limited to just 8 bits per color channel (RGB = 24 bits in total) going out over the DVI cable (and the display itself). Sure, now you can drop a few G's on a 10-bit (30 total) monitor (if your software can even make use of it), but it's kind of sad that progress has been so slow.
What's worse, human vision is still limited to about 10 million nuances and can't even take advantage of 24 bits. Time for an upgrade!
I've seen mainframes used at Insurance companies and Banks, but the rest of the world seems to favour the the cloud ways of Elastic Cloud and what not.
I've heard mainframes have high IO thoroughput, but what about their equivalent Cloud solutions and scalability especially?
Thanks.
Latency. Confidentiality. Reliability. But most of all: sunk costs and proprietary software embodying key business knowledge. Replacing mainframes requires a large enterprise to start not only major software procurement or development (or both, as in ERP), but also business process reengineering... none of which is particularly fun, cheap or in themselves something that helps capture greater market share.
Businesses *did* use RPG.
Past tense? Wake up and smell the mainframe...
Despite what you may think, sometimes Redmond actually can innovate, and do it well.
Trouble is Redmond didn't innovate. Powershell is a weak copy of IBM OS/2 Workplace Shell / System Object Model (SOM).
See here: http://www.warpspeed.com.au/cgi-bin/inf2html.cmd?..%5Chtml%5Cbook%5CToolkt40%5CWPSGUIDE.INFl
Enjoy,
Cool, I thought, some prior art. Then I actually looked: Workplace Shell is about traditional GUI applications programming, not shell scripting, and at least from your link did nothing to even support passing objects around in a pipes-and-filters design (much less propose object based pipes-and-filters as the primary design principle). Nope, until further notice, Redmond is still officially innovative.
Again, try it out. Text manipulation has its strengths, but the more tools you are able to use, the more problems you are able to solve.
The language specification: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=509b77d0-5e5f-4194-a2d0-61648abfd093
I sit corrected. This is great news -- I think I checked last autumn.
What irregularities? Could you give some examples, please. Honest question here - I'm not claiming that PowerShell is perfectly regular and I would appreciate any insights.
Sorry, I may just be rumour-mongering. Something I read over at StackOverflow, I think... and can't find it now. Confession: I've mostly been admiring the idea of PS rather than cutting my teeth on any serious hacking around.
Half of the power in Bash is the ability of the various commands to not only output to text but to take their input as common text from standard in or a file. Usually the text is passed around and filtered between several discrete commands before whatever it is you are doing is accomplished. In PowerShell, can text be passed around, piped, grepped, sorted, etc. as well as in Bash?
As I said, take a look at it. With three decades of use and development behind it, I'd expect Unix to have several tools which haven't been replicated for PS. Yet. But there's nothing can't be done (since everything also is text), and quite a number of things that can be done a great deal more easily and robustly, thanks to being one level of abstraction higher than raw text.
A good idea is a good idea, no matter its source.
Take a look at Windows PowerShell. Instead of the UNIX 'everything is a file' philosophy, it says 'everything is an object'
The big advantage of the Unix philosophy is that plain text is human readable. 'Objects' have this terrible problem that you always need a specific program to read and write them.
...
I don't think powershell offers any advantage over the way Unix has been working for forty years.
You know, check it out. Everything actually has a text representation as well, which anyone who doesn't understand a particular object-with-values can drop back to. Despite what you may think, sometimes Redmond actually can innovate, and do it well.
Well,,, apart from the language still having no formal specification and (therefore?) some unfortunate irregularities in the implementation. That's one thing they really didn't have to copy off other shell languages!
There is plenty of evidence for mutagenic and other negative effects of radio-frequency and microwave fields. Just a small sample: http://www.rrjournal.org/doi/abs/10.2307/3579911 http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6T2D-4G7NFGG-1&_user=10&_coverDate=06%2F06%2F2005&_rdoc=1&_fmt=high&_orig=browse&_origin=browse&_sort=d&view=c&_acct=C000050221&_version=1&_urlVersion=0&_userid=10&md5=f82e85c25e8d4446ef498e2a2d93c83c http://www.ncbi.nlm.nih.gov/pubmed/8627134
So why is this not widely known? Because people tend to not look beyond the headline spin, the parent post being a good example thereof. But also because industry-funded studies tend to generate biased results http://www.seattlemag.com/article/nerd-report/nerd-report which are then touted as "proof" that there is no ill effect.
Obligatory xkcd.
The rule of thumb is that the velocity at aphelion for a parabolic trajectory is Sqrt(2) times the circular orbital velocity. Check e.g. Wikipedia, the fount of all that is true and notable... :-)
To escape the solar system from Earth, you need dv=42km/s, whereas the Earth's orbital velocity is 30km/s. Unless you can get dv from flybys, you're looking at pretty much same ballpark in terms of delta-v to go into the Sun as to leave the solar system starting from Earth.
...except that we could, you know, actually fire it off in the direction the Earth is already moving, at just 12 km/s delta-vee. Much cheaper. If still horribly expensive with chemical propulsion systems.
I have one word that discredits everything you just said: Apple
What an extraordinarily silly comment! Were you trying for humour?
Errrr... Java debuted in 1995, and 2000 saw J2SE 1.3... it's almost 2011 now, does that count as a decade?
It most certainly does. C/C++, Java and C# are going to be around for quite a while yet: the odds are favourable for any language that has survived for long enough, and in which a sufficient number of people are capable if not proficient, whatever the technical merits of the languages in question (which shouldn't be scorned).
I was attempting being facetious about FuckingNickName's (what an elegant nick!) assertion that newer (or, in his/her/its terms, 'more high level') languages are always the better option. In engineering, you always have to deal with tradeoffs. Language elegance or expressiveness is far from the only factor to consider.
Meanwhile, people doing real low-level or time-critical work use assembler/C/C++, and people doing real high-level work don't go for a primitive imperative language which looks like C/C++ with training wheels.
Riiiiight. I wonder, where do people go who want to be able to find people to maintain their software for, say, a decade? Except for COBOL, of course... and that's going to get seriously expensive. (God, I really wish I was kidding about COBOL.)
Wake me up when one of the 'real high level' languages (whichever is your personal poison) has found a significant market and mind share. Meanwhile, I'll stick with whatever language fits the problem, instead of fitting the problem to my favourite language.
So if someone says "___ costs too much", "voila - cost is now zero. Next objection?"
Um... we just don't have the manpower to support any device at the drop of a pin, and even if we got the money to hire or subcontract them, we'd run into other problems (finding the right skills, keeping the organization manageable, predicting popular devices before the fit hits the shan). Sorry if I misapprehend your point, but I just don't see how you can handwave those costs away. It's not just a question of savings: it's a question of where we can get the best value for time and money spent.
My prediction for what it's worth: company IT departments insisting on controlling exactly what devices are used to deal with company business will find themselves sidelined and either restructured or outsourced, in favour of alternate solution providers focusing on the real issues. The problem isn't what exact hardware people are using. The problem is ensuring they are able to use it (with reasonable IT support costs) to access company information (with reasonable guarantees of confidentiality). Speccing the model numbers they are allowed to purchase was the only viable answer ten or even five years back, but isn't enough when demand and technology keeps changing rapidly.
Actually for us it's a business concern. We were evaluating whether or not to allow Android device to connect to our corporate intranet and decided against it for that very reason./.../
With the iPhone, we can force users to upgrade to the latest OS version, and give them a time window to comply. /.../
Yes, we (as an internal IT company) used to think along those lines.. but to us, the iOS family itself is fast becoming the last straw to the perimeter security model, where we controlled what devices are permitted inside, and trusted them completely. This isn't going to fly much longer. First of all, without infeasible expansion in IT staffing, we are unable to match the quick evolution in the mobile segment: count on no more than 18 months' lifecycles for mobile devices, before being replaced by something which would have to be re-integrated with our standards and network security. Second, the devices aren't company provided any more: the ugly 'consumerization' word is rearing its equally ugly head. People (for now, top management and early adopters) want to bring their own devices, be they smartphones or laptops, to work. We've been fighting a holding action against that trend, mostly on the grounds of security, and to some extent supportability, but few of us think that battle can be ultimately won.
Instead of restricting end users' devices to perpetually out-dated models, our integration, provisioning and security model is tenatively moving towards focusing on their interfaces (communications protocols, information standards), and reducing trust towards devices. For the near future, we'll have to restrict access to confidential information to company-approved devices, and setup network malware and DoS protection as part of the open segments of our internal company networks. In the mid-to-longer term (2+ years), we hope to see increased maturity in virtualization, allowing us to push out a trusted virtual desktop/smartphone image, to which users can switch when sensitive information has to be processed. You can understand our happiness over this announcement, happening a bit faster than we were expecting (even if they aren't at the product stage yet).
Most of these 'mistakes' are judgment calls,
Everything a programmer does is a judgment call.
and any programmer will be guilty of most of them if put under sufficient time pressure.
"Any programmer" can mess up implementation if he is in a hurry. Bad design is a sign of stupidity and ignorance.
Also, as a wise man observed, housebreaking a pet by killing the puppy the first time it pees on the rug is a bit inefficient.
There are huge organizations called "schools" made specifically for the purpose of educating people. Once someone works as a programmer, it's too late to tolerate idiotic crap from him.
OK... I'll just... back away quietly. Here, have some candy and coffee. Would it bother you terribly to stop pointing that bazooka at me?
The only common mistake I see is not firing the programmer who makes any of those "common" mistakes. There is absolutely no reason for any of this shit to be "common" unless "programmers" who make them are uneducated dumbasses who should never be allowed anywhere near software development.
Hardly these mistakes, surely? Most of these 'mistakes' are judgment calls, and any programmer will be guilty of most of them if put under sufficient time pressure.
Also, as a wise man observed, housebreaking a pet by killing the puppy the first time it pees on the rug is a bit inefficient.
8 million tons? You'd only need 6400 Saturn V to get all the components into orbit for construction. Ooof.
Oh, no: you build it on the ground, then launch it from a country (or continent!) you don't particularly like...