I haven't encountered such a version, and I saw most versions since 4.0. Maybe you've got some weird configuration error, happens all the time. Best strategy is to update or at least reinstall.
Standardization has been the driving force behind the industrial revolution. Before the industrial revolution, you had to make your own parts if you wanted to put something together because the parts you'd buy elsewhere would almost certainly be incompatible.
For software this is no different. If you look at the win32 platform for instance, you'll see my point. MS has succeeded in getting people to use their components. This has resulted in a large number of applications. From a technical persective there's nothing revolutionary about their stuff (some might even claim it is buggy and has obvious flaws). The Java platform is another example, by providing the same set of components on each VM, applications can be WORA. Often you don't even have to test it works and you can just assume it works.
Now under linux there's always more than one solution to a single problem. Whether we are talking about package management, window managers or even glibc. You can't make much assumptions about what will actually be running on a random linux install. This is both an advantage and a disadvantage: you get choice but at the same time, application developers must assume the common denominator rather than the latest and greatest to be present.
If you'd read a little further, you would have noticed that there's an answer to this question on the site. The main reason appears to be that maintaining TCP connections is to resource intensive for the job (they want something like 50000 or even more connections). On top of that TCP is a bit overkill for the purpose. The connections don't have to be reliable and timeouts are no real problem.
In fact it is really a smart way of reusing the way IP provides peer to peer connections. This DTCP thing sounds like it just might work (unlike gnutella for instance).
UNIX doesn't have one UI it has dozens of UIs. Some of them (Gnome, KDE) are quite good. Some are a bit more primitive. Each perfectly suits the needs of a small group of users. Most of them provide limited compatibility with the alternatives (meaning that typically applications will run but will not integrate well with other applications). The solution to this problem does cannot be found in creating another GUI but in getting GUI creators to agree on basic standards: how to cut and paste, how to embed components, how to define a menu structure, how to put an icon on the desktop, etc. As long as there's more than one way of doing things, there will be inconsistencies making UNIX user unfriendly
you don't get it, these properties of text based storage of sourcecode put an upper limit on a system's size.
Now c++ and c are typical examples where the fixed semantics of the language are not enough. Hence the use of preprocessors. If you were right, preprocessors would be redundant.
Obviously you haven't read Fowler's book on refactoring, otherwise you wouldn't claim such nonsense, I strongly recommend you do.
", but they are different conceptual entities, and should be stored and represented differently."
Just one question: why?
Answer: design uses different representations because sourcecode does not provide you with the constructs to model the design (i.e. the expressiveness of source code is very limited). Abandon the notion of text based storage and fixed semantics and that problem goes away. No more outdated designs! The system description contains all the information you need. You just have to query it in a smart way to get rid of the info you don't need.
"programmers have to do it, and managers have to build time and motivation into the the process to ensure that it happens."
Walk into your average large software company responsible for lets say around 5 million lines of code. Ask for the design documents. Presuming they don't throw you out, you'll find that in most cases either the design consists of some very outdated documents or that the sourcecode is the documentation. In real life people don't spend much time recovering designs unless they absolutely have to. Try convincing managers you want to spend the next three months just recovering the design of the product you're working on.
All programs start as vaporware. This is not a product anouncement, just a few people communicating some good ideas about the way we currently build software and a plan to improve it.
Since the very basis of their idea is not to have a text representation, you won't find code examples. I think the best way to think about working with this kind of systems is as manipulating parse trees (without actually having to parse!). For instance, variables will not be represented as identifiers. Rather you'll just point at the spot in the parse tree where the variable is pointing at (i.e. some subtree). Also the pointer can point to any subtree. So if, you've built some very complex algorithm, all you have to do to reuse it is point at it in the parse tree.
Text is unsuitable for representing structured data. That's why databases exist. In fact the only reason we store programs in ascii files is because programmers are reluctant to give up their vi/emacs editors.
Because of this:
1 - Languages have fixed semantics. The text files follow a syntax which cannot be changed. Consequently the semantics of the syntactical constructs are also fixed. Ever wanted to add multiple inheritance to Java? Well, you can't because the language spec forbids it.
2 - Automatic refactoring of code is difficult, regular expressions just are not powerfull enough to do the job. You need more structure to do it properly.
3 - You don't have first class representations of design concepts. Because of point 1 you can't add them to the language either. But worse, the most abstract details about your system are lost when you store them as text. You won't be able to recover them with a parser, simply because the information is no longer there. Ever tried to recover a highlevel design from just the source code? I remember seeing something about a dependency graph of the linux kernel just a few days ago. That's the best we can do with source code.
Now does this mean we have to give up on our editors? The answer is no. All that needs to change is the primary representation of the program. Once you have a representation, you can define a view on it to be able to manipulate it. Ascii is probably the simplest form of such a view. However, it is a rather limited view also. So we'll need more advanced tools as well.
Finally, I should add that eidola should visit microsoft's site: http://www.research.microsoft.com/ip/ to learn about their intentional programming project. Charles Simonyi had a similar vision years ago and apparently the project has advanced significantly since then. The information on the page is a bit limited unfortunately, but there are some very interesting papers.
Both the language, API and bytecode specifications are available at your convenience. The fact that ISO or any other organization has not put a stamp on it is not very relevant since all the relevant information is open. Lets call it an open industry standard. Closed propietary standards on the other hand do not have these properties. The win32 API, for instance, is largely undocumented and creating something such as wine is a long process of reverse engineering and testing of the binaries.
Now.Net is going to be similar to win32 and different from Java in that many of the APIs will be undocumented and in addition that there will be dependencies on the closed win32 API's. Because of this, vendor independent implementations of.Net, as is common for Java VMs and compilers, are highly unlikely to be available.
Now the confusing part is that MS is making parts of their.Net specifications available and is even moving to standardize for instance C#. However, the bulk of.Net remains closed.
I was thinking the other day how much equipment I have at home that just sits there doing nothing most of the time. The amount of energy consumed by these machines is quite large. Lets see:
- TV, standby most of the day
- Video, same thing
- Printer power supply (I rarely use the printer), always feels warm.
- Power supply of PC's. Even when turned of, the power supply is still active. One of my PC's actually has a second switch on the back to turn it off. However, I rarely use that switch.
- Sub woofer, always has a led blinking.
- Adsl modem, comes with a power supply too.
- Microwave
- Refrigarator
All these machines are using energy constantly, even when I'm not there, 24 hours a day, 365 days a year. That's a lot of energy.
1 your clone will be much younger than you
2 your clone will develop its own personality
3 your clone will have similar capabilities as you and might actually enslave you. So if you are not a nice person, chances are that your clone will have a bad character as well.
4 as far as I know clones still need a mother to grow in. After the embryo has been implanted, development is exactly the same as with normal embryos. So there's absolutely no need to treat them any different than you would treat normal children.
I'm currently using a propietary banking package (homenet from abn-amro, I'm dutch in case you wonder). It sucks. During installation it threw a general protection error at me. Some of the buttons in the program have the same result. It is a 16 bit windows program, obviously written in the good old windows 3.1 days. It doesn't integrate with excel (I wish it did because that would allow for some nice analysis of the data). The GUI is a mess and on top of that it managed to fuck up its internal database.
In short: it's the worst piece of shit I've seen in a long time. Would I prefer an open source version? Yes, provided it was tested properly by somebody else than its developers. I would like to see banks stop developing their shitty propietary packages and start using the same software (propietary or open-source).
Your argument about propietary software is not valid since we're talking about client software. What they do on the server side is the bank's business. All they have to do is provide some standard, secure way of communication.
Many software engineering programs are still stuck in teaching methods based on the waterfall model. You might call XP a process du jour but that doesn't mean it doesn't have things worth considering. The open ended, deliberately iterive way of developing software with frequent releases and strong emphasis on testing is good for a change. You should read Marting Fowler's essay on XP and other methods (available at www.martinfowler.com).
I find that most CS students are particularly ignorant about methodology. They're usually quite naive about such things as working in a team and making realistic plannings and tend to overestimate their own capabilities.
Now pair programming is already practiced in many CS schools and universities anyway. Add some course about testing and let different pairs team up to build something larger and you have an nice XP training course.
Because of the short iterations, it is possible for teachers to keep track of the student rather than having to wait for whatever is thrown over the fence at the end of the semester.
The ultimate test for any language is to write the compiler in its own language. Of course you'll need a separate language for writing the first versions of the compiler. Once that's in place you can write a compiler in the language it is supposed to compile. Doing so is usually a good test for your language. So ultimately you don't need C even for writing compilers.
C should only be used in those parts of a system that are really critical (critical as in a profiler shows that we need more performance here and there's no way to do it the language we're currently using). Using C when it's not needed costs you in terms of lines of code, development time, bugs (direct correlation with lines of code) and maintenance cost (same correlation again). Some might argue against LOC, but the other things have been shown to be true in very extensive and convincing casestudies (I could look up some references if you'd like to have them).
"It appears to me to be a straight shoot-out between C and Java, unless you can give us some of the "plenty of alternatives to C" (preferably ones with comprehensive libraries). Can someone who has worked on implementing a JVM indicate the performance of a machine with nameserver (along with httpd, ftd, etc) all written in Java?"
I didn't start about Java:) But now that we're discussing it: it would require more memory and depending on the way the data is stored, it should perform about as good as the C version provided a run-time optimizing JVM such as Hotspot is used. I wouldn't bet my life on the performance being as fast as C but I don't think performance would be seriously slower. But then there's only one way to find out. The memory usage is an issue however, and I wouldn't go as far as to recommend Java for the job. Probably C++ with a good library and preferably with a garbage collector or some other form of controlling memory allocation would take care of such things as buffer overruns and memory leaks. If you must use a procedural language there's always pascal, modula and derivatives. They're all capable of making system calls so libraries are not an issue + they probably come with some libraries of their own. But then why bother with obsolete paradigms at all. I know this is an issue for some but object oriented programming has been around for thirty years, good quality compilers and tools have been around for a long time, performance has ceased to be an issue in most situations.
My whole point is that the technology exists today to prevent this kind of situations. There's no kind of excuse for this kind of bugs anymore.
I strongly oppose your suggestion that you can make programmers work harder and code better (if you know how, you're going to be rich). It hasn't happened in the past and I guarantee you it won't happen in the future. It's the technology that's fundamentally flawed and not the programmer.
>can you suggest another language that scores higher than C for such a low-level application?
C++, with some proper string class would have probably prevented the problem. I suspect a Java implementation would perform acceptably too. However, there are several procedural languages that would be suitable as well. There's plenty of alternatives to C. C may have been a nice language for this kind of programs in the seventies but its 2001 now. C had technical flaws, many of which were addressed in languages that came after it.
BTW. I disagree that this is a low level application. Device drivers are lowlevel applications. You typically find them at the bottom layer of the OSI model. Bind would classify for the application layer (almost at the top).
Then, you hammer down the fact that it is possible to create safe programs in C. But then my simple question is: why the hell do we have all these security leaks? Bind isn't an incident, it's just the latest leak to be found. Probably a solution will be provided in the form of a patch. However, this patch won't fix the fundamental problem, it will just fix the symptom and in the future more bugs will be found.
Cut the crap, one of the most important tools on the internet broke down because of a memory leak.
Of course it is possible to create good programs if you don't make any errors, duh. The problem is that humans do make errors. And since C provides little or no protection against these errors it is unsafe.
As long as we will use C for implementing these kind of things, there will be memory leaks. Of course C is a very performance efficient language, however, things like this make it unsuitable for security critical apps because you can never be 100% sure it doesn't have memory leaks.
Most security leaks are a direct consequence of using languages like C. People claim it is possible to program safely in C, however, incidents like this prove them wrong.
I though it was rather disappointing. The textures sucked, there was hardly any interactivity: no opening doors, moving robot arms or what so ever. Just these little question marks that when clicked pop up a text window.
Nevertheless, you get a pretty good impression of how the ISS is organized.
I can only watch one channel at the time. Why waste all this bandwidth on stuff you cannot possibly watch anyway. Put the tuner on the other side of the cable and switch channels remotely. All the extra bandwidth can be used for regular internet usage. As a matter of fact, why not stream that remaining channel over TCP/IP anyway?
I don't see the problem, the bandwidth exists (i.e. your phone line), there's hardware (mpeg encoding and decoding chips). What's holding things back??
RDBMS systems are certainly usefull, nobody said they weren't. However, OO databases do partition things more naturally, at the cost of performance. Often RDBMS systems are wrapped by a middle ware layer to hide the complexity and emulate OO behavior while retaining the performance and scalability associated with RDBMS systems.
Comparing OO Components to procedures is just plain silly. They are different concepts. Read Szyperski's book on components (and yes, non OO components do exist).
"The real world does not give a rats behind about fat-type trees. It will change any way it feels like."
The real world is also full of fools who make the same mistakes over and over because they think they are experts while in fact they are not.
"A graph-oriented approach like relational modeling and HAS-A relationships model this aspect of the real world better."
You should take a look at adaptive programming and aspect oriented programming. (use google to find the relevant material). Both approaches extend the OO paradigm to support what you want.
In the hands of somebody that does not understand OO, an OO language can cause quite a lot of dammage. Good use of any tool requires knowledge and you don't gain knowledge by staring at a book for half an hour. This article is provocative, and rightly so. Proclaimers of OO have claimed a lot and OO turned out to fail to be a silver bullet. But guess what? There are no silver bullets.
The truth is that OO languages are an excellent tool for structuring large, complex systems. Simply applying inheritence everywhere you can of course does not work. Using an OO language requires you think differently about how you structure your programs. Some people get this, some never will.
Of course OO has its limitations and there are many research initiatives to work around those limitations or provide alternatives. Falling back to procedural programming is really no option for anything but the most simple stuff. The article points out that you don't need an OO language to do things like components among others. That is true, but it is so much more convenient with a language that supports the concepts you are working with.
Another disturbing statement: "OOP eliminates the complexity of "case" or "switch" statements".
Read Martin Fowlers book on refactoring, it describes how to convert a switch statement into an inheritance based solution (the state pattern). Bottom line, if you understand OO, you know you don't need switch statements. And if you worry about performance, read Fowler's chapter on this topic and you'll see it is not an issue.
- players are expensive (2000$)
- dvd r and dvd rw will become available shortly and will be compatible with existing dvd
- in the long term, tapes have a higher production cost than dvd-r and dvd-rw
- we already have tivo like devices, what the hell do we need a digital vcr for?
Slashdot Mirror
I haven't encountered such a version, and I saw most versions since 4.0. Maybe you've got some weird configuration error, happens all the time. Best strategy is to update or at least reinstall.
Standardization has been the driving force behind the industrial revolution. Before the industrial revolution, you had to make your own parts if you wanted to put something together because the parts you'd buy elsewhere would almost certainly be incompatible.
For software this is no different. If you look at the win32 platform for instance, you'll see my point. MS has succeeded in getting people to use their components. This has resulted in a large number of applications. From a technical persective there's nothing revolutionary about their stuff (some might even claim it is buggy and has obvious flaws). The Java platform is another example, by providing the same set of components on each VM, applications can be WORA. Often you don't even have to test it works and you can just assume it works.
Now under linux there's always more than one solution to a single problem. Whether we are talking about package management, window managers or even glibc. You can't make much assumptions about what will actually be running on a random linux install. This is both an advantage and a disadvantage: you get choice but at the same time, application developers must assume the common denominator rather than the latest and greatest to be present.
alternatively, you can just click on the stop button in IE. This immediately stops animated gifs.
If you'd read a little further, you would have noticed that there's an answer to this question on the site. The main reason appears to be that maintaining TCP connections is to resource intensive for the job (they want something like 50000 or even more connections). On top of that TCP is a bit overkill for the purpose. The connections don't have to be reliable and timeouts are no real problem.
In fact it is really a smart way of reusing the way IP provides peer to peer connections. This DTCP thing sounds like it just might work (unlike gnutella for instance).
I think the average slashdot thread would compress very well :)
UNIX doesn't have one UI it has dozens of UIs. Some of them (Gnome, KDE) are quite good. Some are a bit more primitive. Each perfectly suits the needs of a small group of users. Most of them provide limited compatibility with the alternatives (meaning that typically applications will run but will not integrate well with other applications). The solution to this problem does cannot be found in creating another GUI but in getting GUI creators to agree on basic standards: how to cut and paste, how to embed components, how to define a menu structure, how to put an icon on the desktop, etc. As long as there's more than one way of doing things, there will be inconsistencies making UNIX user unfriendly
you don't get it, these properties of text based storage of sourcecode put an upper limit on a system's size.
Now c++ and c are typical examples where the fixed semantics of the language are not enough. Hence the use of preprocessors. If you were right, preprocessors would be redundant.
Obviously you haven't read Fowler's book on refactoring, otherwise you wouldn't claim such nonsense, I strongly recommend you do.
", but they are different conceptual entities, and should be stored and represented differently."
Just one question: why?
Answer: design uses different representations because sourcecode does not provide you with the constructs to model the design (i.e. the expressiveness of source code is very limited). Abandon the notion of text based storage and fixed semantics and that problem goes away. No more outdated designs! The system description contains all the information you need. You just have to query it in a smart way to get rid of the info you don't need.
"programmers have to do it, and managers have to build time and motivation into the the process to ensure that it happens."
Walk into your average large software company responsible for lets say around 5 million lines of code. Ask for the design documents. Presuming they don't throw you out, you'll find that in most cases either the design consists of some very outdated documents or that the sourcecode is the documentation. In real life people don't spend much time recovering designs unless they absolutely have to. Try convincing managers you want to spend the next three months just recovering the design of the product you're working on.
All programs start as vaporware. This is not a product anouncement, just a few people communicating some good ideas about the way we currently build software and a plan to improve it.
Since the very basis of their idea is not to have a text representation, you won't find code examples. I think the best way to think about working with this kind of systems is as manipulating parse trees (without actually having to parse!). For instance, variables will not be represented as identifiers. Rather you'll just point at the spot in the parse tree where the variable is pointing at (i.e. some subtree). Also the pointer can point to any subtree. So if, you've built some very complex algorithm, all you have to do to reuse it is point at it in the parse tree.
Text is unsuitable for representing structured data. That's why databases exist. In fact the only reason we store programs in ascii files is because programmers are reluctant to give up their vi/emacs editors.
Because of this:
1 - Languages have fixed semantics. The text files follow a syntax which cannot be changed. Consequently the semantics of the syntactical constructs are also fixed. Ever wanted to add multiple inheritance to Java? Well, you can't because the language spec forbids it.
2 - Automatic refactoring of code is difficult, regular expressions just are not powerfull enough to do the job. You need more structure to do it properly.
3 - You don't have first class representations of design concepts. Because of point 1 you can't add them to the language either. But worse, the most abstract details about your system are lost when you store them as text. You won't be able to recover them with a parser, simply because the information is no longer there. Ever tried to recover a highlevel design from just the source code? I remember seeing something about a dependency graph of the linux kernel just a few days ago. That's the best we can do with source code.
Now does this mean we have to give up on our editors? The answer is no. All that needs to change is the primary representation of the program. Once you have a representation, you can define a view on it to be able to manipulate it. Ascii is probably the simplest form of such a view. However, it is a rather limited view also. So we'll need more advanced tools as well.
Finally, I should add that eidola should visit microsoft's site: http://www.research.microsoft.com/ip/ to learn about their intentional programming project. Charles Simonyi had a similar vision years ago and apparently the project has advanced significantly since then. The information on the page is a bit limited unfortunately, but there are some very interesting papers.
Both the language, API and bytecode specifications are available at your convenience. The fact that ISO or any other organization has not put a stamp on it is not very relevant since all the relevant information is open. Lets call it an open industry standard. Closed propietary standards on the other hand do not have these properties. The win32 API, for instance, is largely undocumented and creating something such as wine is a long process of reverse engineering and testing of the binaries.
.Net is going to be similar to win32 and different from Java in that many of the APIs will be undocumented and in addition that there will be dependencies on the closed win32 API's. Because of this, vendor independent implementations of .Net, as is common for Java VMs and compilers, are highly unlikely to be available.
.Net specifications available and is even moving to standardize for instance C#. However, the bulk of .Net remains closed.
Now
Now the confusing part is that MS is making parts of their
I was thinking the other day how much equipment I have at home that just sits there doing nothing most of the time. The amount of energy consumed by these machines is quite large. Lets see:
- TV, standby most of the day
- Video, same thing
- Printer power supply (I rarely use the printer), always feels warm.
- Power supply of PC's. Even when turned of, the power supply is still active. One of my PC's actually has a second switch on the back to turn it off. However, I rarely use that switch.
- Sub woofer, always has a led blinking.
- Adsl modem, comes with a power supply too.
- Microwave
- Refrigarator
All these machines are using energy constantly, even when I'm not there, 24 hours a day, 365 days a year. That's a lot of energy.
1 your clone will be much younger than you
2 your clone will develop its own personality
3 your clone will have similar capabilities as you and might actually enslave you. So if you are not a nice person, chances are that your clone will have a bad character as well.
4 as far as I know clones still need a mother to grow in. After the embryo has been implanted, development is exactly the same as with normal embryos. So there's absolutely no need to treat them any different than you would treat normal children.
So don't worry.
I'm currently using a propietary banking package (homenet from abn-amro, I'm dutch in case you wonder). It sucks. During installation it threw a general protection error at me. Some of the buttons in the program have the same result. It is a 16 bit windows program, obviously written in the good old windows 3.1 days. It doesn't integrate with excel (I wish it did because that would allow for some nice analysis of the data). The GUI is a mess and on top of that it managed to fuck up its internal database.
In short: it's the worst piece of shit I've seen in a long time. Would I prefer an open source version? Yes, provided it was tested properly by somebody else than its developers. I would like to see banks stop developing their shitty propietary packages and start using the same software (propietary or open-source).
Your argument about propietary software is not valid since we're talking about client software. What they do on the server side is the bank's business. All they have to do is provide some standard, secure way of communication.
If it's written in Java it won't need any porting (provided there's a decent JVM on amiga).
Many software engineering programs are still stuck in teaching methods based on the waterfall model. You might call XP a process du jour but that doesn't mean it doesn't have things worth considering. The open ended, deliberately iterive way of developing software with frequent releases and strong emphasis on testing is good for a change. You should read Marting Fowler's essay on XP and other methods (available at www.martinfowler.com).
I find that most CS students are particularly ignorant about methodology. They're usually quite naive about such things as working in a team and making realistic plannings and tend to overestimate their own capabilities.
Now pair programming is already practiced in many CS schools and universities anyway. Add some course about testing and let different pairs team up to build something larger and you have an nice XP training course.
Because of the short iterations, it is possible for teachers to keep track of the student rather than having to wait for whatever is thrown over the fence at the end of the semester.
The ultimate test for any language is to write the compiler in its own language. Of course you'll need a separate language for writing the first versions of the compiler. Once that's in place you can write a compiler in the language it is supposed to compile. Doing so is usually a good test for your language. So ultimately you don't need C even for writing compilers.
C should only be used in those parts of a system that are really critical (critical as in a profiler shows that we need more performance here and there's no way to do it the language we're currently using). Using C when it's not needed costs you in terms of lines of code, development time, bugs (direct correlation with lines of code) and maintenance cost (same correlation again). Some might argue against LOC, but the other things have been shown to be true in very extensive and convincing casestudies (I could look up some references if you'd like to have them).
"It appears to me to be a straight shoot-out between C and Java, unless you can give us some of the "plenty of alternatives to C" (preferably ones with comprehensive libraries). Can someone who has worked on implementing a JVM indicate the performance of a machine with nameserver (along with httpd, ftd, etc) all written in Java?"
:) But now that we're discussing it: it would require more memory and depending on the way the data is stored, it should perform about as good as the C version provided a run-time optimizing JVM such as Hotspot is used. I wouldn't bet my life on the performance being as fast as C but I don't think performance would be seriously slower. But then there's only one way to find out. The memory usage is an issue however, and I wouldn't go as far as to recommend Java for the job. Probably C++ with a good library and preferably with a garbage collector or some other form of controlling memory allocation would take care of such things as buffer overruns and memory leaks. If you must use a procedural language there's always pascal, modula and derivatives. They're all capable of making system calls so libraries are not an issue + they probably come with some libraries of their own. But then why bother with obsolete paradigms at all. I know this is an issue for some but object oriented programming has been around for thirty years, good quality compilers and tools have been around for a long time, performance has ceased to be an issue in most situations.
I didn't start about Java
My whole point is that the technology exists today to prevent this kind of situations. There's no kind of excuse for this kind of bugs anymore.
I strongly oppose your suggestion that you can make programmers work harder and code better (if you know how, you're going to be rich). It hasn't happened in the past and I guarantee you it won't happen in the future. It's the technology that's fundamentally flawed and not the programmer.
>can you suggest another language that scores higher than C for such a low-level application?
C++, with some proper string class would have probably prevented the problem. I suspect a Java implementation would perform acceptably too. However, there are several procedural languages that would be suitable as well. There's plenty of alternatives to C. C may have been a nice language for this kind of programs in the seventies but its 2001 now. C had technical flaws, many of which were addressed in languages that came after it.
BTW. I disagree that this is a low level application. Device drivers are lowlevel applications. You typically find them at the bottom layer of the OSI model. Bind would classify for the application layer (almost at the top).
Then, you hammer down the fact that it is possible to create safe programs in C. But then my simple question is: why the hell do we have all these security leaks? Bind isn't an incident, it's just the latest leak to be found. Probably a solution will be provided in the form of a patch. However, this patch won't fix the fundamental problem, it will just fix the symptom and in the future more bugs will be found.
Cut the crap, one of the most important tools on the internet broke down because of a memory leak.
Of course it is possible to create good programs if you don't make any errors, duh. The problem is that humans do make errors. And since C provides little or no protection against these errors it is unsafe.
As long as we will use C for implementing these kind of things, there will be memory leaks. Of course C is a very performance efficient language, however, things like this make it unsuitable for security critical apps because you can never be 100% sure it doesn't have memory leaks.
Most security leaks are a direct consequence of using languages like C. People claim it is possible to program safely in C, however, incidents like this prove them wrong.
I though it was rather disappointing. The textures sucked, there was hardly any interactivity: no opening doors, moving robot arms or what so ever. Just these little question marks that when clicked pop up a text window.
Nevertheless, you get a pretty good impression of how the ISS is organized.
I can only watch one channel at the time. Why waste all this bandwidth on stuff you cannot possibly watch anyway. Put the tuner on the other side of the cable and switch channels remotely. All the extra bandwidth can be used for regular internet usage. As a matter of fact, why not stream that remaining channel over TCP/IP anyway?
I don't see the problem, the bandwidth exists (i.e. your phone line), there's hardware (mpeg encoding and decoding chips). What's holding things back??
And by the way, 60 channels is not enough.
RDBMS systems are certainly usefull, nobody said they weren't. However, OO databases do partition things more naturally, at the cost of performance. Often RDBMS systems are wrapped by a middle ware layer to hide the complexity and emulate OO behavior while retaining the performance and scalability associated with RDBMS systems.
Comparing OO Components to procedures is just plain silly. They are different concepts. Read Szyperski's book on components (and yes, non OO components do exist).
"The real world does not give a rats behind about fat-type trees. It will change any way it feels like."
The real world is also full of fools who make the same mistakes over and over because they think they are experts while in fact they are not.
"A graph-oriented approach like relational modeling and HAS-A relationships model this aspect of the real world better."
You should take a look at adaptive programming and aspect oriented programming. (use google to find the relevant material). Both approaches extend the OO paradigm to support what you want.
In the hands of somebody that does not understand OO, an OO language can cause quite a lot of dammage. Good use of any tool requires knowledge and you don't gain knowledge by staring at a book for half an hour. This article is provocative, and rightly so. Proclaimers of OO have claimed a lot and OO turned out to fail to be a silver bullet. But guess what? There are no silver bullets.
The truth is that OO languages are an excellent tool for structuring large, complex systems. Simply applying inheritence everywhere you can of course does not work. Using an OO language requires you think differently about how you structure your programs. Some people get this, some never will.
Of course OO has its limitations and there are many research initiatives to work around those limitations or provide alternatives. Falling back to procedural programming is really no option for anything but the most simple stuff. The article points out that you don't need an OO language to do things like components among others. That is true, but it is so much more convenient with a language that supports the concepts you are working with.
Another disturbing statement: "OOP eliminates the complexity of "case" or "switch" statements".
Read Martin Fowlers book on refactoring, it describes how to convert a switch statement into an inheritance based solution (the state pattern). Bottom line, if you understand OO, you know you don't need switch statements. And if you worry about performance, read Fowler's chapter on this topic and you'll see it is not an issue.
- players are expensive (2000$)
- dvd r and dvd rw will become available shortly and will be compatible with existing dvd
- in the long term, tapes have a higher production cost than dvd-r and dvd-rw
- we already have tivo like devices, what the hell do we need a digital vcr for?