Maybe it's a generational mark, or maybe it's only common sense, but in my opinion, OOP today is being over-used. Object abstraction is just a tool, and not a specially good one.
There are more challenging scenarios, paralelization, aspect oriented programming (unfourtunately and arbitrariely mixed with OOP), grid computing, non-textual information processing, etc.
The usage of OOP (read C++) would be much smaller if MS had decided to make the MFC in another language. The C++ 'success' truncated the adoption of better object metaphores (smalltalk).
Maybe is because I learn C too many years ago, but I would not calify C++ as 'merely' and object oriented extension to C. The differences are vast and deep, memory management, variable types, exceptions, sintax.
C++ is an extension to C, true, but the size of that extension is enormous, the beauty of C++ lies in my opinion in that all that extra behaviour can be done with a few C conventions (ie vtables).
Optimization is a complex issue, for instance, you can say, 'ok, in the end the program has to run on a given platform, so we can almost forget about intermediate representations, and focus our effort to create assemby code and then apply know platform optimizations'.
On the other side, you can say 'because we don't know apriori what the running platform is going to be, we better try to reformulate the program on his most optimistic expression, and only then proceeed to create assembly and re-optimize the code.
Of course, to take both levels at the same time, and optimze the code acording the 'high level sintax running on that given platform', is the best approach. Unfortunately to use information from both levels conplicates enormously the designs, and sometimes its benefits are not that evident.
We need a higher level of knowledge of hardware, ie curently, there's no difference between creating a low computational cost opcode (say shift), and a high cost one (say mult) both are just numbers, the program creating the opcodes has only euristics to choose between alternate representations, that's why optimization is so hard, because it depends on the idiosincrasies of the goven platfform doing a given piece of code.
I think we need programs that examine/change running programs to learn the best ways to execute the code. VMs are great for that, because we (those examining programs) can change at runtime the code creation procedures, and profile the results to extract useful information to be applied in succesive generations/versions.
The meme of `register byte code will map nicely to harware' is also rubbish.
True, but the meme of 'stack machines are easier to tune because are conceptually simpler' is also a false.
The fact is that optimizing an VM is difficult, hell, after 50+ years of computer science we are stil trapped on a stack/register dicothomy!?.
If you read "The Art of UNIX Programming", threads are considered the last resort if no other IPC mechanism is fast enough.
That's only because the book's author never have to deal with scenarios where threads are the logical solution, ie graphical interfaces.
Don't take me wrong the book is great and after too many years of experience, I still subcribe almost 90% of the views expressed on the book, but the 'unix only' background/bias of the author is evident.
As for threads or processes, just use the right tool for the job, there are no magic rules.
Oh!, True, but the underlying mindset in C is just a set of variables/registers on a simple memory space, that's why is so simple.
C++ on the other side, is an 'object metaphor', and so needs to have a new() keyword and his related memory behaviour. C has no built-in memory requeriments (except a stack/memory abstraction).
Maybe that CO2 increment could be related to the Global Dimming effect. IANACE (climate expert) but two unknows happening at the same time, on the same subject (atmos)...
Now seriously, there's no excuse, we should have by now all the free content of all over the world online, free for anyone to use and enjoy. Maybe the UN should encompass such a project, meanwhile any effort on that direction is of course welcomed.
It would be useful yes, but on the other side, going from a single language (english) to any other imply a lost of descriptive power that is too extreme.
We need to actively protect our languages, we are already losing too much of our own knowledge letting disappear the small ones.
Not only the Library of Congress of the Unites States of America, we should also scan every big library in the world to create a pool of human work to freely share and preserve.
I think you have a point here, but realize how strict your example is, a piece of hardware!. That means an strict set of inputs and operands with a predefined set of outputs.
The case is not trivial but is well defined, on the other hand, consider how any simple database independent piece of software becomes far more complex if you pretend fully tested portability across a range of database implementations.
Or consider any program expected to run upon a posix implementation, the program may be simple (ie, open/read/close), but the working instances inherits the underlying complexity of the running posix implementation, and so the testing should consider the different posix implementations and behaviours, becoming 'de facto' impossible to test properly.
I've been thinkink about software as an industrial activity for more than 20 years, but it seems that as long as writing software is not fully automated, I see no way to seriously consider QA on a 'hand made' product.
In the end we deal with uncertainty, and logical proof of correctness are always the exception, never the rule.
It may sound crazy these days, but it is not.
Never saw a non trivial piece of software (read 'real application') that is 'FULLY' tested.
The whole concept of 'QA' on software is ridiculous, software has two main propieties that invalidates the whole concept:
1 - The complexity factor, interrelation between parts give an exponential number of possible error conditions, testing those conditions, simply takes too much time.
2 - There's no way no qualify a design as 'good', that's a application dependent evaluation, not an objective one. The best we can say about a given design is that is not that bad, we cannot logicaly assure quality on design.
I can understand the bussiness need of such concepts, and the real opportunity of people doing bussiness around them, but pretending QA is something more than a buzzword and a bussines catchword is simply false.
1 - Who test the tests? (fiability)
2 - Parts are tested, ok, what about the whole thing? (exponential complexity)
3 - Doesn't help when the design is flawed. (correctness).
Overall, unit testing is ok/valuable at a certain level of abstraction, tipically used in library dvelopment, not a panacea, just a good habitude.
There's no way to kill the complexity factor inherent in software development, there's no way to assure that a given design is the correct one.
Maybe when we start to do automated programming, but by now is just a form of writing.
Now, you say that you have a lot of problems with Outlook. Sorry, but THIS is FUD.
Humm... excuse me but wasn't email (Outlook) the preferred entry an spread vector of V-I-R-U-S on windows?. Call it FUD if you like it, but the amount of lost hours due to Outlook 'features' is simpky astonishing.
Slashdot Mirror
The previous ways are still valid - but the areas where they are appropriate disappear over time.
I dissent.
Those 'old ways' are not 'old methodologies'. Thechnicalities dissapear over time, but experience accumulates.
Maybe it's a generational mark, or maybe it's only common sense, but in my opinion, OOP today is being over-used. Object abstraction is just a tool, and not a specially good one.
There are more challenging scenarios, paralelization, aspect oriented programming (unfourtunately and arbitrariely mixed with OOP), grid computing, non-textual information processing, etc.
The usage of OOP (read C++) would be much smaller if MS had decided to make the MFC in another language. The C++ 'success' truncated the adoption of better object metaphores (smalltalk).
Easy, add redundancy to the network of stations. For every route add extra station along the way, that way you have a finer control of the trajectory.
Hell, with such a net we could even have periodic revision teams.
One of the most beautiful ways to use nuclear power I've never read.
Maybe is because I learn C too many years ago, but I would not calify C++ as 'merely' and object oriented extension to C. The differences are vast and deep, memory management, variable types, exceptions, sintax.
C++ is an extension to C, true, but the size of that extension is enormous, the beauty of C++ lies in my opinion in that all that extra behaviour can be done with a few C conventions (ie vtables).
Optimization is a complex issue, for instance, you can say, 'ok, in the end the program has to run on a given platform, so we can almost forget about intermediate representations, and focus our effort to create assemby code and then apply know platform optimizations'.
On the other side, you can say 'because we don't know apriori what the running platform is going to be, we better try to reformulate the program on his most optimistic expression, and only then proceeed to create assembly and re-optimize the code.
Of course, to take both levels at the same time, and optimze the code acording the 'high level sintax running on that given platform', is the best approach. Unfortunately to use information from both levels conplicates enormously the designs, and sometimes its benefits are not that evident.
We need a higher level of knowledge of hardware, ie curently, there's no difference between creating a low computational cost opcode (say shift), and a high cost one (say mult) both are just numbers, the program creating the opcodes has only euristics to choose between alternate representations, that's why optimization is so hard, because it depends on the idiosincrasies of the goven platfform doing a given piece of code.
I think we need programs that examine/change running programs to learn the best ways to execute the code. VMs are great for that, because we (those examining programs) can change at runtime the code creation procedures, and profile the results to extract useful information to be applied in succesive generations/versions.
The meme of `register byte code will map nicely to harware' is also rubbish.
True, but the meme of 'stack machines are easier to tune because are conceptually simpler' is also a false.
The fact is that optimizing an VM is difficult, hell, after 50+ years of computer science we are stil trapped on a stack/register dicothomy!?.
Grow a penis and install Unix.
Or it was the other way around?
If you read "The Art of UNIX Programming", threads are considered the last resort if no other IPC mechanism is fast enough.
That's only because the book's author never have to deal with scenarios where threads are the logical solution, ie graphical interfaces.
Don't take me wrong the book is great and after too many years of experience, I still subcribe almost 90% of the views expressed on the book, but the 'unix only' background/bias of the author is evident.
As for threads or processes, just use the right tool for the job, there are no magic rules.
Oh!, True, but the underlying mindset in C is just a set of variables/registers on a simple memory space, that's why is so simple.
C++ on the other side, is an 'object metaphor', and so needs to have a new() keyword and his related memory behaviour. C has no built-in memory requeriments (except a stack/memory abstraction).
Ok, Now is a really web enabled experience! :)
The dicothomy netween processes and threads is false/religious/historical/etc, just use the right tool for the job, that's all.
Sorry, but C++ is NOT C
C do things the machines way, C++ not.
Maybe that CO2 increment could be related to the Global Dimming effect.
IANACE (climate expert) but two unknows happening at the same time, on the same subject (atmos)...
mathematics is a description of experience
Only on the shadows of the cave. :)
CopyWhat? :)
Now seriously, there's no excuse, we should have by now all the free content of all over the world online, free for anyone to use and enjoy. Maybe the UN should encompass such a project, meanwhile any effort on that direction is of course welcomed.
It would be useful yes, but on the other side, going from a single language (english) to any other imply a lost of descriptive power that is too extreme.
We need to actively protect our languages, we are already losing too much of our own knowledge letting disappear the small ones.
Sorry but NO
Digital content means that any piece of information is just a number, and that means that perfect copy is not only possible but simply natural.
If you really want to 'protect' your work, don't go digital, is that simple, there's no way to stop math.
Not only the Library of Congress of the Unites States of America, we should also scan every big library in the world to create a pool of human work to freely share and preserve.
I think you have a point here, but realize how strict your example is, a piece of hardware!. That means an strict set of inputs and operands with a predefined set of outputs.
The case is not trivial but is well defined, on the other hand, consider how any simple database independent piece of software becomes far more complex if you pretend fully tested portability across a range of database implementations.
Or consider any program expected to run upon a posix implementation, the program may be simple (ie, open/read/close), but the working instances inherits the underlying complexity of the running posix implementation, and so the testing should consider the different posix implementations and behaviours, becoming 'de facto' impossible to test properly.
I've been thinkink about software as an industrial activity for more than 20 years, but it seems that as long as writing software is not fully automated, I see no way to seriously consider QA on a 'hand made' product.
In the end we deal with uncertainty, and logical proof of correctness are always the exception, never the rule.
I've never believed on testing.
It may sound crazy these days, but it is not.
Never saw a non trivial piece of software (read 'real application') that is 'FULLY' tested.
The whole concept of 'QA' on software is ridiculous, software has two main propieties that invalidates the whole concept:
1 - The complexity factor, interrelation between parts give an exponential number of possible error conditions, testing those conditions, simply takes too much time.
2 - There's no way no qualify a design as 'good', that's a application dependent evaluation, not an objective one. The best we can say about a given design is that is not that bad, we cannot logicaly assure quality on design.
I can understand the bussiness need of such concepts, and the real opportunity of people doing bussiness around them, but pretending QA is something more than a buzzword and a bussines catchword is simply false.
Unit testing is not a panacea.
1 - Who test the tests? (fiability)
2 - Parts are tested, ok, what about the whole thing? (exponential complexity)
3 - Doesn't help when the design is flawed. (correctness).
Overall, unit testing is ok/valuable at a certain level of abstraction, tipically used in library dvelopment, not a panacea, just a good habitude.
There's no way to kill the complexity factor inherent in software development, there's no way to assure that a given design is the correct one.
Maybe when we start to do automated programming, but by now is just a form of writing.
Now, you say that you have a lot of problems with Outlook. Sorry, but THIS is FUD.
Humm... excuse me but wasn't email (Outlook) the preferred entry an spread vector of V-I-R-U-S on windows?. Call it FUD if you like it, but the amount of lost hours due to Outlook 'features' is simpky astonishing.
Now... guess how people react when they think their boss is cheap...
OK, now guess how your boss reacts when they realize that you think s/he is cheap! :)
Just to be realistic.
What's the confidence factor of a shared calendar between 100 or more people?
If the answer is below 90%, you better not try to relay on that information for critical work.
A lot of posts say: "Relax, take-it easy", :)
It seems you are going to be inevitably nervous!
Best wishes