You put a lightbulb inside a spinning coffee can with slits at 4 equally spaced spots around the circumference.
The photons are projecting out of the slits. As the can spins, the pattern of light and shadow turns and projects on the surroundings.
The outside surface of the can is moving at 1 full turn per second.
10 feet away from the can, the pattern of light and shadow is moving at 31.4 feet per second.
100 feet away from the can, the pattern of light and shadow is moving at 314 feet per second.
At just 2 miles from the can (we are using a BRIGHT bulb), the light and shadow is moving 22,619 miles per hour!
Gaaah! Who modded parent 'interesting'?
Replace the photon emitter (i.e. lightbulb) with a couple of machine guns spewing bullets through the slits.
The machine guns' aim may 'move' very rapidly when extrapolated to a 2-mile radius, but it doesn't make the bullets go any faster.
There's nobody forcing C# on VB.net developers. MS is even continuing to support COBOL.net, as far as I know. However, you are right in a sense. Although not intentionally pushing C#, Microsoft and other vendors are largely working in C#, publishing more examples in C#, and creating tools/components that only work with C#. So VB.NET is being slowly pushed into second class status due to more experienced/prolific/expert OO coders being more comfortable with C#, thus creating more stuff in that language.
I'm pretty sure VB isn't being pushed into second class status. It was designed to be that way.
By killing of VB6 and making VB.NET a dead duck from the start they ensured that the new C# language would gain large adoption.
The more experienced/prolific/expert OO coders move from VB6 to C# because C# seems to be getting all the goodies they requested be put in VB5, VB6, VB7 and so on. And when VB.NET turns out to be:
a) quite far from VB6
b) you can't leverage existing skills
c) you can't reuse proven class libraries
d) it's still proprietary, so you may need to bend over yet again sometime in the future
... the move to a completely different language becomes a no-brainer. If your shop is an MS-shop, that is either C# or C++, and if you didn't pick C++ the last time, you're likely to go for C#.
(That's what I did, and so far, C# seems to have more VB spirit than VB.NET.)
Not to sound too pedantic, but DRM of some form still has a place. DRM should be there to discourage casual copying by non-geek people. For example, the DRM on DVD's is functionally useless against anyone who has spent an hour looking things up on the internet. But my sister still doesn't know how to burn duplicate DVD's for her friends... it's just not worth the effort to her to find out.
I'm all for DRM that is used to prevent casual copying. However, DRM isn't actually used that way now. It isn't even the main purpose of the DRM efforts of lately.
DRM is approximately equal to format, and whoever owns a format has a big chance of earning a lot of money from either licensing the format to others (Hence the Blu-Ray/HD-DVD format war), or selling proprietary gadgets that can use the format (Apple). Neither of these benefit the customers.
Instead, it drives costs up and forces you to buy specific hardware to play music/movies that could play just as well on regular/old hardware - if it weren't for the DRM. And it locks the content and stops you doing 'normal' things with it, such as building a HTPC with all content on an array of harddrives.
If DRM were used the way you describe, I don't think there would be any issues. And if the companies *really* wanted DRM to be used only for that purpose, we'd see a lot more effort put into DRMs based on 'watermarking'. Apple could do that on Itunes *today*.
The mobo is a socket AM2, an AMD socket with 940 pins.
Just to clarify, the Asus A8R32-MVP is socket 939, just like the rest of the components named. That's why I reacted to TFA calling it an AM2-system - and in the heading of the specs table at that.
In other words, they ran 3dMark06 on two completely different setups and got different results. Geez.
I'm of the opinion that it could be more significant than this... I mean, are we supposed to beleive this guy actually found the QueryPerformanceCounter BIOS issue when he doesn't know the equipment he's using?
On one hand, it could be a typo. On the other hand, this mistake is a bit too obvious if you know your hardware...
In any case, most people wouldn't care about the QPF/BIOS unless it kicked them in the balls, so by being so detailed about it, the article is clearly making a point: "I know my stuff". Supposedbly trying to build some credibility for the later agenda - which seems to be pushing gaming on Vista.
Asus A8R32-MVP with *** Socket AM2 ***? using DDR memory. And an FX 60? He obviously has a 939-system.
How far can we trust this guy to have opinions on drivers and stuff?
So, I would say that strings, if the theory turns out to produce useful, accurate, precise results, are just as real as photons, atoms, rocks, and stars.
I though this was the main gripe about string theory - that it doesn't produce anything. It only models what already is, and the level of accuracy in a given situation is depending on the theorist's whim.
Re:VB already gets the respect it deserves...
on
Lisp and Ruby
·
· Score: 1
It is evident you are a nicer person than I am - at least you have more patience for people than I do.:-)
Good luck. (no irony intended)
Re:VB already gets the respect it deserves...
on
Lisp and Ruby
·
· Score: 1
Good example. I've used the analogy "just because you got a chemistry box for christmas doesn't mean you can start making medical drugs and try them on people". Only said it once, and I felt a bit bad about it afterwards. On the other hand, the guy was just speeding ahead and coding himself into the most amazing corners time and again, so I think he needed to hear it... Sigh.
However, regarding the question, I think you may have missed my point.
Taking the guy who is unable to produce even the makefile for a C/C++ program, while being totally able to churn out working code in VB... Which environment do you think he'll choose to work with? I'm guessing 'VB', and that this explains why so many amateurs code in VB.
The question you answered was - somewhat paraphrased - "If you have a choice between a non-working makefile or a working VB program written by the same guy, which do you prefer?" You can't expect both to work. If both worked, the doofus might attempt to do some C/C++ hacking, but all the evidence suggests the amateurs mainly end up in VB.
Anyway, to answer it myself; I'd say I prefer taking over the makefile. Firstly, there are too many things that can make program code unmaintainable. Secondly, it's a lot easier to convince my manager that doofus should be fired, since it is evident the makefile doesn't work. Trusting managers to be able to tell good code from bad when both seem to work is generally _not_ possible.
Re:VB already gets the respect it deserves...
on
Lisp and Ruby
·
· Score: 1
We agree on some parts, and differ in some... In the book analogy, I would firstly blame myself for not browsing through the pages of the book before buying, then I'd blame the publisher, then finally the author. I think most of the actual blame would go to the publisher for the inferior product, and I guess the publisher is the one who convinced the author that the book was ready for publishing. So... it probably means we agree there...
However, I'd say the 'professional' VB coders write about as crappy VB code as the 'professional' coders using other languages. It's the amateurs that are bringing down the averages. In other languages you don't see as many amateurs because the languages and/or environments are just too hard to use.
I've used the example before, but it'll do again; A guy who wouldn't get past the makefiles of C/C++ may be able to write actual working programs in VB. That he calls himself a 'professional' does not make him one.
By the way, are you of the opinion that it is better to have a working program, or that it's better to have a non-working makefile? (And who or what would you blame?)
Re:There is an improved VB...
on
Lisp and Ruby
·
· Score: 1
This is probably getting off topic, but I'd have to disagree with this I'm afraid.
Delphi provides a set of components on a palette that can be dragged and dropped onto a form, same as VB. It has events same as VB.
Then, by the same logic, just about all languages that use Visual Studio as their IDE are also descendants of VB. This includes not only VB.NET, but also C# and C++/CLI and some others.
There's more to VB than this, I'm afraid.
Re:VB already gets the respect it deserves...
on
Lisp and Ruby
·
· Score: 3, Insightful
Build a tool even an idiot can use and only an idiot will want to use it.
I'd like to change that to "Build a tool even an idiot can use and expect idiots will try to use it."
I've been on the receiving end of many a poorly designed VB app, but is that the language's fault?
Assume we collect a random number of 3rd graders' essays. We can safely assume they will be pretty badly written. Do you automatically blame 'english' for the essays being bad? Maybe you also tout another language as superior just because the only ones you know speaking that other language are all 20+, and have picked up a bit or two about telling a story.
Btw, english is not my first language, and I think the VB slamming that is so fashionable around slashdot is just stupid. Not that I think there's any doubt about either after this.
They also don't replace NiCad batteries in especially high current draw devices like RC cars.
Actually, even if NiMh has a slightly lower current draw than NiCd, the higher capacity still makes them desirable. I *do* race with R/C cars, and I honestly don't know of anyone who still uses NiCd. As far as I know, NiCd hasn't been used for racing for the last 5 years, and while NiMh may be the most popular for the time being, it is being surpassed by LiPo and Li-Ion. Especially in anything flying (due to the higher capacity per unit of weight).
On another note, I saw some people comparing the capacities of Alkalines and NiMh in some earlier posts. I've had the opportunity to try both in the same applications under similar conditions. In both transmitters and some small R/C cars (Mini-Zs take AAA batteries, I have one).
As others have already pointed out, it is preferrable to use alkalines in low-current draw applications such as the transmitter, but Alkalines really don't stand any chance whatsoever in moderate to high-draw applications such as powering a Mini-Z.
Jörg Mrkwitschka, world record holder for fastest electric boat ever (140.9 MPh google 'mrkwitschka' for movies of some of his runs) uses NiMh cells (32 of them IIRC).
I also know that a swedish team gunning for the fastest R/C car also use NiMh batteries.
Both of those are [b]all[/b] about extreme current draw, so I'll stick my neck out and say that NiCd batteries are pretty much eclipsed in the R/C hobby.
Finally, NiMh batteries do lose their charge quite quickly, so it's necessary to 'exercise' them if you have them sitting on a shelf. Even after a single week, the lack of 'punch' is quite noticeable when racing.
So - that only leaves you the letters H, I, N, O, P (sic!), U, V, W, Y and Z if you don't want to have a name clash with another programming language. Technically, M and X are followed by numbers in the previous examples, so you could argue for them as well, and even A (as it has a plus behind the letter)
Actually, I did some UI programming in V+ on an Adept robot back in 1990, so 'V' is already taken.
It was an industrial robot, but was actually pretty cool both hardware and software-wise. It had a mouse, windows and widgets and stuff, and multiple add-in boards for hooking up a video camera and running image recognition.
Why not sign up for a course?
Been a long time since I've used VB -- I think it was VB3 back then. It'll stay that way, since I'm a linux guy, but I guess it's good that the language is making some progress.
And I do say the same thing about java, c#, and their ilk. Finally, so what if VB5 used the same back-end compiler as VC++6? When translating down to C++, there is not a 1-1 correspondance between lines of C++ and lines of VB -- otherwise, they'd be the same language. The compiler doesn't kill the performance, the extra instructions do.
Yeah, I started on VB3 myself, so if that's your only experience, then.. Well.. VB3 was interpreted bytecode, and didn't even have classes... Things have moved a long way since then, so if that's your only experience, then it was like 12-15 years ago, and then you really shouldn't be slamming it now.
Re-visiting the discussion about the back-end compiler; The only extra instructions used by VB5 compared to C++ is that VB5 objects are reference counted... But if you're that particular about speed, you should use C instead of C++ to avoid vtable indirections. Or are you referring to the fact that VB5's language contains a lot of pre-packaged, optimized and ready-to use commands? I guess you're not using class libraries or SOs then either. They're also pre-packaged, optimized and ready to use. I think you're confusing it with VB3 and 4 being interpreted bytecode.
On a different note, I can probably come up with more scathing criticism of VB than you, because I know where its ugly bits are... For example, you have to jump through hoops just to make efficient bit operations - there are no shift operators. Writing your own window procedures are a hack. Lots of stuff in core libraries weren't thread-safe, so you really had to use caution when using free threading (VB5). And VB6 broke the free threading completely... etc. Most of it has to do with not being able to get down to the metal even when you have legitimate reasons to.
Naw, I've got plenty of experience, both in the corporate and open source environment. My two biggest complaints about VB are the limited support base (windows) and performance (shitty). No dynamically typed language is going to beat C++.
I wasn't disputing your computer experience. I was just whining about your remark sounding like someone without much VB experience.... And since you apparently think VB is dynamically typed, it seems I was right. VB is COM. COM doesn't know dynamic typing. The best it can do is UNIONs... Which happen to be a C/C++-construct, but that doesn't make me want to call C dynamically typed...
Also, like Bjarne said, you can write just about *anything* in C++. Can you write device drivers in VB? Can you write a multi-threaded webserver? My bet is that if you can, it'd be an ugly ugly beast.
You could say the same about Java, and C++.NET, but I don't hear you arguing that they are just prototyping languages and the code should be thrown away.
But you do have some points - C++ is without a doubt a lot closer to the metal than VB, and no. I would not want to attempt to write a device driver in VB... However, I feel the same about writing user interfaces and reporting applications in C++. If you think C++ is good for that, then you should really give VB a try.
As for a web-server, I think a multi-threaded web server with reasonable performance would be perfectly possible to write in VB. VB5 to be more specific. VB6 broke the possibilities for free-threading, and VB7 is.NET (memory hog and sub-stellar performance).
By the way, did you know that VB5 used the same back-end compiler as Visual C++ 6.0? Yup... That must be where the shitty performance comes from.
VB is a rapid prototyping environment. And just like an RP machine, it makes a flimsy product that you can send back to the drawing board without much expense. But you don't ship a product you've made on an RP machine -- it's crap. You take your prototype, and make a real product out of it using sturdy materials. Same goes for VB. You make something that works the way you expect, then you make it work in a real language. Good thing about VB is that you can replace pieces at a time with DLLs compiled from C++. If that isn't a part of the VB curriculum, it's a waste of time.
Sigh... To me, this sounds like a typical rant from someone who doesn't have any actual experience.
Anyway... I think the problem may be that VB is too easy to use. People who would not be able to write the makefile for their 'Hello World' program in C++, are able to write working but very rickety/ flimsy VB programs.
I happen to make a living as a computer consultant. This means I get to see a lot of different organizations and their in-house software... This means a LOT of VB code... And of that VB code, a lot (maybe 90%) is written by people who may know their business but don't have a clue about programming. I can definitely see how that would create the reputation that VB programmers are bad, but not how it makes the LANGUAGE bad.
As for stability, I can promise you that some of my VB programs are a hell of a lot stabler than the memory-leaking SEGF/GPF-ing C++ hacks they replaced. In case you didn't know - it's perfectly possible to write shitty C++ code too. It's just that you have to get above a certain level to even get the compiler to work, so most of the would-be self-made computer wizards turn to something easier instead.. Like VB.
The big question here is: Is it better to have a flimsy but functioning VB program or a defunct makefile? I'm not sure of the answer myself. A defunct makefile is a 5-minute job to fix, whereas some of the VB messes I've seen would literally take years to get straightened out. (I hate people who think they can program just because their $h!+ compiles.)
Slashdot Mirror
Ah, but me from Russia, where point misses ME.
Replace the photon emitter (i.e. lightbulb) with a couple of machine guns spewing bullets through the slits.
The machine guns' aim may 'move' very rapidly when extrapolated to a 2-mile radius, but it doesn't make the bullets go any faster.
The bean passage is from the 'big bang'.
By killing of VB6 and making VB.NET a dead duck from the start they ensured that the new C# language would gain large adoption.
The more experienced/prolific/expert OO coders move from VB6 to C# because C# seems to be getting all the goodies they requested be put in VB5, VB6, VB7 and so on. And when VB.NET turns out to be:
a) quite far from VB6
b) you can't leverage existing skills
c) you can't reuse proven class libraries
d) it's still proprietary, so you may need to bend over yet again sometime in the future
(That's what I did, and so far, C# seems to have more VB spirit than VB.NET.)
Misread of the day: "That's OK. Here, have a bowl of hot girls. Don't eat them, just put them in your pants."
DRM is approximately equal to format, and whoever owns a format has a big chance of earning a lot of money from either licensing the format to others (Hence the Blu-Ray/HD-DVD format war), or selling proprietary gadgets that can use the format (Apple). Neither of these benefit the customers.
Instead, it drives costs up and forces you to buy specific hardware to play music/movies that could play just as well on regular/old hardware - if it weren't for the DRM. And it locks the content and stops you doing 'normal' things with it, such as building a HTPC with all content on an array of harddrives.
If DRM were used the way you describe, I don't think there would be any issues. And if the companies *really* wanted DRM to be used only for that purpose, we'd see a lot more effort put into DRMs based on 'watermarking'. Apple could do that on Itunes *today*.
On one hand, it could be a typo. On the other hand, this mistake is a bit too obvious if you know your hardware...
In any case, most people wouldn't care about the QPF/BIOS unless it kicked them in the balls, so by being so detailed about it, the article is clearly making a point: "I know my stuff". Supposedbly trying to build some credibility for the later agenda - which seems to be pushing gaming on Vista.
Am I making more sense now?
Asus A8R32-MVP with *** Socket AM2 ***? using DDR memory. And an FX 60? He obviously has a 939-system. How far can we trust this guy to have opinions on drivers and stuff?
The so-called 'contractor' edition... When a client tells you to shove it, you can actually go 'yes sir!'.
Ok. Thanks for the clarification. (Please mod parent +1 Informative.)
It is evident you are a nicer person than I am - at least you have more patience for people than I do. :-)
Good luck. (no irony intended)
Good example. I've used the analogy "just because you got a chemistry box for christmas doesn't mean you can start making medical drugs and try them on people". Only said it once, and I felt a bit bad about it afterwards. On the other hand, the guy was just speeding ahead and coding himself into the most amazing corners time and again, so I think he needed to hear it... Sigh.
However, regarding the question, I think you may have missed my point.
Taking the guy who is unable to produce even the makefile for a C/C++ program, while being totally able to churn out working code in VB... Which environment do you think he'll choose to work with?
I'm guessing 'VB', and that this explains why so many amateurs code in VB.
The question you answered was - somewhat paraphrased - "If you have a choice between a non-working makefile or a working VB program written by the same guy, which do you prefer?" You can't expect both to work. If both worked, the doofus might attempt to do some C/C++ hacking, but all the evidence suggests the amateurs mainly end up in VB.
Anyway, to answer it myself; I'd say I prefer taking over the makefile. Firstly, there are too many things that can make program code unmaintainable. Secondly, it's a lot easier to convince my manager that doofus should be fired, since it is evident the makefile doesn't work. Trusting managers to be able to tell good code from bad when both seem to work is generally _not_ possible.
We agree on some parts, and differ in some... In the book analogy, I would firstly blame myself for not browsing through the pages of the book before buying, then I'd blame the publisher, then finally the author. I think most of the actual blame would go to the publisher for the inferior product, and I guess the publisher is the one who convinced the author that the book was ready for publishing. So... it probably means we agree there...
However, I'd say the 'professional' VB coders write about as crappy VB code as the 'professional' coders using other languages. It's the amateurs that are bringing down the averages. In other languages you don't see as many amateurs because the languages and/or environments are just too hard to use.
I've used the example before, but it'll do again; A guy who wouldn't get past the makefiles of C/C++ may be able to write actual working programs in VB. That he calls himself a 'professional' does not make him one.
By the way, are you of the opinion that it is better to have a working program, or that it's better to have a non-working makefile? (And who or what would you blame?)
There's more to VB than this, I'm afraid.
I've been on the receiving end of many a poorly designed VB app, but is that the language's fault?
Assume we collect a random number of 3rd graders' essays. We can safely assume they will be pretty badly written. Do you automatically blame 'english' for the essays being bad? Maybe you also tout another language as superior just because the only ones you know speaking that other language are all 20+, and have picked up a bit or two about telling a story.
Btw, english is not my first language, and I think the VB slamming that is so fashionable around slashdot is just stupid. Not that I think there's any doubt about either after this.
On another note, I saw some people comparing the capacities of Alkalines and NiMh in some earlier posts. I've had the opportunity to try both in the same applications under similar conditions. In both transmitters and some small R/C cars (Mini-Zs take AAA batteries, I have one).
As others have already pointed out, it is preferrable to use alkalines in low-current draw applications such as the transmitter, but Alkalines really don't stand any chance whatsoever in moderate to high-draw applications such as powering a Mini-Z.
Jörg Mrkwitschka, world record holder for fastest electric boat ever (140.9 MPh google 'mrkwitschka' for movies of some of his runs) uses NiMh cells (32 of them IIRC).
I also know that a swedish team gunning for the fastest R/C car also use NiMh batteries.
Both of those are [b]all[/b] about extreme current draw, so I'll stick my neck out and say that NiCd batteries are pretty much eclipsed in the R/C hobby.
Finally, NiMh batteries do lose their charge quite quickly, so it's necessary to 'exercise' them if you have them sitting on a shelf. Even after a single week, the lack of 'punch' is quite noticeable when racing.
Re-visiting the discussion about the back-end compiler; The only extra instructions used by VB5 compared to C++ is that VB5 objects are reference counted... But if you're that particular about speed, you should use C instead of C++ to avoid vtable indirections. Or are you referring to the fact that VB5's language contains a lot of pre-packaged, optimized and ready-to use commands? I guess you're not using class libraries or SOs then either. They're also pre-packaged, optimized and ready to use. I think you're confusing it with VB3 and 4 being interpreted bytecode.
On a different note, I can probably come up with more scathing criticism of VB than you, because I know where its ugly bits are... For example, you have to jump through hoops just to make efficient bit operations - there are no shift operators. Writing your own window procedures are a hack. Lots of stuff in core libraries weren't thread-safe, so you really had to use caution when using free threading (VB5). And VB6 broke the free threading completely... etc. Most of it has to do with not being able to get down to the metal even when you have legitimate reasons to.
You could say the same about Java, and C++
But you do have some points - C++ is without a doubt a lot closer to the metal than VB, and no. I would not want to attempt to write a device driver in VB... However, I feel the same about writing user interfaces and reporting applications in C++. If you think C++ is good for that, then you should really give VB a try.
As for a web-server, I think a multi-threaded web server with reasonable performance would be perfectly possible to write in VB. VB5 to be more specific. VB6 broke the possibilities for free-threading, and VB7 is
By the way, did you know that VB5 used the same back-end compiler as Visual C++ 6.0? Yup... That must be where the shitty performance comes from.
Anyway... I think the problem may be that VB is too easy to use. People who would not be able to write the makefile for their 'Hello World' program in C++, are able to write working but very rickety/ flimsy VB programs.
I happen to make a living as a computer consultant. This means I get to see a lot of different organizations and their in-house software... This means a LOT of VB code... And of that VB code, a lot (maybe 90%) is written by people who may know their business but don't have a clue about programming. I can definitely see how that would create the reputation that VB programmers are bad, but not how it makes the LANGUAGE bad.
As for stability, I can promise you that some of my VB programs are a hell of a lot stabler than the memory-leaking SEGF/GPF-ing C++ hacks they replaced. In case you didn't know - it's perfectly possible to write shitty C++ code too. It's just that you have to get above a certain level to even get the compiler to work, so most of the would-be self-made computer wizards turn to something easier instead.. Like VB.
The big question here is: Is it better to have a flimsy but functioning VB program or a defunct makefile? I'm not sure of the answer myself. A defunct makefile is a 5-minute job to fix, whereas some of the VB messes I've seen would literally take years to get straightened out. (I hate people who think they can program just because their $h!+ compiles.)
Did you watch them with Rosey Palm? In that case, you have earned your tagline; "To go bald where no man has gone bald before..."