Hmm? I thought I said that... However, I have a problem with something in your post: this optimization doesn't hurt apps that use multiple cores because it is enabled only when one core is idle.
Sorry to be so pedantic. I'm sure you knew that, but I don't like leaving misinformation lying around for other readers, even if this is Slashdot. grin
This "single thread acceleration" will have to be supported by the OS?
I doubt it. My reading of the article is that the CPU detects when only one core is in use and does everything itself. But, even if it does require some level of OS support, I wouldn't worry about Linux's support of it (or of UEFI, for that matter, as Linux runs quite well on Macs and Intel does a good job of supporting Linux, anyway). Linux even has support for hotplugging CPUs, so, even if it comes to that (and I doubt it will), then it should still work.
Does it have the potential to break a half-bad application?
Any change in a CPU's implementation should not be observable to anyone unless the observer knows to look for it (e.g. with the CPUID instruction). Intel won't release a chip that breaks existing apps. Besides, if you think about it, if apps work on a single-core CPU, why shouldn't they work on a dual-core CPU with one core disabled?
Why should they? The advent of multicore CPUs won't actually hurt single-threaded apps. They just won't get any faster. For most things, that's fine. Legacy apps that aren't changing are most likely already fast enough. Besides, not everything can be parallelized properly, anyway. Multithreaded applications will become more popular, but I think this trend will affect new applications much more than old ones because it's just not that important. Even new apps don't necessarily need parallelization because many things are "fast enough" on a single core.
By the way, I actually hope that many things never become multithreaded. In my experience, most coders simply aren't capable of thinking threading through clearly. For many people, the concept is just too complex. Hopefully, compilers will improve to the point where many things can be parallelized without the coder having to know very much, if anything, about the threading involved, but, today, we're nowhere near that. We desperately need higher-level threading primitives in computer science.
It makes perfect sense that you'd still try to speed up single-threaded applications. After all, if you have 4 cores, then any speedup to one core is a speedup to all of them. I realize that's not what this article is about. In this case, they are speeding up one at the expense of the other, but the article's blurb makes it sound like Intel shouldn't be interested in per-core speedups when that is clearly false.
You obviously know nothing of what you are speaking. You have never seen a security bulletin from ATI or nVidia because they both fix the bugs they find silently or ignore the bugs. Have you heard of the Month of Kernel bugs? If not, I suggest you look it up and take note of where all the Windows kernel flaws were found - wireless drivers.
Furthermore, I have it on good faith from a friend who once worked at ATI that their driver, at least, is full of security holes.
I had lots of problems. First, the glibc upgrade failed because certain extra files existed. I accidentally rm'ed the wrong file (stupid of me, yes) and then had to repair with a live CD. I then rm'ed the right files and my system was b0rked until I ran ldconfig to regenerate the ldconfig file. Finally, I could upgrade glibc. However, at this point, apt-get won't boot because glibc is inconsistent. I then use dpkg to unpack a bunch of packages until apt-get works again and continue the upgrade.
Next, I reboot. The default kernel doesn't boot due to a bug in the nvidia fb driver. Fine. I pass video=vga to the kernel and reboot. Now it freezes detecting my sata drives. Wonderful.
I try to boot my custom built 2.6.18 kernel which I know works. Panic. Beautiful. I look at the grub command line and Ubuntu has put a large string of hex characters into the root= parameter. I remove that, remove the "splash" and "quiet" that it also felt like adding, and then I finally had a working system.
Unless you are comfortable manually repairing glibc and editing kernel command lines, I suggest you don't go anywhere near this upgrade.
MS bashing is fun and all, but do you have any idea how a kernel works? Anything can step on anything else. An off-by-one error in a kernel can be catastrophic to any number of things. This one does sound suspicious, but keep in mind that the code that is failing is probably only peripherally related to the code that was patched. They say they patched a buffer overflow. Maybe the buffer was already being overflowed by the compression code and patching it caused the compression to break. That might explain why it's the last 4000 bytes or so in a file that's almost a multiple of 4K.
The real question is why they didn't catch it in testing, especially with MS's extra-long patch process where they spend so much time testing (that is the current excuse for the months that pass between reports and patches, right?). Being "extra careful" does not save you from these types of bugs and being a programmer for as long as you have, you ought to know that being careful just doesn't cut it.
I should also add that lesbians could also get it for fairly obvious reasons. That leaves the only woman-to-woman transmission vector being bisexual women or women who have one-off lesbian experiences.
Not necessarily. A vaccine could be useful even if it causes birth defects as long as it doesn't cause *genetic* defects in the offspring because then, we could vaccinate all males, for example. That would help quite a bit because it would prevent aids from being transmitted via heterosexual and gay intercourse, leaving only lesbian and non-intercourse methods of transmission (and, I believe that woman-to-woman transmission is a lot more difficult than the other forms). I think that could go a very long way in stopping the AIDS epidemic in Africa.
Whether the African people would use AIDS vaccines is an entirely separate issue of which I am both unqualified and reluctant to speak.
The incredulity that this mathematician might have been more interested in the challenge of the work than fame and fortune in the Western world practically oozes from each sentence.
What I think is harder for most people to comprehend is why he would turn down the *recognition* rather than the money. There are many reasons why someone might not care about money, but there are very few people who have such talent who want to simply hide it under a rock. This guy doesn't seem to care at all about being recognized for his work, so much so that he is quite willing to hand it to other people to finish for him when it's quite possible that those other people may have tried to take credit. That's the bit that I have trouble understanding. Genius is usually accompanied by a certain amount of conceit. Just look at Isaac Newton for one good example.
You ought to learn a little more about Agile software development. You pretty much prove the point.
Even planned communities are done incrementally. As you say, "new parts of the community can be grafted on easily". The key here is that you have new parts over time. Agile software is like a planned community, if done right: you lay down all the parts using techniques that you hope will be future-proof. You still plan at every stage before developing in Agile software, and you use accepted practice to try to prevent problems in the future. You have no way of knowing what might come in the future (in a planned city or a software project), so the best you can do is follow a few principles that you hope will keep your project maintainable.
Nobody (I hope) is promoting building software by throwing code together until something works. If you were under the impression that's what Agile programming is, then you've either never used it, or you've been working under bad management too long. You don't write code by the seat of your pants in Agile programming just as you don't drop houses in just any location at all in a city, planned or otherwise.
Group 2 will be like "But IBM/RedHat/Novell won", and MS says "They got off b/c of a judge's ruling dismissing half the case"
I know that's what you were getting at, and that's what my post was meant to address. It's not a technicality because SCO couldn't make a case. The judge gave them lots of rope and SCO hung themselves with it (at least, as far as the dismissed claims go). However, you are also missing the point. If MS wants to spin this as Linux "dodging a bullet", then they can do that whether or not it's just a technicality. Why do you think that MS will tell the truth? MS sales reps can and will say whatever they like about the SCO fiasco, and you can bet that, if they do speak about it, it will be to the detriment of Linux regardless of the facts of the case.
Here's an example. Let's say that IBM hadn't filed to have these dismissed and all the claims were dismissed at some later date simply because of their lack of merit. Why would that stop MS? They could claim that IBM had not produced enough in discovery (IBM lost some versions of AIX, I believe), so SCO was at a disadvantage. Or MS could just say that the lawsuit was bad enough. After all, even if SCO loses, who wants to face a lawsuit like that? Or maybe MS might just say, "SCO lost only because they didn't have the financial resources to battle IBM. Just wait until Linux infringes on our patents." The possibilities are endless. If I were you, I wouldn't worry too much about this ruling helping MS spread FUD.
That's true, to a point. After all, this is a rejection of the claims based on the lack of specificity instead of a lack of merit. However, there are two reasons why I have no doubt that it cannot be construed as you say. First, SCO was ordered by the court to provide that specificity and was given ample time to do so. That they still did not provide it demonstrates that SCO could not provide that specificity. Second, there are over 100 claims left to SCO. I expect all of them to be demolished by IBM in the coming months.
Oh, and one other point: the judge's point is that SCO failed to allege an actual violation. How could Linux have "dodged a bullet" when all of the dismissed claims were not actually real claims? If I say that Linux has copied Microsoft's USB infrastructure, for example, does that mean that, when I can't offer any proof, that Linux has "dodged a bullet"? Or, more likely, does it marganilize any other claims I might make?
Now I am mainly a Delphi programmer, but worked enough with VB to tell you al your "problems" with VB are really no issues
I have disagree with you. While all the problems can be solved (I know; I've solved them all in the past, and more nasty things besides), they are still problems. The fact that they have to be solved just adds complexity to the project and many of your solutions aren't. For example, pushing the window procedure code into another control and using that control in your project helps compartmentalize the problem, but you still need to debug the control, which will still crash when you hit stop. Using third party controls to subclass the window can solve that problem, but now you've got to include that other control and worry about any licensing issues. I'm not saying these are big problems, but they do increase the complexity of the project.
For Low level COM use, check the book "Advanced Visual Basic 6: Power Techniques for Everyday Programs" for a little hand holding with the normal VB COM check the book "Dan Appleman's Developing COM/ActiveX Components with VB6: A Guide to the Perplexed"
I don't know what you mean by "low-level com" (maybe manipulating IUnknown et al directly?) but I've had my share of trying to manipulate the COM machinery in VB and it's never pretty. Usually, though, that type of thing is unnecessary. Only under strange circumstances where you need to implement an interface that has a reserved name as a method or a method that doesn't return an HRESULT do you have to worry about that very much (it's been a very long time since I've had to do that in VB, so I don't recall all the tricks anymore). However, I'd hardly use that as an example as to how the problem can be solved. Yes, it can almost always be done, but it just adds so much complexity that it's often not worth it. As you say, VB programmers are cheap. They are cheap for a reason. What's the point of writing code that does all this if none of your coworkers can maintain it?
With VB (just selecting the WebClass template) you could define dinamic web pages generators using the same object model used for ASP, but much faster and using vba instead of vbscript (WebClass and DHTML class where the main additions to vb6 with respect to vb5, there where incremental additions to Data binding, data source, data consumer, object persistence, DCOM/MTS integration the rest where librarys like ADO, Dictionary and FileSystem Object and dumbed down designers like DataEnviroment or DataReport and a bunch of bad quality wizards)
I didn't say you couldn't do cool things with VB. Sometimes it is the right tool for the job. VB makes some tedious things (in C++) very easy. However, that doesn't mean there aren't problems.
VB5 its faster than VB6, but VB6 its not slower than.Net, at least not if you know what you are doing
I'd argue that, if VB6 is faster than.NET, then you should probably find a better.NET programmer. In my experience, VB6 is slower than even Java (though, admittedly, Java has been getting a lot faster in recent years). You can say I don't know what I'm doing, but I've written a lot of VB code and I've produced some very fast VB code. It's just that if I spend the same amount of time optimizing C++ or.NET code, VB always comes out the loser.
Some languages like VB dont suport inheritance, but multiples interfaces; and the design of the object model must be developed from a different point of view
A different point of view? While you do have to keep it in mind, you can't escape the fact that you simply cannot do many things in VB as easily as you can in other languages. You are forced into a certain development model that doesn't respond well to changing requirements. As others have commented, you can crank out new UIs at a
Note how MyClass needs to have all the functions in MyInterface (prefixed by MyInterface_). If I add another function to MyInterface, I need to modify every class that implements it (like MyClass). That's the same as Java and C#, except that in those languages, I have inheritance, so if I have a parent class which implements an interface, then I just have to add the new interface function to the parent class and all the child classes get it. In VB, all classes would have to explicitly implement the interface, so I'd have to modify every class that implements that interface, since there is no parent class with an inherited implementation.
Ugh, so many bad memories coming back. I agree with pretty much all you had to say, but I do have some additional comments.
Okay, well this one doesn't really have a workaround other than writing reams of hookup code - this is a limitation of COM, and VB was (eventually) written to be a top-notch COM development system. In my experience, building hugely interdependent object models is unnecessary for nearly all client applications, which is usually what you're building with VB6.
I know why they did it that way, but is there really any reason why they couldn't have allowed inheritance on private classes where they don't ever need to expose the class via a COM interface (I'm sure they still do, but there's no reason they have to)? Furthermore, though COM doesn't have the idea of inheritance, it can be faked by delegation, which could have been done behind the scenes by the language.
I use the Windows API type library originally developed by Bruce McKinney. One reference added to your project and thousands of Win32 functions, constants, and structures are available. The compiler will only add in the items you use to your executable, so you're not linking in the full ~750K of declarations.
I remember that. It was pretty handy, but many of the large projects, which weren't under my control, were very picky over their dependencies, so I couldn't use it. I know it's irrational, but that's the way things go sometimes.
Yeah, a struct with a pointer to another struct can be a pain - but again, that's a pretty rare item. It's easy enough to pass structures directly to the API - you just need to be careful about how you declare your API calls.
I remember it came up with the common dialogs (the font chooser dialog requires a struct with a pointer to a LOGFONT struct). You might wonder why I was using the API for the common controls - the simple answer is that I didn't want to include a large OCX in that particular project (that was before you could reasonably expect it to be already on most users' PCs and most users were on dial-up).
I haven't. I can't imagine why I would. Frankly, I can't imagine looking at the assembly output of some JITted Java piece, or a C++/MFC app, or damn near anything other than assembler, or (maybe) hand-tuned C. VB6 has got a great debugger that allows you to inspect and modify any variable and execute program functions on the fly.
I had to do this on a few occasions. VB often fails with very weird error messages. E.g. Out of memory seems to be a rather common one. Once, I was debugging a problem where calling an interface would fail in strange ways. It turned out that the interface had a function where it took a reference to an ADO object and the client didn't have ADO installed, thus making the cast to that interface fail with a very unhelpful error message. Another example is when you have bugs in the libraries the VB app is calling. Once, I found a bug in Crystal Reports like this, for example.
With.NET there are plenty of tools for inspecting and debugging the IL that it creates, so such tools do exist for.NET and it isn't that far fetched that you'd want to do something similar for VB.
I am little surprised that you saw an order of magnitude difference.
I'm not, after seeing the generated machine code. For example, after every single statement, VB puts in an "fnclex" instruction, which means "clear floating point exception", even if the instruction wasn't a floating point instruction. Just about every VB statement is implemented with several function calls to the VB runtime. Just making those calls adds a significant amount of overhead. Add to that all the redundant bounds checking you do and you have a recipe for really slow code. Keep in mind that most optimizers can't do very much about optimizations across calls to functi
Aside from it being at end-of-life, there are plenty of other, more technical, reasons why VB6 is a bad choice for many projects, especially large ones. I say this coming from a long history of writing and maintaining VB6 code, not because I have a bias against the language.
VB was my second language and VB6 does vastly improve the VB experience, but there are several large problems: it doesn't support inheritance (only polymorphism); it is very difficult to use advanced features of the Windows API, it is very hard to debug and profile, and finally, it can lead to extremely unstable code.
The VB6 language supports a feature where you can implement an interface, similar to Java or C# interfaces, or C++ pure virtual functions. It does not, however, support a method to inherit methods from another class. Thus, you often find yourself writing reams of code to delegate to another class that has a common implementation of various functions. Furthermore, if an interface changes, all the classes that inherit that interface must also be changed. That can lead to a rather large maintenance headache. Furthermore, changing the interface often plays havoc with the IDE's parser, so it can no longer tell which methods on the class are inherited in the Intellisense functions.
More advanced features of the Windows API require you to copy and paste large bits of function and constant declarations into your code, and you have to jump through all kinds of hoops just to properly use the registry, system tray, or message handlers. I.e. if you want to catch a certain message sent to a window, you have to use SetWindowLong to override the message procedure of the window (you pass in the address of another procedure, which you acquire by calling "Address Of"). There is also all kinds of problems with passing pointers to structs, since you can't get a pointer in VB6. I.e. often, many window procedures require a struct with a pointer to another struct. There are hacks to get that, such as allocating a new memory buffer (using the LocalAlloc API), using CopyMemory to copy the VB struct into the memory location, then passing the pointer you got from the LocalAlloc call in as a struct member, and then using CopyMemory after the call to put the data into the VB6 struct. There are also undocumented functions to retrieve the address of variables, but there is, of course, no way to dereference a pointer, short of copying the data into a VB struct, or doing some fancy copying to change what an object points to (but that plays havoc with the reference counting).
Next, you've got the instability issues. Using *any* of these features leads to instability. Under normal circumstances, things work alright, but if you try to run the application in the IDE while you've got a custom message handler set up for a window, then the moment you hit "Stop" to end execution, the whole IDE crashes. The reason for this is that the VB6 IDE runs the app inside the IDE's process, so if your app causes a GPF or similar, the whole IDE goes with it. It also makes it a real pain for debugging, since setting breakpoints inside the window procedure often causes crashes.
Finally, it's very difficult to debug a VB application. If you've ever looked at the assembly output of the compiler, it's absolutely horrendous. Trying to step through it in WinDebug or something similar is just about impossible. The only way to debug it is with source code and full symbols, but even that is rather difficult sometimes. For example, most of the magic happens within the VB6 runtime (just about every VB statement is implemented as a call to the runtime; even assignment), so it's very difficult to follow what is really going on underneath the hood.
Those are my main problems with it. I also don't like many other things. For example, VB is really slow. Slower than.NET, in my experience. Every benchmark I've ever run has VB losing by at least an order of magnitude. For example, I wrote an MD5 algorithm in VB (no small feat since VB has no unsign
A while back, I remember reading that someone had invented a video game that was controlled similarly, but it took a while to train yourself to "think" properly. Having the robot mirror your own movement sounds far superior. If this continues to develop, I have some hope of never developing carpal tunnel syndrome.
Right, just because weird stuff happens, and you didn't believe in carpal tunnel syndrome, we should believe any quack who comes along. When a doctor investigates this and comes up with something better than wide-spectrum antibiotics, I might start believing it. I've had bed bugs before, and I've been bitten by quite a few things. I've had unexplained allergic reactions. I still think this story is total crap.
i've got to say that grammar is just about the least important part of writing
You're partly right. I think what you're trying to say is that grammar ought to be the smallest concern for a writer, but that's not the same as saying it's not important. You cannot write well if you use bad grammar. E.g. sentence this you no idea means what have (at least, at first, anyway). To put it simply, good grammar is necessary, but not sufficient, for good writing.
Great link (note that the link doesn't work as-is; the terminating slash must be removed).
I'd never seen that before, but it seems that the original discoverer thinks pretty much as I do: that the original bug was overblown. However, the last sentence in there is interesting:
In several of these instances, I had no reason to be suspicious of the result except that a second machine produced a different result.
With the FDIV bug, in an all-pentium environment, he wouldn't notice that difference. The AMD bug would be noticed because, even if both machines overheated, they'd likely produce different (random) results. Thus, he provides yet another reason why this bug isn't as severe as the FDIV bug.
I think you've missed the point a little. While the FDIV bug didn't really harm Intel long-term. It was mostly a lot of hype and not a large problem. I don't really know why MBAs would learn from it, unless they have a course in handling overblown non-problems, in which case Intel handled it very poorly, because the problem got hyped quite a bit. My father, who was buying a computer at the time, was considering purchasing a 486 instead just because he had heard about the bug.
The problem is that most people don't like thinking that parts of their computers are fallible. A bug like the FDIV bug calls that faith into jeopardy. That, along with Intel's original downplaying of the bug, is what caused the hype. People were afraid of getting a bad CPU and not being able to get it replaced as Intel was saying it wasn't a big enough problem to warrant a replacement. Intel was probably right, but it doesn't change the fact that people really want their computers to give correct answers all the time.
Oh, and before you start trying to explain what CPU steppings are, I'll mention that most errata fixed in the various CPU steppings are very minor, even compared to the FDIV bug and this bug.
Slashdot Mirror
Sorry to be so pedantic. I'm sure you knew that, but I don't like leaving misinformation lying around for other readers, even if this is Slashdot. grin
I doubt it. My reading of the article is that the CPU detects when only one core is in use and does everything itself. But, even if it does require some level of OS support, I wouldn't worry about Linux's support of it (or of UEFI, for that matter, as Linux runs quite well on Macs and Intel does a good job of supporting Linux, anyway). Linux even has support for hotplugging CPUs, so, even if it comes to that (and I doubt it will), then it should still work.
Any change in a CPU's implementation should not be observable to anyone unless the observer knows to look for it (e.g. with the CPUID instruction). Intel won't release a chip that breaks existing apps. Besides, if you think about it, if apps work on a single-core CPU, why shouldn't they work on a dual-core CPU with one core disabled?
Why should they? The advent of multicore CPUs won't actually hurt single-threaded apps. They just won't get any faster. For most things, that's fine. Legacy apps that aren't changing are most likely already fast enough. Besides, not everything can be parallelized properly, anyway. Multithreaded applications will become more popular, but I think this trend will affect new applications much more than old ones because it's just not that important. Even new apps don't necessarily need parallelization because many things are "fast enough" on a single core.
By the way, I actually hope that many things never become multithreaded. In my experience, most coders simply aren't capable of thinking threading through clearly. For many people, the concept is just too complex. Hopefully, compilers will improve to the point where many things can be parallelized without the coder having to know very much, if anything, about the threading involved, but, today, we're nowhere near that. We desperately need higher-level threading primitives in computer science.
It makes perfect sense that you'd still try to speed up single-threaded applications. After all, if you have 4 cores, then any speedup to one core is a speedup to all of them. I realize that's not what this article is about. In this case, they are speeding up one at the expense of the other, but the article's blurb makes it sound like Intel shouldn't be interested in per-core speedups when that is clearly false.
Right...
You obviously know nothing of what you are speaking. You have never seen a security bulletin from ATI or nVidia because they both fix the bugs they find silently or ignore the bugs. Have you heard of the Month of Kernel bugs? If not, I suggest you look it up and take note of where all the Windows kernel flaws were found - wireless drivers.
Furthermore, I have it on good faith from a friend who once worked at ATI that their driver, at least, is full of security holes.
Absence of evidence is not evidence of absence.
I upgraded this morning.
I had lots of problems. First, the glibc upgrade failed because certain extra files existed. I accidentally rm'ed the wrong file (stupid of me, yes) and then had to repair with a live CD. I then rm'ed the right files and my system was b0rked until I ran ldconfig to regenerate the ldconfig file. Finally, I could upgrade glibc. However, at this point, apt-get won't boot because glibc is inconsistent. I then use dpkg to unpack a bunch of packages until apt-get works again and continue the upgrade.
Next, I reboot. The default kernel doesn't boot due to a bug in the nvidia fb driver. Fine. I pass video=vga to the kernel and reboot. Now it freezes detecting my sata drives. Wonderful.
I try to boot my custom built 2.6.18 kernel which I know works. Panic. Beautiful. I look at the grub command line and Ubuntu has put a large string of hex characters into the root= parameter. I remove that, remove the "splash" and "quiet" that it also felt like adding, and then I finally had a working system.
Unless you are comfortable manually repairing glibc and editing kernel command lines, I suggest you don't go anywhere near this upgrade.
Really?
And tests are good only when you run them.
Oh, please.
MS bashing is fun and all, but do you have any idea how a kernel works? Anything can step on anything else. An off-by-one error in a kernel can be catastrophic to any number of things. This one does sound suspicious, but keep in mind that the code that is failing is probably only peripherally related to the code that was patched. They say they patched a buffer overflow. Maybe the buffer was already being overflowed by the compression code and patching it caused the compression to break. That might explain why it's the last 4000 bytes or so in a file that's almost a multiple of 4K.
The real question is why they didn't catch it in testing, especially with MS's extra-long patch process where they spend so much time testing (that is the current excuse for the months that pass between reports and patches, right?). Being "extra careful" does not save you from these types of bugs and being a programmer for as long as you have, you ought to know that being careful just doesn't cut it.
I should also add that lesbians could also get it for fairly obvious reasons. That leaves the only woman-to-woman transmission vector being bisexual women or women who have one-off lesbian experiences.
Not necessarily. A vaccine could be useful even if it causes birth defects as long as it doesn't cause *genetic* defects in the offspring because then, we could vaccinate all males, for example. That would help quite a bit because it would prevent aids from being transmitted via heterosexual and gay intercourse, leaving only lesbian and non-intercourse methods of transmission (and, I believe that woman-to-woman transmission is a lot more difficult than the other forms). I think that could go a very long way in stopping the AIDS epidemic in Africa.
Whether the African people would use AIDS vaccines is an entirely separate issue of which I am both unqualified and reluctant to speak.
Shouldn't that be 1490?*
Coat? I don't need. It's over 40 F outside.
* Gung'f 2412 va onfr 12.
The incredulity that this mathematician might have been more interested in the challenge of the work than fame and fortune in the Western world practically oozes from each sentence.
What I think is harder for most people to comprehend is why he would turn down the *recognition* rather than the money. There are many reasons why someone might not care about money, but there are very few people who have such talent who want to simply hide it under a rock. This guy doesn't seem to care at all about being recognized for his work, so much so that he is quite willing to hand it to other people to finish for him when it's quite possible that those other people may have tried to take credit. That's the bit that I have trouble understanding. Genius is usually accompanied by a certain amount of conceit. Just look at Isaac Newton for one good example.
You ought to learn a little more about Agile software development. You pretty much prove the point.
Even planned communities are done incrementally. As you say, "new parts of the community can be grafted on easily". The key here is that you have new parts over time. Agile software is like a planned community, if done right: you lay down all the parts using techniques that you hope will be future-proof. You still plan at every stage before developing in Agile software, and you use accepted practice to try to prevent problems in the future. You have no way of knowing what might come in the future (in a planned city or a software project), so the best you can do is follow a few principles that you hope will keep your project maintainable.
Nobody (I hope) is promoting building software by throwing code together until something works. If you were under the impression that's what Agile programming is, then you've either never used it, or you've been working under bad management too long. You don't write code by the seat of your pants in Agile programming just as you don't drop houses in just any location at all in a city, planned or otherwise.
I know that's what you were getting at, and that's what my post was meant to address. It's not a technicality because SCO couldn't make a case. The judge gave them lots of rope and SCO hung themselves with it (at least, as far as the dismissed claims go). However, you are also missing the point. If MS wants to spin this as Linux "dodging a bullet", then they can do that whether or not it's just a technicality. Why do you think that MS will tell the truth? MS sales reps can and will say whatever they like about the SCO fiasco, and you can bet that, if they do speak about it, it will be to the detriment of Linux regardless of the facts of the case.
Here's an example. Let's say that IBM hadn't filed to have these dismissed and all the claims were dismissed at some later date simply because of their lack of merit. Why would that stop MS? They could claim that IBM had not produced enough in discovery (IBM lost some versions of AIX, I believe), so SCO was at a disadvantage. Or MS could just say that the lawsuit was bad enough. After all, even if SCO loses, who wants to face a lawsuit like that? Or maybe MS might just say, "SCO lost only because they didn't have the financial resources to battle IBM. Just wait until Linux infringes on our patents." The possibilities are endless. If I were you, I wouldn't worry too much about this ruling helping MS spread FUD.
That's true, to a point. After all, this is a rejection of the claims based on the lack of specificity instead of a lack of merit. However, there are two reasons why I have no doubt that it cannot be construed as you say. First, SCO was ordered by the court to provide that specificity and was given ample time to do so. That they still did not provide it demonstrates that SCO could not provide that specificity. Second, there are over 100 claims left to SCO. I expect all of them to be demolished by IBM in the coming months.
Oh, and one other point: the judge's point is that SCO failed to allege an actual violation. How could Linux have "dodged a bullet" when all of the dismissed claims were not actually real claims? If I say that Linux has copied Microsoft's USB infrastructure, for example, does that mean that, when I can't offer any proof, that Linux has "dodged a bullet"? Or, more likely, does it marganilize any other claims I might make?
I have disagree with you. While all the problems can be solved (I know; I've solved them all in the past, and more nasty things besides), they are still problems. The fact that they have to be solved just adds complexity to the project and many of your solutions aren't. For example, pushing the window procedure code into another control and using that control in your project helps compartmentalize the problem, but you still need to debug the control, which will still crash when you hit stop. Using third party controls to subclass the window can solve that problem, but now you've got to include that other control and worry about any licensing issues. I'm not saying these are big problems, but they do increase the complexity of the project.
I don't know what you mean by "low-level com" (maybe manipulating IUnknown et al directly?) but I've had my share of trying to manipulate the COM machinery in VB and it's never pretty. Usually, though, that type of thing is unnecessary. Only under strange circumstances where you need to implement an interface that has a reserved name as a method or a method that doesn't return an HRESULT do you have to worry about that very much (it's been a very long time since I've had to do that in VB, so I don't recall all the tricks anymore). However, I'd hardly use that as an example as to how the problem can be solved. Yes, it can almost always be done, but it just adds so much complexity that it's often not worth it. As you say, VB programmers are cheap. They are cheap for a reason. What's the point of writing code that does all this if none of your coworkers can maintain it?
I didn't say you couldn't do cool things with VB. Sometimes it is the right tool for the job. VB makes some tedious things (in C++) very easy. However, that doesn't mean there aren't problems.
I'd argue that, if VB6 is faster than .NET, then you should probably find a better .NET programmer. In my experience, VB6 is slower than even Java (though, admittedly, Java has been getting a lot faster in recent years). You can say I don't know what I'm doing, but I've written a lot of VB code and I've produced some very fast VB code. It's just that if I spend the same amount of time optimizing C++ or .NET code, VB always comes out the loser.
A different point of view? While you do have to keep it in mind, you can't escape the fact that you simply cannot do many things in VB as easily as you can in other languages. You are forced into a certain development model that doesn't respond well to changing requirements. As others have commented, you can crank out new UIs at a
The problem here is that you basically have this:
MyInterface:
public function foo()
end function
public function bar()
end function
MyClass:
Implements MyInterface
public function MyInterface_foo()
end function
public function MyInterface_bar()
end function
Note how MyClass needs to have all the functions in MyInterface (prefixed by MyInterface_). If I add another function to MyInterface, I need to modify every class that implements it (like MyClass). That's the same as Java and C#, except that in those languages, I have inheritance, so if I have a parent class which implements an interface, then I just have to add the new interface function to the parent class and all the child classes get it. In VB, all classes would have to explicitly implement the interface, so I'd have to modify every class that implements that interface, since there is no parent class with an inherited implementation.
Is that clearer?
I know why they did it that way, but is there really any reason why they couldn't have allowed inheritance on private classes where they don't ever need to expose the class via a COM interface (I'm sure they still do, but there's no reason they have to)? Furthermore, though COM doesn't have the idea of inheritance, it can be faked by delegation, which could have been done behind the scenes by the language.
I remember that. It was pretty handy, but many of the large projects, which weren't under my control, were very picky over their dependencies, so I couldn't use it. I know it's irrational, but that's the way things go sometimes.
I remember it came up with the common dialogs (the font chooser dialog requires a struct with a pointer to a LOGFONT struct). You might wonder why I was using the API for the common controls - the simple answer is that I didn't want to include a large OCX in that particular project (that was before you could reasonably expect it to be already on most users' PCs and most users were on dial-up).
I had to do this on a few occasions. VB often fails with very weird error messages. E.g. Out of memory seems to be a rather common one. Once, I was debugging a problem where calling an interface would fail in strange ways. It turned out that the interface had a function where it took a reference to an ADO object and the client didn't have ADO installed, thus making the cast to that interface fail with a very unhelpful error message. Another example is when you have bugs in the libraries the VB app is calling. Once, I found a bug in Crystal Reports like this, for example.
With .NET there are plenty of tools for inspecting and debugging the IL that it creates, so such tools do exist for .NET and it isn't that far fetched that you'd want to do something similar for VB.
I'm not, after seeing the generated machine code. For example, after every single statement, VB puts in an "fnclex" instruction, which means "clear floating point exception", even if the instruction wasn't a floating point instruction. Just about every VB statement is implemented with several function calls to the VB runtime. Just making those calls adds a significant amount of overhead. Add to that all the redundant bounds checking you do and you have a recipe for really slow code. Keep in mind that most optimizers can't do very much about optimizations across calls to functi
Aside from it being at end-of-life, there are plenty of other, more technical, reasons why VB6 is a bad choice for many projects, especially large ones. I say this coming from a long history of writing and maintaining VB6 code, not because I have a bias against the language.
.NET, in my experience. Every benchmark I've ever run has VB losing by at least an order of magnitude. For example, I wrote an MD5 algorithm in VB (no small feat since VB has no unsign
VB was my second language and VB6 does vastly improve the VB experience, but there are several large problems: it doesn't support inheritance (only polymorphism); it is very difficult to use advanced features of the Windows API, it is very hard to debug and profile, and finally, it can lead to extremely unstable code.
The VB6 language supports a feature where you can implement an interface, similar to Java or C# interfaces, or C++ pure virtual functions. It does not, however, support a method to inherit methods from another class. Thus, you often find yourself writing reams of code to delegate to another class that has a common implementation of various functions. Furthermore, if an interface changes, all the classes that inherit that interface must also be changed. That can lead to a rather large maintenance headache. Furthermore, changing the interface often plays havoc with the IDE's parser, so it can no longer tell which methods on the class are inherited in the Intellisense functions.
More advanced features of the Windows API require you to copy and paste large bits of function and constant declarations into your code, and you have to jump through all kinds of hoops just to properly use the registry, system tray, or message handlers. I.e. if you want to catch a certain message sent to a window, you have to use SetWindowLong to override the message procedure of the window (you pass in the address of another procedure, which you acquire by calling "Address Of"). There is also all kinds of problems with passing pointers to structs, since you can't get a pointer in VB6. I.e. often, many window procedures require a struct with a pointer to another struct. There are hacks to get that, such as allocating a new memory buffer (using the LocalAlloc API), using CopyMemory to copy the VB struct into the memory location, then passing the pointer you got from the LocalAlloc call in as a struct member, and then using CopyMemory after the call to put the data into the VB6 struct. There are also undocumented functions to retrieve the address of variables, but there is, of course, no way to dereference a pointer, short of copying the data into a VB struct, or doing some fancy copying to change what an object points to (but that plays havoc with the reference counting).
Next, you've got the instability issues. Using *any* of these features leads to instability. Under normal circumstances, things work alright, but if you try to run the application in the IDE while you've got a custom message handler set up for a window, then the moment you hit "Stop" to end execution, the whole IDE crashes. The reason for this is that the VB6 IDE runs the app inside the IDE's process, so if your app causes a GPF or similar, the whole IDE goes with it. It also makes it a real pain for debugging, since setting breakpoints inside the window procedure often causes crashes.
Finally, it's very difficult to debug a VB application. If you've ever looked at the assembly output of the compiler, it's absolutely horrendous. Trying to step through it in WinDebug or something similar is just about impossible. The only way to debug it is with source code and full symbols, but even that is rather difficult sometimes. For example, most of the magic happens within the VB6 runtime (just about every VB statement is implemented as a call to the runtime; even assignment), so it's very difficult to follow what is really going on underneath the hood.
Those are my main problems with it. I also don't like many other things. For example, VB is really slow. Slower than
A while back, I remember reading that someone had invented a video game that was controlled similarly, but it took a while to train yourself to "think" properly. Having the robot mirror your own movement sounds far superior. If this continues to develop, I have some hope of never developing carpal tunnel syndrome.
Right, just because weird stuff happens, and you didn't believe in carpal tunnel syndrome, we should believe any quack who comes along. When a doctor investigates this and comes up with something better than wide-spectrum antibiotics, I might start believing it. I've had bed bugs before, and I've been bitten by quite a few things. I've had unexplained allergic reactions. I still think this story is total crap.
-1 Paranoid ravings
Who let the slashdot editors start posting stories without parental supervision again? This whole story is crap.
You're partly right. I think what you're trying to say is that grammar ought to be the smallest concern for a writer, but that's not the same as saying it's not important. You cannot write well if you use bad grammar. E.g. sentence this you no idea means what have (at least, at first, anyway). To put it simply, good grammar is necessary, but not sufficient, for good writing.
I'd never seen that before, but it seems that the original discoverer thinks pretty much as I do: that the original bug was overblown. However, the last sentence in there is interesting:
In several of these instances, I had no reason to be suspicious of the result except that a second machine produced a different result.
With the FDIV bug, in an all-pentium environment, he wouldn't notice that difference. The AMD bug would be noticed because, even if both machines overheated, they'd likely produce different (random) results. Thus, he provides yet another reason why this bug isn't as severe as the FDIV bug.
I think you've missed the point a little. While the FDIV bug didn't really harm Intel long-term. It was mostly a lot of hype and not a large problem. I don't really know why MBAs would learn from it, unless they have a course in handling overblown non-problems, in which case Intel handled it very poorly, because the problem got hyped quite a bit. My father, who was buying a computer at the time, was considering purchasing a 486 instead just because he had heard about the bug.
The problem is that most people don't like thinking that parts of their computers are fallible. A bug like the FDIV bug calls that faith into jeopardy. That, along with Intel's original downplaying of the bug, is what caused the hype. People were afraid of getting a bad CPU and not being able to get it replaced as Intel was saying it wasn't a big enough problem to warrant a replacement. Intel was probably right, but it doesn't change the fact that people really want their computers to give correct answers all the time.
Oh, and before you start trying to explain what CPU steppings are, I'll mention that most errata fixed in the various CPU steppings are very minor, even compared to the FDIV bug and this bug.