As a side note I would like to point that if women _were_ smarter than men, most of the male readership of Slashdot would never get laid. Oh, wait, that already is the case !:-)
WaitForMultipleObjects(). Overlapped IO. Preemptive Kernel. SMP support from day one. Excellent thread support. Journaling filesystem. ACLs. Standard kernel driver API.
Linux and/or BSD have many of these features nowadays (although usually not together in a popular distribution or not widely used) but it took many years to get there, while NT had them at its _introduction_.
As a whole Windows is crap, but it is not technologically inferior.
I can't imagine know how this got moded "insightful".
It is not particularily insighful to claim that Windows NT is "the single most technologically inferior operating system to have ever seen the light of day".
It is, to say the least... ahem... terribly uninformed. Or, let's be honest here, it is plain old provocative trolling.
Windows has lots of problems - in design, complexity, usability, security - that's why many of us use alternatives - but _technologically_ it is quite advanced in many areas and Linux and BSD are still catching up.
I suspect that Dave Cuttler knows a little more about OS design than "petrus4":-)
And secondly, why would the software industry suddenly die with open source? We would still need software. Thus software would still need to be written. IBM and HP pay people to write open soite industry.
I haven't paid for software in a long time because I am using free software almost exclusively. Good for me. Now explain to me how the people who developed that free software will get paid. I do hope they will continue doing it out of the goodness of their hearts, while working two additional jobs at a supermarket and a fast food joint (somebody has to pay the bills).
IBM and HP sell hardware. RedHat sells support. Show me one company selling free software and doing well.
How about the USPTO paying back the damages ? That should teach them to think before granting absurd patents. I hope the USPTO files for bankrupcy and its employees go to prison. They are doing more damage than real criminals.
I am sure the Russians would not refuse saving the American astronauts if it came to it. They could do it for the publicity only.
Isn't it cheaper and faster to launch a classical rocket like Soyuz than the Shuttle, esp. for cases like this ? Perhaps that should the developed as a backup plan.
It is amazing how far we are from Sci Fi movies, even ones that are supposed to represent very near future if not present. I'll just throw all my childhood dreams in the garbage:-)
Call me what you like, but I -love- Steam and being ingrained in the independent game industry, I really like how it has been accepted, sometimes begrudgingly, by the game-buying public and geeks at large. I see its flaws, but I'm more of a silver lining guy myself.
This is the kind of service/platform that independent developers need, not shelf space. Games are becoming risk-adverse, and that means creativity suffers. Don't slam a great leap in technology and delivery. Instead, use it, provide some constructive criticism, but don't dismiss it.
You have no idea what the problem is at all, do you ?:-) I would like to see you play while your Internet connection is down. Think about that...
TFA tells us that Windows XP SP2 is more secure than Windows XP SP1 (unbelievable!!) and that there are fewer attackers targeting Linux and MacOS than Windows (hmmm - I wonder why ?).
Very thought provoking and innovative information indeed.
Re:The Problem With XML
on
Effective XML
·
· Score: 1
No, it wasn't compiling while you typed. There was a command line version (TPC.EXE) which was as fast as the IDE.
I believe these were the reasons for its speed: - The Borland Unit format (.TPU): allowed for very fast recalculation of dependancies and for linking in-memory (no need to store the executable to disk) - Recursive descent parser written in assembler - Single pass compiler - it didn't perform any optimizations and generated code on the fly.
Pascal is a really straight-foward language to compile and was designed for efficient LL(1) parsing.
All in all, very reasonable compromises for those times. It was a work of art.
Re:The Problem With XML
on
Effective XML
·
· Score: 1
The parent is not trolling! What are the moderators drinking today ?
Anyway, while I agree that XML suffers from both these problems (not very human readable and not efficiently parsable), there doesn't seem to be anything better and I am not sure there could be. These are contradictory goals.
That said, it is amazing how slow XML parsing can be! A 200-300 line file sometimes takes 100 ms to parse on a modern machine. Turbo Pascal used to compile a thousand lines of code in less then a second on a IBM PC/XT:-)
Computer companies should not be machines for making money. One would still hope they consist of and are lead by people who deeply care about and love what they do, about technological progress, and are involved with it.
The idea that the CEO only needs to care about "running" the business and making money is so cynical it gives me the shivers.
I can't deny that this is the contemporary reality of high tech companies. It is no wonder that the quality of _everything_ is down the drain these days - it is considered normal that released software has dozens of bugs. "Bugs are a part of life" - they say; and it is, thanks to the managers that don't give a shit about technology.
I don't know wbout Symbian, but getting licenses for Windows CE is not a problem for any size developer. I used to work for a very small company (less than 10 people) in 1999 and we developed an embedded device with Windows CE (2.1 I think). Getting the licenses was not a problem at all. The environment (to build custom CE images) wasn't expensive either (I don't remember exactly, but less than $1K).
A CE license in our miniscule volumes was about $50 (again, I don't remember exactly), which might be considered prohibitive for devices in the $200-300 range. I don't know.
OTOH, Linux in a phone is mighty cool. I doubt it will be available in the US, though.
Surely you mean 'unhashed' values, not value. A 160-bit hash value can map to about 4 billion 'unhashed' values of length 192-bits - good luck finding the right one:-)
I've been wondering myself what essential properties distinguish an object from a primitive value. If it looks and smells like an object syntactically, then surely it must be an object (doens't matter how it is implemented)?
C#'s primitives clearly aren't objects (they don't live in the heap, etc), however if you can refer to them as one, then they as well might be from the language standpoint. The question is with the automatic boxing do they mimic real objects in all aspects ?
I think the answer is no. They fail in one very important aspect. You can box a primitive variable , creating an object copy of it, however if the variable is modified the copy will not change.
Oh, yeah, that's why they are taking over the world. How many commercial projects (or free for that matter) are written in Ruby, Smalltalk and Eiffel compared to C/C++, Java and now C# ?
Note: I am not saying they are bad languages. Lisp could be added to the list too (no pun intended). However in order to be really successful, a programming language must combine power with reasonable efficiency (at least for now).
Some argue that the "pause" from GC is a problem. Maybe. Except that as mentioned before, malloc can also "pause" for arbitrarily long times. And a lot of work has been done on "concurrent" GC that doesn't pause. If you can afford paging in from disk (swap file), you can also afford GC's "pause".
I basically agree with you, but I must point out that a GC cycle potentially touches the entire heap and can cause massive paging. A good malloc() and free() implementation never does that. Additionally, GC operates well only when no more than 50% of the available heap is used. So I guess it is safe to say that when physical memory is tight, malloc() and free() have the advantage.
I'd much rather have everything be a true object; any performance issues can be handled by the compiler, runtime, or Moore's law.
That would be nice if it were possible. Unfortunately, it isn't (at least on a practical scale, esp. considering that we seem to be at the end of Moore's law). Turning everything into an object in a procedural language like Java would have a tremendous negative impact on performance, since currently there aren't practical optimizations to take care of that. Such a hypothetical language would be an immediate failure, even though it might look ellegant.
Yes, actually, it does. Have you checked it recently? The only overhead that natively compiled Java code would have over comparable C++ is that it always does array bounds checking. Other than that you just have to ask yourself, what kind of optimization can a static compiler (C/C++) do that a dynamic, profiling runtime compiler (Java) can't do?
Java suffers a penalty of about 500% on the average because of pointer chasing. There is no compiler or optimization that exist today that can optimize that, but Java as a language requires it, while C/C++ does not. (Think about how an array of complex numbers can be implemented in either languages, for example)
Static versus dynamic compilation has little to do with this, since both Java and C/C++ can be compiled statically or dynamically (although Java tends to benefit more from dynamic compilation).
Slashdot Mirror
I completely agree.
:-)
As a side note I would like to point that if women _were_ smarter than men, most of the male readership of Slashdot would never get laid. Oh, wait, that already is the case !
Or even better, the community might come to its senses and use Debian ... I heard rumours that apt already works there :-)
(Note: This is a joke! Nothing against SuSE)
Unfortunately small fonts with antialiasing enabled actually render _a lot worse_ with the byte code interpreter than with auto hinting. Go figure.
Sure. Off the top of my head:
WaitForMultipleObjects(). Overlapped IO. Preemptive Kernel. SMP support from day one. Excellent thread support. Journaling filesystem. ACLs. Standard kernel driver API.
Linux and/or BSD have many of these features nowadays (although usually not together in a popular distribution or not widely used) but it took many years to get there, while NT had them at its _introduction_.
As a whole Windows is crap, but it is not technologically inferior.
I can't imagine know how this got moded "insightful".
... ahem ... terribly uninformed. Or, let's be honest here, it is plain old provocative trolling.
:-)
It is not particularily insighful to claim that Windows NT is "the single most technologically inferior operating system to have ever seen the light of day".
It is, to say the least
Windows has lots of problems - in design, complexity, usability, security - that's why many of us use alternatives - but _technologically_ it is quite advanced in many areas and Linux and BSD are still catching up.
I suspect that Dave Cuttler knows a little more about OS design than "petrus4"
And secondly, why would the software industry suddenly die with open source? We would still need software. Thus software would still need to be written. IBM and HP pay people to write open soite industry.
I haven't paid for software in a long time because I am using free software almost exclusively. Good for me. Now explain to me how the people who developed that free software will get paid. I do hope they will continue doing it out of the goodness of their hearts, while working two additional jobs at a supermarket and a fast food joint (somebody has to pay the bills).IBM and HP sell hardware. RedHat sells support. Show me one company selling free software and doing well.
I just been digging through the USPTO records about this patent (its intruiging in a sadistic way)
You mean masochistic don't you !?!How about the USPTO paying back the damages ? That should teach them to think before granting absurd patents. I hope the USPTO files for bankrupcy and its employees go to prison. They are doing more damage than real criminals.
I am sure the Russians would not refuse saving the American astronauts if it came to it. They could do it for the publicity only.
Isn't it cheaper and faster to launch a classical rocket like Soyuz than the Shuttle, esp. for cases like this ? Perhaps that should the developed as a backup plan.
It is amazing how far we are from Sci Fi movies, even ones that are supposed to represent very near future if not present. I'll just throw all my childhood dreams in the garbage :-)
Call me what you like, but I -love- Steam and being ingrained in the independent game industry, I really like how it has been accepted, sometimes begrudgingly, by the game-buying public and geeks at large. I see its flaws, but I'm more of a silver lining guy myself.
:-) I would like to see you play while your Internet connection is down. Think about that...
This is the kind of service/platform that independent developers need, not shelf space. Games are becoming risk-adverse, and that means creativity suffers. Don't slam a great leap in technology and delivery. Instead, use it, provide some constructive criticism, but don't dismiss it.
You have no idea what the problem is at all, do you ?
TFA tells us that Windows XP SP2 is more secure than Windows XP SP1 (unbelievable!!) and that there are fewer attackers targeting Linux and MacOS than Windows (hmmm - I wonder why ?).
Very thought provoking and innovative information indeed.
No, it wasn't compiling while you typed. There was a command line version (TPC.EXE) which was as fast as the IDE.
I believe these were the reasons for its speed:
- The Borland Unit format (.TPU): allowed for very fast recalculation of dependancies and for linking in-memory (no need to store the executable to disk)
- Recursive descent parser written in assembler
- Single pass compiler - it didn't perform any optimizations and generated code on the fly.
Pascal is a really straight-foward language to compile and was designed for efficient LL(1) parsing.
All in all, very reasonable compromises for those times. It was a work of art.
The parent is not trolling! What are the moderators drinking today ?
:-)
Anyway, while I agree that XML suffers from both these problems (not very human readable and not efficiently parsable), there doesn't seem to be anything better and I am not sure there could be. These are contradictory goals.
That said, it is amazing how slow XML parsing can be! A 200-300 line file sometimes takes 100 ms to parse on a modern machine. Turbo Pascal used to compile a thousand lines of code in less then a second on a IBM PC/XT
Oh, what a load of cr*p.
Computer companies should not be machines for making money. One would still hope they consist of and are lead by people who deeply care about and love what they do, about technological progress, and are involved with it.
The idea that the CEO only needs to care about "running" the business and making money is so cynical it gives me the shivers.
I can't deny that this is the contemporary reality of high tech companies. It is no wonder that the quality of _everything_ is down the drain these days - it is considered normal that released software has dozens of bugs. "Bugs are a part of life" - they say; and it is, thanks to the managers that don't give a shit about technology.
I don't know wbout Symbian, but getting licenses for Windows CE is not a problem for any size developer. I used to work for a very small company (less than 10 people) in 1999 and we developed an embedded device with Windows CE (2.1 I think). Getting the licenses was not a problem at all. The environment (to build custom CE images) wasn't expensive either (I don't remember exactly, but less than $1K).
A CE license in our miniscule volumes was about $50 (again, I don't remember exactly), which might be considered prohibitive for devices in the $200-300 range. I don't know.
OTOH, Linux in a phone is mighty cool. I doubt it will be available in the US, though.
Surely you mean 'unhashed' values, not value. A 160-bit hash value can map to about 4 billion 'unhashed' values of length 192-bits - good luck finding the right one :-)
Can you clarify ?
Thanks for this reply.
I've been wondering myself what essential properties distinguish an object from a primitive value. If it looks and smells like an object syntactically, then surely it must be an object (doens't matter how it is implemented)?
C#'s primitives clearly aren't objects (they don't live in the heap, etc), however if you can refer to them as one, then they as well might be from the language standpoint. The question is with the automatic boxing do they mimic real objects in all aspects ?
I think the answer is no. They fail in one very important aspect. You can box a primitive variable , creating an object copy of it, however if the variable is modified the copy will not change.
Yeah, let's see you port that C++.NET application to anything :-)
Ahem, in C# everything is an object ??? Excuse me, but that is blatantly false.
Oh, yeah, that's why they are taking over the world. How many commercial projects (or free for that matter) are written in Ruby, Smalltalk and Eiffel compared to C/C++, Java and now C# ?
Note: I am not saying they are bad languages. Lisp could be added to the list too (no pun intended). However in order to be really successful, a programming language must combine power with reasonable efficiency (at least for now).
Some argue that the "pause" from GC is a problem. Maybe. Except that as mentioned before, malloc can also "pause" for arbitrarily long times. And a lot of work has been done on "concurrent" GC that doesn't pause. If you can afford paging in from disk (swap file), you can also afford GC's "pause".
I basically agree with you, but I must point out that a GC cycle potentially touches the entire heap and can cause massive paging. A good malloc() and free() implementation never does that. Additionally, GC operates well only when no more than 50% of the available heap is used. So I guess it is safe to say that when physical memory is tight, malloc() and free() have the advantage.
I'd much rather have everything be a true object; any performance issues can be handled by the compiler, runtime, or Moore's law.
That would be nice if it were possible. Unfortunately, it isn't (at least on a practical scale, esp. considering that we seem to be at the end of Moore's law). Turning everything into an object in a procedural language like Java would have a tremendous negative impact on performance, since currently there aren't practical optimizations to take care of that. Such a hypothetical language would be an immediate failure, even though it might look ellegant.
Yes, actually, it does. Have you checked it recently? The only overhead that natively compiled Java code would have over comparable C++ is that it always does array bounds checking. Other than that you just have to ask yourself, what kind of optimization can a static compiler (C/C++) do that a dynamic, profiling runtime compiler (Java) can't do?
Java suffers a penalty of about 500% on the average because of pointer chasing. There is no compiler or optimization that exist today that can optimize that, but Java as a language requires it, while C/C++ does not. (Think about how an array of complex numbers can be implemented in either languages, for example)
Static versus dynamic compilation has little to do with this, since both Java and C/C++ can be compiled statically or dynamically (although Java tends to benefit more from dynamic compilation).
So, you were lucky in more than one way :-) Did you eventually read all three of the volumes (and as other people have said, with exercises) ?