One valid reason in the past has been that traditional Unix mail clients do not care much about usability. Most of them are console-based, all with their own keyboard syntax and menu layout.
Console-based and keyboard-based apps can have excellent usability, as applications like Emacs show. What they don't have is "usability for beginners"--it takes a while to get proficient at them. But once people are proficient at them, they can be more efficient with them than in GUI-based systems.
It is true that this may limit their adoption in corporations, but it is absolutely not true that therefore we all should settle on user interfaces that make making easy things easy to learn their number one priority.
Also, few if any of the old clients have collaboration features like Outlook -- they are email clients and nothing else.
Gee, this is no coincidence. In the UNIX world, collaboration and group applications happen in the file system. This is doubtlessly confusing for people who are used to Windows, but it has worked very well for the last 30 years on UNIX systems. Windows/Evolution-style systems don't look like an improvement over that.
Don't get me wrong: Evolution is a nifty E-mail client, and it will doubtlessly attract many users, in particular users coming from Windows. However, neither Windows nor Evolution are the single gold standard for usability--there is not single gold standard for usability. There are many different kinds of user interfaces and many different kinds of people. Let's not fall into the Windows/Gates trap of believing that one size fits all.
These scams predate Internet credit card payments by many years. People used to guess credit card numbers and "verify" them over the phone or at various convenience locations. Banks have made this particularly simple by making valid, recently issued numbers easy to guess.
Seems they've opened themselves to a wave of court cases and possible fraud.
If only that were the case. But in real life, people can do all sorts of irresponsible things with your credit card number and you don't really have any recourse, even if it damages your credit rating and costs you months to straighten out the mess. At best, you can hope that MC or Visa will punish them through their contractual relationship.
Credit card thieves can simply brute force the credit card numbers. Some banks helpfully even assign credit card numbers sequentially or predictably, and the credit card number space is too small anyway.
Social security numbers used as identification, credit card numbers, and a whole host of other "real world" identifiers and systems are simply extremely sloppy security. In the past, that meant that only a few customers got screwed. With modern computer equipment, a lot of people get screwed.
What is particularly annoying about it is that the companies that put this sloppy security in place never really have given a damn about protecting their customers--as long as the casualties are not too many and don't frighten the masses away, it's acceptable. In most cases, companies that use sloppy identifiers or security end up not even being legally liable for the trouble and expenses they are causing their customers.
For earth orbit, telepresence is a much more cost-effective way of having "astronauts" perform work in space. You still get all the benefits of human flexibility with none of the costs of life support systems. And telepresence at this point is probably less cumbersome than a space suit.
If we need real-time human intelligence for planetary exploration, telepresence from orbit is likely also a better choice than human landings: you reduce risks greatly, save on equipment, and still get real-time manipulation. But current planetary exploration goals are so modest that purely robotic systems are probably better.
So, let's scrap human space flight for the time being. We can do an enormous number of really neat exploratory missions in space for the cost of the shuttle program and its replacements. When we return to the issue of human space travel again in a few decades, we'll have much better technologies.
There is no reason to go through the enormous expense of sending humans to mars for now. It would be much cheaper and safer to send more robotic probes. Robotic probes can also be sterilized much more easily, reducing both the risk of contaminating earth with mars bacteria and contaminating mars with earth bacteria.
Once we know one way or another what kind of life exists on mars, then we can start thinking about sending humans. But that will invariably and irrevocably change mars.
I find this constant refrain of the "creative people" that can't be bothered with technical intricacies silly. People into typography, color, graphic design, photography, etc. are every bit as geeky as, and no more "creative" than, your geekiest C programmer. And when it comes down to it, those "creative people" spend inordinate amounts of time fiddling with their Macs, installing extensions, installing little add-ons, tweaking the color, experimenting with different network settings, etc.
The Mac has a shallow (=good) learning curve and makes it easy to get started. And OSX is now (finally) a robust and powerful Macintosh operating system, and that is great. But anybody who spends significant amounts of time with computers will naturally learn a lot of arcane trivia, and that's no different for Mac users.
Yes, that's exactly my point. And because they can't, they should have concentrated on making the STL simple, safe, and focussed, instead of doing something enormously complex that still can't guarantee high performance.
The standard _does_ spec the complexity of the algorithm used,
Yes, which just goes to show how naive the standard is. Asymptotic complexity is neither necessary nor sufficient to ensure efficiency in particular applications. In some cases, an O(N^2) algorithm may be faster than an O(N log N) algorithm, in others it may not be. And if we look at "map", there are lots of O(log N) query data structures, and they are not at all interchangeable. The abstractions that STL presents simply break down when you are talking efficiency.
You are a damned fine troll (I am replying, aren't I?) but you simply say "you are wrong" and wander away without giving any evidence, even a note of personal experience.
Think about it: people didn't start writing multi-tiered applications yesterday. How can you seriously believe that choosing a set of software tools that barely runs on a 1GHz PC is necessary for writing those kinds of applications? The notion is absurd.
For example, if IDEA is too slow, don't use it; there is no evidence that it increases productivity. Even if IDEA wasn't such a dog, its user interface alone is so cumbersome that refactoring in it is slower than doing it by hand, at least for an experienced programmer. People have been refactoring for decades; if you know what you are doing, you don't need IDEA.
As another example, if you can't run the bloated relational database of your choice on your own machine, do what generations of developers have done and set up a dedicated machine for it. During development, there won't be a high load on it. Of course, it is perfectly possible anyway to run a commercial database (like DB2) and a Java development environment even on a sub-100MHz workstation; I was developing like that for a couple of years.
But what's the point of giving those examples? Your problem isn't that you need specific technical advice, your problem (shared with a large number of.COM developers) is a mindset. Buying faster machines or getting little hints here and there isn't going to fix that. Take the time to learn the craft of programming well, and stop thinking that throwing money and new tools at the problem will fix it.
400 MHz is to slow to run our client application, local instance of mid-tier server, and IDE simultaneously so you can debug the business logic effectively on the middle tier.
Well, that's just too bad--because it's a problem with your client application, system architecture, and development methods. A 400MHz PC is perfectly fine for developing multi-tiered, database-backed Java applications.
Once you factor in build times it becomes absurd to waste your (expensive) developer's time waiting on a slow cpu.
Modern Java compilers exceed 10kloc/sec on a 400MHz PC, and Java code has much fewer compile-time dependencies than C or C++. If it consistently takes more than a few seconds to recompile your system after an edit, you are either using the wrong tools or you set up your project wrong.
Grayscale and 66MHz are fine, and the form factor is great. But it needs an SD slot and a standard serial port (or Bluetooth) to be really useful. Can that be so expensive to add? Of course, slightly higher resolution would be nice, too.
Whereas with bounds checking you have have to introduce another register to hold the index, along with possible redirects and atleast 2 comparisions.
Yes, you need one register to hold the bound and you need one bounds check instruction, a single, fast, register-based operation. Neither is a big issue on modern processors. For the array indexing, you need to load the base, the index, add them, and then do the indirect load. Furthermore, you usually do something with the value, further amortizing the cost of the array bounds check. Overall, the overhead of array bounds checking in real programs is generally modest.
In addition, if bounds checking had been part of the C++ standard library, compiler vendors would have gone out of their way to make compilers understand it and to add the right kinds of primitives to their libraries (and maybe the C++ standard) to make it as efficient as possible. Instead, we have vendors wasting their time on implementing the most obscure template features imaginable.
Note that even on something as antiquated as the x86 architecture, you only need a single comparison, commonly and idiomatically expressed in C++ as "unsigned(index)>=unsigned(bound)".
Furthermore, even if this modest overhead affects program performance, it usually does so only in a handful of cases in any real program. The correct solution is to have an optional unsafe subscripting operator that is used only in those few places where it is demonstrably important (and only conditionally after extensive testing even in those places).
It just boggles the mind that something as dismissive of safety and debugging concerns as the STL could have been designed and accepted by a standards body in the 1990's. The STL is so fatally flawed that we would have been better off delaying ANSI C++ by another year or two than rushing it out the door with STL. But, I suppose, the situation is symbolic of the widespread disregard for software quality in the industry.
Works for me. I was developing Java and C++ on a 300MHz PC with 256Mbytes of RAM until a few months ago, when the motherboard finally died, and even that was a big machine.
Come on, people used to do C++ development on 40MHz SPARCstations. You don't need a big machine for C++ development unless you are actually trying to solve big computational problems.
Have you ever tried using even DreamWeaver on a 400MHz machine? What about VisualCafe? Or deploying an app with a few dozen EJBs and servlets to WebLogic, running on the same machine as the Cafe?
What does any of that have to do with web development?;-)
Yes: they give you paper-like resolution on the display. With them, I can finally look at PDF documents and read the small type without eyestrain or constantly playing with the magnifying glass.
Of course, you do need to update UIs to deal with them. The default Windows fonts are tiny on them.
An STL vector will perform exactly the same as a standard C array. If bounds checking was introduced, a vector would be between 3 and probably 20 times slower depending on the inliner.
For the STL, that is probably true, and it is one of the fundamental design flaws with the STL: bounds checking in the STL is very costly. The irony is that the STL has taken pointer arithmetic, which gave you a bit of efficiency on a PDP-11 with a dumb compiler, and turned it into a feature that makes the STL both unnecessary complex and very hard to bounds-check.
But there is nothing inherently costly about array bounds checking. Modern processors are designed to implement it efficiently. In a well-designed template library, the overhead of array bounds checking should be less than a factor of 2.
The performance of STL algorithms is implementation dependent. You get good performance if you get a good implementation and if you use the right combination of algorithm and container. And that means that, for practical purposes, using STL algorithms is risky because you don't know what you are going to get in terms of performance.
The STL makes no guarantees that it checks for errors (bounds checking, using a pointer into the wrong collection, etc.), and it is designed in such a way that error checking is quite costly. (Note that there have been a couple of attempts at making a safe STL; see here; it is unacceptable that this isn't part of the standard and isn't used by default).
It's hard to predict whether any particular data structure or algorithm is going to be fast. Sure, it makes asymptotic guarantees, but everybody does that; it's the constants that matter.
The library is too complex for most needs, and you can't easily just use "a little bit" of it. If you want to write efficient code using STL, you have to understand it pretty well.
STL's complex semantics also make thread safety hard to guarantee.
The STL wasn't adopted because the committee liked it tremendously, it was adopted by default: it was the only serious proposal for collection classes for C++ that the committee had, and C++ needed collection classes in order to pass as a standard. I think what C++ should have gotten was a simple template array class, list class, and hash table class, with excellent error checking. IMO, STL has greatly damaged the C++ language.
How can you live with the C++ STL? Your best bet is to pick a small, simple subset of concrete STL datatypes and operations (vector, stack, and map) and stick to those in your interfaces and most of your code. You can implement your own, safe and efficient versions of those for development and internal use and use the standard STL versions when you ship library code. Forget about iterators: they are a mess to debug. And use the STL algorithms only if you don't care about performance.
Note that I have nothing against generic programming: generic programming is an old and well-established idea (and predates Stepanov and Lee by many years). C++ is just not a good language to push it to the extremes that STL pushes it.
Slashdot Mirror
Console-based and keyboard-based apps can have excellent usability, as applications like Emacs show. What they don't have is "usability for beginners"--it takes a while to get proficient at them. But once people are proficient at them, they can be more efficient with them than in GUI-based systems.
It is true that this may limit their adoption in corporations, but it is absolutely not true that therefore we all should settle on user interfaces that make making easy things easy to learn their number one priority.
Also, few if any of the old clients have collaboration features like Outlook -- they are email clients and nothing else.
Gee, this is no coincidence. In the UNIX world, collaboration and group applications happen in the file system. This is doubtlessly confusing for people who are used to Windows, but it has worked very well for the last 30 years on UNIX systems. Windows/Evolution-style systems don't look like an improvement over that.
Don't get me wrong: Evolution is a nifty E-mail client, and it will doubtlessly attract many users, in particular users coming from Windows. However, neither Windows nor Evolution are the single gold standard for usability--there is not single gold standard for usability. There are many different kinds of user interfaces and many different kinds of people. Let's not fall into the Windows/Gates trap of believing that one size fits all.
These scams predate Internet credit card payments by many years. People used to guess credit card numbers and "verify" them over the phone or at various convenience locations. Banks have made this particularly simple by making valid, recently issued numbers easy to guess.
If only that were the case. But in real life, people can do all sorts of irresponsible things with your credit card number and you don't really have any recourse, even if it damages your credit rating and costs you months to straighten out the mess. At best, you can hope that MC or Visa will punish them through their contractual relationship.
Social security numbers used as identification, credit card numbers, and a whole host of other "real world" identifiers and systems are simply extremely sloppy security. In the past, that meant that only a few customers got screwed. With modern computer equipment, a lot of people get screwed.
What is particularly annoying about it is that the companies that put this sloppy security in place never really have given a damn about protecting their customers--as long as the casualties are not too many and don't frighten the masses away, it's acceptable. In most cases, companies that use sloppy identifiers or security end up not even being legally liable for the trouble and expenses they are causing their customers.
What's going to be next? This???
If we need real-time human intelligence for planetary exploration, telepresence from orbit is likely also a better choice than human landings: you reduce risks greatly, save on equipment, and still get real-time manipulation. But current planetary exploration goals are so modest that purely robotic systems are probably better.
So, let's scrap human space flight for the time being. We can do an enormous number of really neat exploratory missions in space for the cost of the shuttle program and its replacements. When we return to the issue of human space travel again in a few decades, we'll have much better technologies.
Once we know one way or another what kind of life exists on mars, then we can start thinking about sending humans. But that will invariably and irrevocably change mars.
The Mac has a shallow (=good) learning curve and makes it easy to get started. And OSX is now (finally) a robust and powerful Macintosh operating system, and that is great. But anybody who spends significant amounts of time with computers will naturally learn a lot of arcane trivia, and that's no different for Mac users.
Yes, that's exactly my point. And because they can't, they should have concentrated on making the STL simple, safe, and focussed, instead of doing something enormously complex that still can't guarantee high performance.
Yes, which just goes to show how naive the standard is. Asymptotic complexity is neither necessary nor sufficient to ensure efficiency in particular applications. In some cases, an O(N^2) algorithm may be faster than an O(N log N) algorithm, in others it may not be. And if we look at "map", there are lots of O(log N) query data structures, and they are not at all interchangeable. The abstractions that STL presents simply break down when you are talking efficiency.
You see, I know that bounds errors are not common in my projects because I use bounds checking.
Throw me something that will solve a problem I don't already have under complete control to begin with.
How would you have a clue whether you have it under control? You don't test for it.
Think about it: people didn't start writing multi-tiered applications yesterday. How can you seriously believe that choosing a set of software tools that barely runs on a 1GHz PC is necessary for writing those kinds of applications? The notion is absurd.
For example, if IDEA is too slow, don't use it; there is no evidence that it increases productivity. Even if IDEA wasn't such a dog, its user interface alone is so cumbersome that refactoring in it is slower than doing it by hand, at least for an experienced programmer. People have been refactoring for decades; if you know what you are doing, you don't need IDEA.
As another example, if you can't run the bloated relational database of your choice on your own machine, do what generations of developers have done and set up a dedicated machine for it. During development, there won't be a high load on it. Of course, it is perfectly possible anyway to run a commercial database (like DB2) and a Java development environment even on a sub-100MHz workstation; I was developing like that for a couple of years.
But what's the point of giving those examples? Your problem isn't that you need specific technical advice, your problem (shared with a large number of .COM developers) is a mindset. Buying faster machines or getting little hints here and there isn't going to fix that. Take the time to learn the craft of programming well, and stop thinking that throwing money and new tools at the problem will fix it.
Well, that's just too bad--because it's a problem with your client application, system architecture, and development methods. A 400MHz PC is perfectly fine for developing multi-tiered, database-backed Java applications.
Once you factor in build times it becomes absurd to waste your (expensive) developer's time waiting on a slow cpu.
Modern Java compilers exceed 10kloc/sec on a 400MHz PC, and Java code has much fewer compile-time dependencies than C or C++. If it consistently takes more than a few seconds to recompile your system after an edit, you are either using the wrong tools or you set up your project wrong.
NFS isn't really any better--it just has a different set of problems than SMB. We really need something better in the open soruce community.
Sorry, I meant USB, not serial. It does have a standard serial port, of course.
Grayscale and 66MHz are fine, and the form factor is great. But it needs an SD slot and a standard serial port (or Bluetooth) to be really useful. Can that be so expensive to add? Of course, slightly higher resolution would be nice, too.
Here is the research group's web site. No update since 2000...
Yes, you need one register to hold the bound and you need one bounds check instruction, a single, fast, register-based operation. Neither is a big issue on modern processors. For the array indexing, you need to load the base, the index, add them, and then do the indirect load. Furthermore, you usually do something with the value, further amortizing the cost of the array bounds check. Overall, the overhead of array bounds checking in real programs is generally modest.
In addition, if bounds checking had been part of the C++ standard library, compiler vendors would have gone out of their way to make compilers understand it and to add the right kinds of primitives to their libraries (and maybe the C++ standard) to make it as efficient as possible. Instead, we have vendors wasting their time on implementing the most obscure template features imaginable.
Note that even on something as antiquated as the x86 architecture, you only need a single comparison, commonly and idiomatically expressed in C++ as "unsigned(index)>=unsigned(bound)".
Furthermore, even if this modest overhead affects program performance, it usually does so only in a handful of cases in any real program. The correct solution is to have an optional unsafe subscripting operator that is used only in those few places where it is demonstrably important (and only conditionally after extensive testing even in those places).
It just boggles the mind that something as dismissive of safety and debugging concerns as the STL could have been designed and accepted by a standards body in the 1990's. The STL is so fatally flawed that we would have been better off delaying ANSI C++ by another year or two than rushing it out the door with STL. But, I suppose, the situation is symbolic of the widespread disregard for software quality in the industry.
Come on, people used to do C++ development on 40MHz SPARCstations. You don't need a big machine for C++ development unless you are actually trying to solve big computational problems.
What does any of that have to do with web development? ;-)
If you must, go out and get some low-end consumer PCs and buy a bunch of spares: it's less work than building your own and still very cheap.
Of course, you do need to update UIs to deal with them. The default Windows fonts are tiny on them.
For the STL, that is probably true, and it is one of the fundamental design flaws with the STL: bounds checking in the STL is very costly. The irony is that the STL has taken pointer arithmetic, which gave you a bit of efficiency on a PDP-11 with a dumb compiler, and turned it into a feature that makes the STL both unnecessary complex and very hard to bounds-check.
But there is nothing inherently costly about array bounds checking. Modern processors are designed to implement it efficiently. In a well-designed template library, the overhead of array bounds checking should be less than a factor of 2.
The performance of STL algorithms is implementation dependent. You get good performance if you get a good implementation and if you use the right combination of algorithm and container. And that means that, for practical purposes, using STL algorithms is risky because you don't know what you are going to get in terms of performance.
The STL wasn't adopted because the committee liked it tremendously, it was adopted by default: it was the only serious proposal for collection classes for C++ that the committee had, and C++ needed collection classes in order to pass as a standard. I think what C++ should have gotten was a simple template array class, list class, and hash table class, with excellent error checking. IMO, STL has greatly damaged the C++ language.
How can you live with the C++ STL? Your best bet is to pick a small, simple subset of concrete STL datatypes and operations (vector, stack, and map) and stick to those in your interfaces and most of your code. You can implement your own, safe and efficient versions of those for development and internal use and use the standard STL versions when you ship library code. Forget about iterators: they are a mess to debug. And use the STL algorithms only if you don't care about performance.
Note that I have nothing against generic programming: generic programming is an old and well-established idea (and predates Stepanov and Lee by many years). C++ is just not a good language to push it to the extremes that STL pushes it.