There I was, going 5mph, maybe not paying as much attention as I should have been, when someone got impatient & just turned in front of the car in front of me. So he of course stopped. I slammed on my brakes, but they sucked at the time, and I tapped the back of his truck.
From your description, the officer was justified in giving you a ticket. The specific ticket he gave you may not have been quite appropriate; I won't say without seeing the entire law, not the snippet you posted (if there's a clause A, I assume there's a B to follow...). It's reckless to be driving a car with brakes so pathetic that you can't stop at 5 mph or to be paying so little attention that you can't. You caused no damages or injuries, but in other circumstances you would have. Damn straight you weren't "exercising reasonable care for the protection of others." I have no sympathy.
I know that BBEdit is popular for HTML stuff, but I'm talking about programming stuff.
BBEdit is good for C/C++ as well as HTML. I don't use it personally; I don't have a Mac. But I've seen it do pretty well with C code. It has syntax highlighting, smart indenting, a ctags-like facility to quickly find bits of code, etc, transparent FTP (useful for development on a UNIX machine as well as just web stuff). I don't know what, if anything, it has as far as debugging goes, but for writing code, it definitely has some good features.
The other problem being that if the Fat32 test was run under Linux as well, all it's showing is how good the Linux driver is, not the filesystem itself.
That's true of all the filesystems being benchmarked. There's no way to seperate the performance of the filesystem from the performance of the driver, unless there are two drivers for the same filesystem on the same OS. Benchmarking it on another OS would change way too many things to get any meaningful results.
In fact, all of the filesystems except ReiserFS have drivers under other operating systems. (FAT32 is obvious. ext2, FreeBSD has it, I think there's an NT driver, etc. XFS was originally for IRIX.)
I disagree with this article's core point -- that one language is absolutely more powerful than another. He's right that Perl5 is more powerful than Perl4: it includes every Perl4 feature and a lot of new ones. But realistically, how often is this the case, other than a subsequent version of the same language?
He never formally defines "powerful", instead saying this:
All languages are equally powerful in the sense of being Turing equivalent, but that's not the sense of the word programmers care about. (No one wants to program a Turing machine.) The kind of power programmers care about may not be formally definable, but one way to explain it would be to say that it refers to features you could only get in the less powerful language by writing an interpreter for the more powerful language in it. If language A has an operator for removing spaces from strings and language B doesn't, that probably doesn't make A more powerful, because you can probably write a subroutine to do it in B. But if A supports, say, recursion, and B doesn't, that's not likely to be something you can fix by writing library functions.
So he thinks an operator to do something that a subroutine could do doesn't make the language more powerful, because there's another way to do it. Yet by what he just said, that all are Turing equivalent, there is always a way to do the same thing. It may be much more obfuscated, but it's there.
I would instead define powerful as this: providing a simple and elegant way to do a given task. This means powerful is not an absolute. A language like Perl is much more powerful at doing string manipulation because its string handling is part of the language. C obviously can do everything Perl can (Perl is written in C) but it's not as simple, so C is less powerful than Perl in this respect. Other languages are more powerful for other tasks. Some languages may be a poor choice for just about any task, but others are better for one thing than another.
Also, powerful is not all there is to think about. He mentioned execution speed. Readability is another concern. COBOL was written so even non-programmers could understand it. Whether you agree or disagree that this is important (I'm inclined to think it's a lost cause), it is another thing to consider. LISP...well, I just don't get it. I will eventually try again to (actually, I think it's going to come up in a class fairly soon), but I'm hardly alone. It does make it harder to find programmers for, etc.
I'm quite happy at 2.4. Is there any compelling reason why I would need 2.4.4?
YES! Upgrade now! 2.4.2 ate my ext2 filesystem. And I'm far from a unique case, there are weird filesystem bugs (both ext2 and reiserfs) in early 2.4 kernels. Lots of information about this on Kernel Traffic: (1)(2)(3)(4)(5)(6)(7)(8)(9).
Given all these problems, I'd say: don't run 2.4.x on a server yet. Run it on your desktop if you are daring (I do, even after it ate my filesystem.) but make backups of anything really important. Keep up-to-date on them; don't let a fixed bug eat your filesystem.
Well, I can't argue with that. I didn't realize there was a working compiler for this, I thought this was still in the design stage. Guess I should have looked around a bit more. I still think this could be confusing, but if the speed boost is there, maybe it's worth it.
The fact that you hate them doesn't make them useless. Consider a device control register where flipping a bit in one register changes the meaning of another register. The alternative is ugly pointers.
I did give reasons for hating them. To restate, I'd like to actually use the encapsulation for security (you can't mess with private stuff) instead of just type safety (it's easier not to mess with private stuff), like Java supports. This is impossible with unions, since members can overwrite each other's data. Not only does this feature not help me, it's impossible to do what I want because of this feature. It is really a matter of what you want the language to be used for.
This is an all-or-nothing thing with the addresses pointer type. If you can do pointer arithmetic and not unions (or vice versa), there's no gain for me.
The fragile base class problem is that you cannot extend the class.
Agreed. But what is causing the problem is not the way C++ conceptualizes polymorphism, that you add virtual operations to the base class. The real problem is an implementation detail. Java has the same concept but not the fragile base class problem, simply because of its implementation.
I'm not a low-level expert, but I believe it works something like this: given a base class with n virtual functions, an instance has a virttable[n]. Derived classes then have that same virttable[n+m] where m is their own virtual table. If the base class is then recompiled with virttable[n+1], code compiled with the new version expects the derived classes to have virttable[n+1+m] with the new spot being at index n...this isn't true, stuff breaks.
I really don't like the idea of an extension to class Foo. The point of the polymorphism is that you have a bunch of operations which can be performed on any Foo, but are implemented differently in subclasses. Conceptually, each subclass does the same thing, even though it has a different implementation. I can't reconcile this with your idea of extending class Foo only for class Bar. You seem to basically be creating multiple versions of Foo. I hope I can't make a pointer to a Foo_e (extended version of foo) point to a Foo, because then I'd get a "pure virtual function called" or something strange when I try to call a non-pure function.
Indentation-sensitive syntax. I've seen Python code and this seems to really improve readability. It would be especially great for a beginner's language, since it's important to stress proper indentation at the beginning.
Named and out-of-order parameters. Your example very clearly demonstrated the advantage of named operators for complex function parameters. This is a feature I don't think I've seen in any language but VHDL. (Though some Perl modules sort of cheat to get this functionality.)
Constrained generic types. I think this nicely solves the problem in C++ of getting confusing compile errors when you try to sort objects you've forgotten to define operator< for. This is especially important if plug in the types at runtime instead of compile-time, which it sounds like you intend to do.
Here's some things I don't like:
Expression reduction. This seems like it would be hard to implement and very confusing. Specifically, think about expressions like that within larger expressions. If I define "A*B", "A+B", "A/B", "A*B+C" and "(A+B)/C", what happens when I use "(A*B+C)/D"? What gets called? You could do "(A*B)" then "(A+B)/C" or "A*B+C" then "A/B" or just use the binary operators. There would be a bunch of different cases and its unclear what code would actually be executed. I think it creates too much confusion unless you can demonstrate that this would be a huge speed boost.
Variant records.
The first example you showed of these was basically using them as a replacement for unions. I hate unions. I like the way you can in Java set a security manager that controls what various bits of code can and can not do. But this depends on those bits of code only accessing other objects through the public interfaces. So unions in this case would be very bad for security, and they are very bad already for type safety. I really think we're past the point where we need to save a few bytes.
Second, you used a variable to size an array. Basically, you created much simpler syntax for dynamic memory management. I think this masks a lot of problems. What happens when you run out of memory trying to resize the array? You never explicitly resize the array, so I don't even know where you'd go about inserting code to deal with that failure. Second, what happens when that variable changes in some non-obvious way? Ie, through a pointer to it or through the union thing you described above. The array isn't resized, and nothing good can come of that.
Multiple kinds of pointers.
I can't help but see so many different types of pointers as needlessly complicated and confusing. What will you really be needing pointers for? You've defined "in", "out", and "inout" parameters, so pointers are no longer needed to pass by reference. They are needed for dynamically allocated memory. And they are needed for really low-level stuff that needs to address specific bits of memory.
I suggest instead doing this: having the simple pointer type you've defined which does not allow pointer arithmetic or pointers to arbitrary addresses. Having the address type you defined available if the security manager allows it (again, the idea of not only type safety but security from not allowing access to arbitrary regions of memory). autoptr really isn't that different from ptr...especially since in C++ it can be implemented without any language support at all. Leave the others out.
Function-based dynamic dispatch (polymorphism).
You talk about how C++ has the fragile base class problem, that new virtual functions can't easily be added to the base class. But I think you are misinterpreting where the problem lies. The problem is not that you have to add the virtual functions to the base class. That's just the way it has to be; otherwise, very weird stuff would happen when you try myBaseClass->onlyDefinedInInheritedClass() (remember, you don't know if a shape object is a rectangle or a triangle or whatever, that's the point of polymorphism). The real problem is the way C++ represents virtual function tables in compiled code. Java, for example, does not have this problem.
Really, quite a few of these features I don't like. It seems like they just add complication to the language spec without solving any huge problem. This will both make it harder for you to create a compiler and harder for people to learn/use the language.
California ranks 48th in the Union in per capita energy consumption. Compared to the other states, we do an excellent job of conservation, reducing demand, and developing new energy saving technologies.
...which is clearly because Californians are all supermen. It couldn't have anything to do with California's perpetually ideal climate...never cold (very low heating costs) and not incredibly hot either (moderate air conditioning costs).
perhaps what was being referred to was the incentive that quantum computers would bring to bear by making trad. crypto obsolete, thereby requiring more resources to be put into R&D for quantum crypto?
That's not how I read it, but even if that was what the original poster meant, I disagree. Current cryptography seems to work; no one is able to easily break it now, that we know of. But it isn't proven that there isn't a much easier way to factor numbers, even without a quantum computer. I think the motivation is already to pursue a perfectly* secure transmission method.
* - as much as anything is perfect...there's still the matter of the people on both ends, etc.
The more serious problem is that a prerequisite for quantum crypto is stronger quantum computers.
Umm...no. The quantum cryptography this article talks about involves tricky arrangement of photons that makes it essentially impossible for transmissions to be intercepted. This does not require quantum computers at all.
You also have failed to realize that perception is reality. If it seems faster, then it IS faster.
For GUIs, you're probably right. I'd be happier if I could click and see something change immediately to respond to my action, so I know my machine is doing what I want. I'd still be happier with this even if this meant that the actual work it was doing took longer.
But not everything is the GUI. There's plenty of other areas Linux (and the other systems KDE/GNOME run on, of course) that need actual CPU power and not just immediate responsiveness.
I read about one of the Linux real-time projects that talked about context switches more often. The solution they proposed was more complex than just changing the value of HZ (frequency of the system clock). I believe they had some algorithm to decide if more precise timing was required in a given interval and if so basically busy-loop instead of waiting for another interrupt. So, when more precise timing is required, it is available. When it is not, there is no performance impact. Sorry I don't remember the specifics or URL, but if you are really interested, you can look around the various real-time projects.
Getting sysadmin acceptance for overhauling the config file formats [...] is never going to happen either. So the problem is "stuck" and probably will be until someone forks a distribution. (Note that I'm trying to avoid anything mentioning a markup language that starts with X. Whoops...)
My hope is that when people see the XML files that MacOS X uses for much of its setup, they'll see the advantage, and some of that support might come. We'll have to wait and see...
you should prob try reading the README next time you attempt to install the nvidia drivers (and make sure mesa doesnt overwrite your glx.so's or your OpenGL will be done in software)
I did read that readme. I did the RPM installation, which found the lib[Gg][Ll]* stuff Mesa had left around and moved it out of the way. With pure software rendering, I get even worse than that...like 2 seconds per frame, not frames per second. So I do know it's doing something else. Also when games give info about the drivers they are using, it appears correct.
Thanks for the suggestion, anyway. I guess I will try again now...maybe my (much) faster processor will help, as it did help in Windows. (From a dual-Celeron 500 to an Athlon 1Ghz. Much higher FSB speed as well.)
Ok, Linux supporters...time to put up or shut up. If you truly want to help, lay out the money now.
Loki is doing a great job and I would like to see them continue. But I'm not going to run out and buy their games yet, for this reason: there are no good 3D graphics drivers for my nVidia GeForce. Yes, I'm aware that everyone says how great these drivers are...but I don't see it. Last time I tried them (admittedly, before I upgraded my processor, but given my CPU usage I don't think that was the bottleneck), I got around 15fps on Unreal...not playable. The drivers have other problems, too...remember, they're beta at best. Look at even the known bugs list: SMP crashes, bad memory leaks, etc.
Given that Unreal is that slow, there's absolutely no way I'm going to pay for Tribes2/Linux, when even the Windows version is known to be quite slow on a lot of systems. I'd consider buying 2D Loki games (I'd buy Starcraft in a second if they had it), but not 3D ones.
You want an open-source library to access AIM in any way the users choose. If the protocol is open, users will choose to not display banner ads.
AOL wants to get money off AIM...they run the servers that support it, it's reasonable for them to expect to make a profit, since they've put a significant investment into this. They are doing this by these banner ads. They don't like the idea of open-source libraries accessing their network because people can disable the banner ads, so advertisers will pay less...it's hurting their revenue. Consequently, they start this arms race with protocol modifications, MD5 checksums, etc.
Here's my solution:
Give AOL an alternative way to make money off AIM, removing their objection to open-source clients. Yes, I'm talking about...paying money to use AIM. I, and I think many other people, would not find it unreasonable to pay a modest fee to AOL in exchange for using their services in the way I want to use them. From everything I understand, ad revenue isn't that hot anyway as an income provider. I think AOL would be receptive to this idea.
I really think this is the only way to keep everyone happy. I, like you, want to use AIM any way I want. But I also understand that AOL wants money. Let's just give it to them in a way that lets us use open-source clients.
So you can only fix these problems by dropping legacy support.
Legacy applications would still run fine, but they would not take advantage of the new feature without being rewritten. In Berlin, they would automatically, since there more shared code.
Berlin should only provide unnamed shaped "canvases" that belong to different clients, it should not provide any "buttons" or "menus" or "windows", but conversely you should be able to easily (ie with no setup before the drawing function) do full PostScript and OpenGL graphics into these, and anti-aliased fonts, full UTF-8 formatting of text, and high speed placing of images with arbitrary linear transformations from user memory onto the screen.
Did you read the article? Do you have any idea what Berlin is trying to accomplish? Berlin allows graphic primitives (the buttons, menus, and windows you mentioned and more) to be moved to the server side. This has several obvious advantages...one being that there's much less network traffic, since higher-level messages are being passed around. Likewise, much fewer context switches in the local case. None of this would be true if they did what you wanted, exporting only a canvas to the client.
It seamlessly allows local and remotely-running programs to work together on a display
This is even more true for Berlin. As I understand it, Berlin moves a lot of the simple GUI code for stuff like buttons to the server side. This is a big performance advantage for Berlin over networks. Compare the two, creating a button and it being pressed and released:
X: Client tells server how to draw the button as unpressed. Server tells client a mouse event occurred. Client tells server how to redraw the button as unpressed. Server tells client a mouse event occurred. Client tells server how to redraw the button as unpressed again.
Berlin: Client tells server to create button. Server tells client button was pressed.
Obviously, this is much more efficient. The more high-level widgets the server side has, the more this is true. There's not only less bandwidth used, but much less latency since the server and client don't chat back and forth a bunch of times when only one is necessary for the server to tell the client what is going on.
It is flexible enough to allow programs to fully determine how it is to behave on lots of things -- X does not force you into a specific widget set or window decoration method, window placement behaviour, or anything else
I'm not sure how Berlin stands on this. I believe a while ago they were considering some sort of virtual machine so the client could send new GUI controls to the server to be run. Obviously it would still be possible for the client to create its own buttons and such even if this is not true, but I don't know how much of that would then need to be moved to the client side (negating the advantage I just discussed).
In any case, I don't think this is as great a feature as you make it out to be. I like comformity. I want all my applications to look and act the same, so I don't get confused. With Berlin's design, I could replace the list box widget in all of them at once, since they share the server's implementation. With X's current situation, none of them will ever be the same, since none of the toolkits have anything in common more abstract than Xlib. There are advantages to diversity, but there's huge advantages to shared code as well.
It is flexible enough to have extensions to help with some things. Lately we have seen extensions to add Anti-Aliased fonts and to aid in 3D display and moving picture display.
I believe this is also true of Berlin. (That it can have extensions, not that these specific extensions have been added.)
Many of the old ``problems'' of X, such as no anti-aliased fonts and poor support for moving pictures and 3D, are being addressed within the existing framework of X. This is because X is great, it allows for this sort of advancement while still having compatability.
But existing applications don't take advantage of extensions. As Stefan noted in the article, "The new renderer is usable as an extension, i.e. both the server as well as the client have to be aware of it." So you can only fix these problems by dropping legacy support. If X had sufficiently abstracted font drawing in the first place, like Berlin intends to, anti-aliasing could have been introduced without rewriting client-side code.
If you want to make your windowing stuff faster, if it's X's fault you can almost always fix it.
Not really. The performance problems I just discussed take place because of something fundamental in X: the client tells the server exactly what to draw. The server doesn't have any knowledge of something even as basic as a button.
Please don't get rid of the good to go with the new.
Again, these problems in X are fundamental.
If you have a problem with X, fix it. Don't just whine.
I do believe that's what the Berlin people intend to do...
No, it isn't. Type "setenv DISPLAY:0" into ksh, or "DISPLAY=:0; export DISPLAY" into sh. Or even "export DISPLAY=:0" into sh; only bash likes that, I think.
There are lots of choices for command interpreters, and there are lots of choices for graphical toolkits. The command interpreter is much easier to replace than the toolkit (the shell utilities aren't different, but the code using the toolkits is) but the parallelism is still there.
The information he provided to you should be trivial to disprove if this is a GUID. He gave specific meanings for each byte in the string. All you have to do (assuming you are an Earthlink customer, if not I don't see how this concerns you) is to find out what your string would be if the meanings given are correct. Then use a proxy server or packet sniffer to find out what your machine sends to remote sites. If the information is correct, the two will be identical. If it is false, maybe it is a GUID; it is also possible michael made a typo or something.
ECE has a lot more flexibility, you can essentially get a CS degree with only a few hardware classes, or you can get essentially a physics degree, or the more traditional EE curriculum...
At my school (the University of Iowa), this doesn't seem to be true. I'm a freshman ECE major, and it seems to me to be very rigid. It's a fairly set path all the way through. I'm thinking of changing to computer science because of this.
That agrees with what you said earlier, though, that the programs vary vastly from school to school. It might have a lot more flexibility elsewhere. Looking into the courses needed before choosing a major is definitely a good idea.
Maybe you're right, maybe I do just know where the workarounds are under Linux. But that does come back to Linux's basic openness...there are lots of diagnostic tools available (ps, strace, ltrace, gdb, lsof, netstat, lspci,/proc, etc) and the source is available, so it's very, very easy to see what's going on in the system and where problems are. So if I do know where the workarounds are under Linux...I think that's why. Windows just doesn't ship out of the box with those kinds of tools. Some I've managed to find (PrcView is a decent approximation of ps, for example), some I haven't.
As to my specific problems...I just checked, the "JavaScript debugging disabled" option is on. I assume that means debugging is disabled. So, that doesn't seem to be my problem, but thanks anyway.
For the curious, here are a couple of the weird problems I'm having with IE5.5 right now:
It doesn't like really long/complicated forms. Specifically, I was a Slashdot moderator recently. I tried to browse at -1/nested so I could moderate, but it didn't work out very well. The form elements just sort of came and went on the screen, completely unrelated to where they were placed in the HTML. I also tried it on a friend's computer, the same thing happened.
The scroll wheel occasionally stops working. I can always move it up and down, but if I hit the button, a circle is supposed to pop up that lets me scroll by moving the whole mouse. After some unknown trigger (I've been trying to find out what it is), Internet Explorer stops liking this. It instead pops up a dialog box basically saying that Internet Explorer screwed up and will quit. The current IE window then goes away when I hit OK. If I start another window and tap the scroll wheel again, the same thing happens. It doesn't get better unless I ctrl-alt-del explorer and let it restart. This might be some weird interaction with my mouse drivers, I should really check to make sure I'm at the latest version.
AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met.
Is there any reason quantum computing would be better at cracking AES than some other algorithm? It seems to me that if someone builds a quantum computer and gets it to crack stuff really fast, it wouldn't be hard to crack any algorithm really fast.
Luckily, there are other ways of keeping data secure. One I remember seeing was another quantum effect, dealing with the orientation of photons. Basically, it was a complicated but theoretically perfectly secure way to transmit data with light. The only real downside was that it's probably expensive to do, and no one's yet done it over a very long distance (say, to a satellite) so far. Plus, of course, that it only helps for transmission. You can't encode a hard drive like that.
Slashdot Mirror
There I was, going 5mph, maybe not paying as much attention as I should have been, when someone got impatient & just turned in front of the car in front of me. So he of course stopped. I slammed on my brakes, but they sucked at the time, and I tapped the back of his truck.
From your description, the officer was justified in giving you a ticket. The specific ticket he gave you may not have been quite appropriate; I won't say without seeing the entire law, not the snippet you posted (if there's a clause A, I assume there's a B to follow...). It's reckless to be driving a car with brakes so pathetic that you can't stop at 5 mph or to be paying so little attention that you can't. You caused no damages or injuries, but in other circumstances you would have. Damn straight you weren't "exercising reasonable care for the protection of others." I have no sympathy.
I know that BBEdit is popular for HTML stuff, but I'm talking about programming stuff.
BBEdit is good for C/C++ as well as HTML. I don't use it personally; I don't have a Mac. But I've seen it do pretty well with C code. It has syntax highlighting, smart indenting, a ctags-like facility to quickly find bits of code, etc, transparent FTP (useful for development on a UNIX machine as well as just web stuff). I don't know what, if anything, it has as far as debugging goes, but for writing code, it definitely has some good features.
The other problem being that if the Fat32 test was run under Linux as well, all it's showing is how good the Linux driver is, not the filesystem itself.
That's true of all the filesystems being benchmarked. There's no way to seperate the performance of the filesystem from the performance of the driver, unless there are two drivers for the same filesystem on the same OS. Benchmarking it on another OS would change way too many things to get any meaningful results.
In fact, all of the filesystems except ReiserFS have drivers under other operating systems. (FAT32 is obvious. ext2, FreeBSD has it, I think there's an NT driver, etc. XFS was originally for IRIX.)
I disagree with this article's core point -- that one language is absolutely more powerful than another. He's right that Perl5 is more powerful than Perl4: it includes every Perl4 feature and a lot of new ones. But realistically, how often is this the case, other than a subsequent version of the same language?
He never formally defines "powerful", instead saying this:
So he thinks an operator to do something that a subroutine could do doesn't make the language more powerful, because there's another way to do it. Yet by what he just said, that all are Turing equivalent, there is always a way to do the same thing. It may be much more obfuscated, but it's there.
I would instead define powerful as this: providing a simple and elegant way to do a given task. This means powerful is not an absolute. A language like Perl is much more powerful at doing string manipulation because its string handling is part of the language. C obviously can do everything Perl can (Perl is written in C) but it's not as simple, so C is less powerful than Perl in this respect. Other languages are more powerful for other tasks. Some languages may be a poor choice for just about any task, but others are better for one thing than another.
Also, powerful is not all there is to think about. He mentioned execution speed. Readability is another concern. COBOL was written so even non-programmers could understand it. Whether you agree or disagree that this is important (I'm inclined to think it's a lost cause), it is another thing to consider. LISP...well, I just don't get it. I will eventually try again to (actually, I think it's going to come up in a class fairly soon), but I'm hardly alone. It does make it harder to find programmers for, etc.
I'm quite happy at 2.4. Is there any compelling reason why I would need 2.4.4?
YES! Upgrade now! 2.4.2 ate my ext2 filesystem. And I'm far from a unique case, there are weird filesystem bugs (both ext2 and reiserfs) in early 2.4 kernels. Lots of information about this on Kernel Traffic: (1) (2) (3) (4) (5) (6) (7) (8) (9).
Given all these problems, I'd say: don't run 2.4.x on a server yet. Run it on your desktop if you are daring (I do, even after it ate my filesystem.) but make backups of anything really important. Keep up-to-date on them; don't let a fixed bug eat your filesystem.
I did actually implement it
Well, I can't argue with that. I didn't realize there was a working compiler for this, I thought this was still in the design stage. Guess I should have looked around a bit more. I still think this could be confusing, but if the speed boost is there, maybe it's worth it.
The fact that you hate them doesn't make them useless. Consider a device control register where flipping a bit in one register changes the meaning of another register. The alternative is ugly pointers.
I did give reasons for hating them. To restate, I'd like to actually use the encapsulation for security (you can't mess with private stuff) instead of just type safety (it's easier not to mess with private stuff), like Java supports. This is impossible with unions, since members can overwrite each other's data. Not only does this feature not help me, it's impossible to do what I want because of this feature. It is really a matter of what you want the language to be used for.
This is an all-or-nothing thing with the addresses pointer type. If you can do pointer arithmetic and not unions (or vice versa), there's no gain for me.
The fragile base class problem is that you cannot extend the class.
Agreed. But what is causing the problem is not the way C++ conceptualizes polymorphism, that you add virtual operations to the base class. The real problem is an implementation detail. Java has the same concept but not the fragile base class problem, simply because of its implementation.
I'm not a low-level expert, but I believe it works something like this: given a base class with n virtual functions, an instance has a virttable[n]. Derived classes then have that same virttable[n+m] where m is their own virtual table. If the base class is then recompiled with virttable[n+1], code compiled with the new version expects the derived classes to have virttable[n+1+m] with the new spot being at index n...this isn't true, stuff breaks.
I really don't like the idea of an extension to class Foo. The point of the polymorphism is that you have a bunch of operations which can be performed on any Foo, but are implemented differently in subclasses. Conceptually, each subclass does the same thing, even though it has a different implementation. I can't reconcile this with your idea of extending class Foo only for class Bar. You seem to basically be creating multiple versions of Foo. I hope I can't make a pointer to a Foo_e (extended version of foo) point to a Foo, because then I'd get a "pure virtual function called" or something strange when I try to call a non-pure function.
Thanks for the comments. They help.
I'm glad to hear it.
Here's some things I do like:
Indentation-sensitive syntax. I've seen Python code and this seems to really improve readability. It would be especially great for a beginner's language, since it's important to stress proper indentation at the beginning.
Named and out-of-order parameters. Your example very clearly demonstrated the advantage of named operators for complex function parameters. This is a feature I don't think I've seen in any language but VHDL. (Though some Perl modules sort of cheat to get this functionality.)
Constrained generic types. I think this nicely solves the problem in C++ of getting confusing compile errors when you try to sort objects you've forgotten to define operator< for. This is especially important if plug in the types at runtime instead of compile-time, which it sounds like you intend to do.
Here's some things I don't like:
Expression reduction. This seems like it would be hard to implement and very confusing. Specifically, think about expressions like that within larger expressions. If I define "A*B", "A+B", "A/B", "A*B+C" and "(A+B)/C", what happens when I use "(A*B+C)/D"? What gets called? You could do "(A*B)" then "(A+B)/C" or "A*B+C" then "A/B" or just use the binary operators. There would be a bunch of different cases and its unclear what code would actually be executed. I think it creates too much confusion unless you can demonstrate that this would be a huge speed boost.
Variant records.
The first example you showed of these was basically using them as a replacement for unions. I hate unions. I like the way you can in Java set a security manager that controls what various bits of code can and can not do. But this depends on those bits of code only accessing other objects through the public interfaces. So unions in this case would be very bad for security, and they are very bad already for type safety. I really think we're past the point where we need to save a few bytes.
Second, you used a variable to size an array. Basically, you created much simpler syntax for dynamic memory management. I think this masks a lot of problems. What happens when you run out of memory trying to resize the array? You never explicitly resize the array, so I don't even know where you'd go about inserting code to deal with that failure. Second, what happens when that variable changes in some non-obvious way? Ie, through a pointer to it or through the union thing you described above. The array isn't resized, and nothing good can come of that.
Multiple kinds of pointers.
I can't help but see so many different types of pointers as needlessly complicated and confusing. What will you really be needing pointers for? You've defined "in", "out", and "inout" parameters, so pointers are no longer needed to pass by reference. They are needed for dynamically allocated memory. And they are needed for really low-level stuff that needs to address specific bits of memory.
I suggest instead doing this: having the simple pointer type you've defined which does not allow pointer arithmetic or pointers to arbitrary addresses. Having the address type you defined available if the security manager allows it (again, the idea of not only type safety but security from not allowing access to arbitrary regions of memory). autoptr really isn't that different from ptr...especially since in C++ it can be implemented without any language support at all. Leave the others out.
Function-based dynamic dispatch (polymorphism). You talk about how C++ has the fragile base class problem, that new virtual functions can't easily be added to the base class. But I think you are misinterpreting where the problem lies. The problem is not that you have to add the virtual functions to the base class. That's just the way it has to be; otherwise, very weird stuff would happen when you try myBaseClass->onlyDefinedInInheritedClass() (remember, you don't know if a shape object is a rectangle or a triangle or whatever, that's the point of polymorphism). The real problem is the way C++ represents virtual function tables in compiled code. Java, for example, does not have this problem.
Really, quite a few of these features I don't like. It seems like they just add complication to the language spec without solving any huge problem. This will both make it harder for you to create a compiler and harder for people to learn/use the language.
California ranks 48th in the Union in per capita energy consumption. Compared to the other states, we do an excellent job of conservation, reducing demand, and developing new energy saving technologies.
...which is clearly because Californians are all supermen. It couldn't have anything to do with California's perpetually ideal climate...never cold (very low heating costs) and not incredibly hot either (moderate air conditioning costs).
I've never heard that before. Do you have a link to more info?
perhaps what was being referred to was the incentive that quantum computers would bring to bear by making trad. crypto obsolete, thereby requiring more resources to be put into R&D for quantum crypto?
That's not how I read it, but even if that was what the original poster meant, I disagree. Current cryptography seems to work; no one is able to easily break it now, that we know of. But it isn't proven that there isn't a much easier way to factor numbers, even without a quantum computer. I think the motivation is already to pursue a perfectly* secure transmission method.
* - as much as anything is perfect...there's still the matter of the people on both ends, etc.
The more serious problem is that a prerequisite for quantum crypto is stronger quantum computers.
Umm...no. The quantum cryptography this article talks about involves tricky arrangement of photons that makes it essentially impossible for transmissions to be intercepted. This does not require quantum computers at all.
Please read the article next time.
You also have failed to realize that perception is reality. If it seems faster, then it IS faster.
For GUIs, you're probably right. I'd be happier if I could click and see something change immediately to respond to my action, so I know my machine is doing what I want. I'd still be happier with this even if this meant that the actual work it was doing took longer.
But not everything is the GUI. There's plenty of other areas Linux (and the other systems KDE/GNOME run on, of course) that need actual CPU power and not just immediate responsiveness.
I read about one of the Linux real-time projects that talked about context switches more often. The solution they proposed was more complex than just changing the value of HZ (frequency of the system clock). I believe they had some algorithm to decide if more precise timing was required in a given interval and if so basically busy-loop instead of waiting for another interrupt. So, when more precise timing is required, it is available. When it is not, there is no performance impact. Sorry I don't remember the specifics or URL, but if you are really interested, you can look around the various real-time projects.
Getting sysadmin acceptance for overhauling the config file formats [...] is never going to happen either. So the problem is "stuck" and probably will be until someone forks a distribution. (Note that I'm trying to avoid anything mentioning a markup language that starts with X. Whoops...)
My hope is that when people see the XML files that MacOS X uses for much of its setup, they'll see the advantage, and some of that support might come. We'll have to wait and see...
you should prob try reading the README next time you attempt to install the nvidia drivers (and make sure mesa doesnt overwrite your glx .so's or your OpenGL will be done in software)
I did read that readme. I did the RPM installation, which found the lib[Gg][Ll]* stuff Mesa had left around and moved it out of the way. With pure software rendering, I get even worse than that...like 2 seconds per frame, not frames per second. So I do know it's doing something else. Also when games give info about the drivers they are using, it appears correct.
Thanks for the suggestion, anyway. I guess I will try again now...maybe my (much) faster processor will help, as it did help in Windows. (From a dual-Celeron 500 to an Athlon 1Ghz. Much higher FSB speed as well.)
Ok, Linux supporters...time to put up or shut up. If you truly want to help, lay out the money now.
Loki is doing a great job and I would like to see them continue. But I'm not going to run out and buy their games yet, for this reason: there are no good 3D graphics drivers for my nVidia GeForce. Yes, I'm aware that everyone says how great these drivers are...but I don't see it. Last time I tried them (admittedly, before I upgraded my processor, but given my CPU usage I don't think that was the bottleneck), I got around 15fps on Unreal...not playable. The drivers have other problems, too...remember, they're beta at best. Look at even the known bugs list: SMP crashes, bad memory leaks, etc.
Given that Unreal is that slow, there's absolutely no way I'm going to pay for Tribes2/Linux, when even the Windows version is known to be quite slow on a lot of systems. I'd consider buying 2D Loki games (I'd buy Starcraft in a second if they had it), but not 3D ones.
Very interesting. Where'd you get that information? I'd love to read more...
In essence, it seems to me the problem is this:
Here's my solution:
Give AOL an alternative way to make money off AIM, removing their objection to open-source clients. Yes, I'm talking about...paying money to use AIM. I, and I think many other people, would not find it unreasonable to pay a modest fee to AOL in exchange for using their services in the way I want to use them. From everything I understand, ad revenue isn't that hot anyway as an income provider. I think AOL would be receptive to this idea.
I really think this is the only way to keep everyone happy. I, like you, want to use AIM any way I want. But I also understand that AOL wants money. Let's just give it to them in a way that lets us use open-source clients.
A slight correction to what I said:
So you can only fix these problems by dropping legacy support.
Legacy applications would still run fine, but they would not take advantage of the new feature without being rewritten. In Berlin, they would automatically, since there more shared code.
Berlin should only provide unnamed shaped "canvases" that belong to different clients, it should not provide any "buttons" or "menus" or "windows", but conversely you should be able to easily (ie with no setup before the drawing function) do full PostScript and OpenGL graphics into these, and anti-aliased fonts, full UTF-8 formatting of text, and high speed placing of images with arbitrary linear transformations from user memory onto the screen.
Did you read the article? Do you have any idea what Berlin is trying to accomplish? Berlin allows graphic primitives (the buttons, menus, and windows you mentioned and more) to be moved to the server side. This has several obvious advantages...one being that there's much less network traffic, since higher-level messages are being passed around. Likewise, much fewer context switches in the local case. None of this would be true if they did what you wanted, exporting only a canvas to the client.
It seamlessly allows local and remotely-running programs to work together on a display
This is even more true for Berlin. As I understand it, Berlin moves a lot of the simple GUI code for stuff like buttons to the server side. This is a big performance advantage for Berlin over networks. Compare the two, creating a button and it being pressed and released:
X: Client tells server how to draw the button as unpressed. Server tells client a mouse event occurred. Client tells server how to redraw the button as unpressed. Server tells client a mouse event occurred. Client tells server how to redraw the button as unpressed again.
Berlin: Client tells server to create button. Server tells client button was pressed.
Obviously, this is much more efficient. The more high-level widgets the server side has, the more this is true. There's not only less bandwidth used, but much less latency since the server and client don't chat back and forth a bunch of times when only one is necessary for the server to tell the client what is going on.
It is flexible enough to allow programs to fully determine how it is to behave on lots of things -- X does not force you into a specific widget set or window decoration method, window placement behaviour, or anything else
I'm not sure how Berlin stands on this. I believe a while ago they were considering some sort of virtual machine so the client could send new GUI controls to the server to be run. Obviously it would still be possible for the client to create its own buttons and such even if this is not true, but I don't know how much of that would then need to be moved to the client side (negating the advantage I just discussed).
In any case, I don't think this is as great a feature as you make it out to be. I like comformity. I want all my applications to look and act the same, so I don't get confused. With Berlin's design, I could replace the list box widget in all of them at once, since they share the server's implementation. With X's current situation, none of them will ever be the same, since none of the toolkits have anything in common more abstract than Xlib. There are advantages to diversity, but there's huge advantages to shared code as well.
It is flexible enough to have extensions to help with some things. Lately we have seen extensions to add Anti-Aliased fonts and to aid in 3D display and moving picture display.
I believe this is also true of Berlin. (That it can have extensions, not that these specific extensions have been added.)
Many of the old ``problems'' of X, such as no anti-aliased fonts and poor support for moving pictures and 3D, are being addressed within the existing framework of X. This is because X is great, it allows for this sort of advancement while still having compatability.
But existing applications don't take advantage of extensions. As Stefan noted in the article, "The new renderer is usable as an extension, i.e. both the server as well as the client have to be aware of it." So you can only fix these problems by dropping legacy support. If X had sufficiently abstracted font drawing in the first place, like Berlin intends to, anti-aliasing could have been introduced without rewriting client-side code.
If you want to make your windowing stuff faster, if it's X's fault you can almost always fix it.
Not really. The performance problems I just discussed take place because of something fundamental in X: the client tells the server exactly what to draw. The server doesn't have any knowledge of something even as basic as a button.
Please don't get rid of the good to go with the new.
Again, these problems in X are fundamental.
If you have a problem with X, fix it. Don't just whine.
I do believe that's what the Berlin people intend to do...
The command line is a consistent interface.
No, it isn't. Type "setenv DISPLAY :0" into ksh, or "DISPLAY=:0; export DISPLAY" into sh. Or even "export DISPLAY=:0" into sh; only bash likes that, I think.
There are lots of choices for command interpreters, and there are lots of choices for graphical toolkits. The command interpreter is much easier to replace than the toolkit (the shell utilities aren't different, but the code using the toolkits is) but the parallelism is still there.
The information he provided to you should be trivial to disprove if this is a GUID. He gave specific meanings for each byte in the string. All you have to do (assuming you are an Earthlink customer, if not I don't see how this concerns you) is to find out what your string would be if the meanings given are correct. Then use a proxy server or packet sniffer to find out what your machine sends to remote sites. If the information is correct, the two will be identical. If it is false, maybe it is a GUID; it is also possible michael made a typo or something.
ECE has a lot more flexibility, you can essentially get a CS degree with only a few hardware classes, or you can get essentially a physics degree, or the more traditional EE curriculum...
At my school (the University of Iowa), this doesn't seem to be true. I'm a freshman ECE major, and it seems to me to be very rigid. It's a fairly set path all the way through. I'm thinking of changing to computer science because of this.
That agrees with what you said earlier, though, that the programs vary vastly from school to school. It might have a lot more flexibility elsewhere. Looking into the courses needed before choosing a major is definitely a good idea.
Maybe you're right, maybe I do just know where the workarounds are under Linux. But that does come back to Linux's basic openness...there are lots of diagnostic tools available (ps, strace, ltrace, gdb, lsof, netstat, lspci, /proc, etc) and the source is available, so it's very, very easy to see what's going on in the system and where problems are. So if I do know where the workarounds are under Linux...I think that's why. Windows just doesn't ship out of the box with those kinds of tools. Some I've managed to find (PrcView is a decent approximation of ps, for example), some I haven't.
As to my specific problems...I just checked, the "JavaScript debugging disabled" option is on. I assume that means debugging is disabled. So, that doesn't seem to be my problem, but thanks anyway.
For the curious, here are a couple of the weird problems I'm having with IE5.5 right now:
The article said this...
AES was specified (and is expected) to remain a standard for at least as long as DES, and to protect data for even longer, and barring a major development (such as faster-than-forseen developments in quantum computing), this standard will likely be met.
Is there any reason quantum computing would be better at cracking AES than some other algorithm? It seems to me that if someone builds a quantum computer and gets it to crack stuff really fast, it wouldn't be hard to crack any algorithm really fast.
Luckily, there are other ways of keeping data secure. One I remember seeing was another quantum effect, dealing with the orientation of photons. Basically, it was a complicated but theoretically perfectly secure way to transmit data with light. The only real downside was that it's probably expensive to do, and no one's yet done it over a very long distance (say, to a satellite) so far. Plus, of course, that it only helps for transmission. You can't encode a hard drive like that.