"Too often I have seen programmers assuming infinite precision in their real numbers and similar errors that someone who has dealt with the reality of bits and bytes would never do."
These are errors on the part of the computer. The user wants to represent 1/3. He cares not why the computer cannot do it. That's the computer's fault, and it is easily remedied.
Your 'easy' solution is to presumably use an infinite precision data type - something significantly slower and more data intensive than a real as handled by the (co-)processor. The thing is, the programmer needs to know which of these he should use, which he will only learn, if he's gotten "down and dirty" in assembler. My point stands.
I'm not sure I entirely agree with that. It makes them think in terms of "how" instead of "what". In non-trivial software design, it's usually best to think about the general requirements or goals first instead of the mechanics of carrying out those requirements.
I think it is a good thing that they learn about the "how" before they learn the "what". Too often I have seen programmers assuming infinite precision in their real numbers and similar errors that someone who has dealt with the reality of bits and bytes would never do.
If you are learning about anything new, be it karate or knitting or playing guitar, you learn the basics first - the block, the pearl, the chord - before you advance to "non-trivial" things - combinations, designing a sweater, the riff. Why should it be any different in making good software?
They'll be cutting private internet access for one day, right?
They make contradictory claims about why, but in the end, it is a one day inconvenience for internet users.
The most sinister reason I can think of for them wanting to shut it down is to prevent riots caused by posts alleging election improprieties (real or imagined). Really sinister.
I don't know about all you other hackers out there, but over my thirty years of experience, I have probably developed over a hundred ideas that would have been patentable under todays standards, maybe hundreds if you sink to the "one click" level. I do not have a single patent. If I had taken time to develop a patent or patents on one idea, it would have taken months and screwed up my creative processes for a good long time. In the small company I work for, that would be fatal.
I live and usually work close to home, but a couple times a month I have to go to the company central, 300 Km away. I usually leave around 6:00 am, so that I can arrive in time to do useful work and talk to colleagues.
Before laptops, I would pack my workstation, including monitor, keyboard, mouse, cables and anything else I was working with at the time into my company car and drive. Theoretically I could have left the monitor - I was told to and did so at first - but a single incident of there not being a promised monitor available cured me of that. Note that there were also stairs to climb both at start and destination. When I arrived, I was both mentally stressed out from driving and physically hot and sweaty (even in Winter) from just dragging 50 Kilos of equipment up stairs. I would need 20 minutes or more just to recover from the trip.
Now I simply pack up my laptop and perhaps a suitcase and take the train. If I'm tired, then I can rest on the train. If I am alert, then I can work. I no longer have a company car, but I consider it a plus because it translated directly into a raise.
It even saves the company money directly: where I live, the train trip is cheaper than the gas + wear and tear on the company car it would cost.
The articles number one point "Battery Life Still Bombs" is ludicrous: (some battery life) > (no battery life). Battery life is not the major reason for me to have a laptop, but it is rare for my batteries to go out on me during the trip (with changing trains, I normally have about two hours of 'up' time on a three hour trip).
Sure laptops are still slower and less powerful than a workstation of the same cost - but todays laptop is still way ahead of a five year old workstation and they're getting more powerful and cheaper all the time.
Perhaps the folks involved are simply a bit uninformed and need a tiny bit of information, to whit:
It has been standard practice for over twenty years to count the number of interactions a user must make to perform a given action as a measure of the ease of use of an interface. After the mouse became standard, this measure was given the handy name of 'click counting'.
Who can read that, and then say "one click" is not the obvious end-point?
Re:Application to "OOXML is an open standard" myth
on
Why Myths Persist
·
· Score: 1
The thing to do here is not to negate the original myth, but to submit a juicy new story to the rumor mill (whether true or myth) that is incompatible with the original myth or at least with its aim:
"OOXML sucks big time! It's just a repackaged DOC format!"
"Saddam Hussein and Osama Bin Laden hated each other and would have killed each other if they could."
> The compiler then assumes that something(a) can be safely executed in parallel for every element in the list.
That is trivial to implement without changing a language, e.g. for C/C++ just pass function and list of parameters to be executed in parallel to a function which starts a thread for each:
StartParallelThreads(something, list);
The real problem is shared resources, i.e. where those "something(a)" do come into conflict with one another.
> Java changed that. Basically every programmer who has had a basic Java course or worked through an introductory Java book has learned the basics of threading and written several multi-threaded programs.
Odd that: the one programmer in my shop who started out as a Java only programmer, has the weakest multithreading skills.
I've done a lot of multithreaded programming over the past 20 years, slowly progressing from a rare occurrence to pretty much my daily diet. I work in a shop with 6 full time programmers, plus several externals. At first I was the only one who could do any multithreaded programming, having learned the principles in college some 25 years ago (*ouch* I'm old!). Now others are producing reasonable multithreaded code, but I'm still the one they run to when there's a problem.
Looking at the proposals for switching languages, they just shift the problem around (as another poster has already mentioned). The only thing new that might be useful is the idea of "Guards" from Haskell (for why, see below). But you don't need a new programming language to implement that, with a little imagination you can build it into a C++ library.
In my experience, 99% of the problems are due to two problems: overlooked shared resources and deadlocks. An example of the first problem might be when two threads are pushing/popping from the same queue, causing duplicates or skips. An example of the second would be thread A has resource X and is waiting for resource Y, while thread B has resource Y and is waiting for resource X. Guards could possibly make it easier to avoid some forms of deadlock by making it easier to acquire multiple resources simultaneously with less risk of deadlock. I think I have a new library to go code now...;-)
Slashdot Mirror
"Too often I have seen programmers assuming infinite precision in their real numbers and similar errors that someone who has dealt with the reality of bits and bytes would never do."
These are errors on the part of the computer. The user wants to represent 1/3. He cares not why the computer cannot do it. That's the computer's fault, and it is easily remedied.
Your 'easy' solution is to presumably use an infinite precision data type - something significantly slower and more data intensive than a real as handled by the (co-)processor. The thing is, the programmer needs to know which of these he should use, which he will only learn, if he's gotten "down and dirty" in assembler. My point stands.
I'm not sure I entirely agree with that. It makes them think in terms of "how" instead of "what". In non-trivial software design, it's usually best to think about the general requirements or goals first instead of the mechanics of carrying out those requirements.
I think it is a good thing that they learn about the "how" before they learn the "what". Too often I have seen programmers assuming infinite precision in their real numbers and similar errors that someone who has dealt with the reality of bits and bytes would never do.
If you are learning about anything new, be it karate or knitting or playing guitar, you learn the basics first - the block, the pearl, the chord - before you advance to "non-trivial" things - combinations, designing a sweater, the riff. Why should it be any different in making good software?
They make contradictory claims about why, but in the end, it is a one day inconvenience for internet users. The most sinister reason I can think of for them wanting to shut it down is to prevent riots caused by posts alleging election improprieties (real or imagined). Really sinister.
Am I missing something? What's the big deal?
I don't know about all you other hackers out there, but over my thirty years of experience, I have probably developed over a hundred ideas that would have been patentable under todays standards, maybe hundreds if you sink to the "one click" level. I do not have a single patent. If I had taken time to develop a patent or patents on one idea, it would have taken months and screwed up my creative processes for a good long time. In the small company I work for, that would be fatal.
I live and usually work close to home, but a couple times a month I have to go to the company central, 300 Km away. I usually leave around 6:00 am, so that I can arrive in time to do useful work and talk to colleagues.
Before laptops, I would pack my workstation, including monitor, keyboard, mouse, cables and anything else I was working with at the time into my company car and drive. Theoretically I could have left the monitor - I was told to and did so at first - but a single incident of there not being a promised monitor available cured me of that. Note that there were also stairs to climb both at start and destination. When I arrived, I was both mentally stressed out from driving and physically hot and sweaty (even in Winter) from just dragging 50 Kilos of equipment up stairs. I would need 20 minutes or more just to recover from the trip.
Now I simply pack up my laptop and perhaps a suitcase and take the train. If I'm tired, then I can rest on the train. If I am alert, then I can work. I no longer have a company car, but I consider it a plus because it translated directly into a raise.
It even saves the company money directly: where I live, the train trip is cheaper than the gas + wear and tear on the company car it would cost.
The articles number one point "Battery Life Still Bombs" is ludicrous: (some battery life) > (no battery life). Battery life is not the major reason for me to have a laptop, but it is rare for my batteries to go out on me during the trip (with changing trains, I normally have about two hours of 'up' time on a three hour trip).
Sure laptops are still slower and less powerful than a workstation of the same cost - but todays laptop is still way ahead of a five year old workstation and they're getting more powerful and cheaper all the time.
The people we need to convince are the PTO judges. If they are marketing people, we're sunk before we've started!
Hovering then becomes the action instead of clicking - same "click count" - despite no button pressing.
Perhaps the folks involved are simply a bit uninformed and need a tiny bit of information, to whit: It has been standard practice for over twenty years to count the number of interactions a user must make to perform a given action as a measure of the ease of use of an interface. After the mouse became standard, this measure was given the handy name of 'click counting'. Who can read that, and then say "one click" is not the obvious end-point?
"OOXML sucks big time! It's just a repackaged DOC format!"
"Saddam Hussein and Osama Bin Laden hated each other and would have killed each other if they could."
> The compiler then assumes that something(a) can be safely executed in parallel for every element in the list.
That is trivial to implement without changing a language, e.g. for C/C++ just pass function and list of parameters to be executed in parallel to a function which starts a thread for each:
StartParallelThreads(something, list);
The real problem is shared resources, i.e. where those "something(a)" do come into conflict with one another.
Odd that: the one programmer in my shop who started out as a Java only programmer, has the weakest multithreading skills.
Looking at the proposals for switching languages, they just shift the problem around (as another poster has already mentioned). The only thing new that might be useful is the idea of "Guards" from Haskell (for why, see below). But you don't need a new programming language to implement that, with a little imagination you can build it into a C++ library.
In my experience, 99% of the problems are due to two problems: overlooked shared resources and deadlocks. An example of the first problem might be when two threads are pushing/popping from the same queue, causing duplicates or skips. An example of the second would be thread A has resource X and is waiting for resource Y, while thread B has resource Y and is waiting for resource X. Guards could possibly make it easier to avoid some forms of deadlock by making it easier to acquire multiple resources simultaneously with less risk of deadlock. I think I have a new library to go code now... ;-)