I don't really understand much about the.Net framework yet, but I've been playing around with the VB7 beta for a couple weeks (I'm primarily a VB6 programmer, basically because my previous boss, while being a nice guy, and a lot of fun, is a fucking idiot. Under my current boss, we're trying to move our heavy-duty data processing to VC++, but my major app has ~500K of VB source that I wrote over the course of two years.).
My basic impression? VB is dead! Long live VB! My first year and a half as a programmer was spent maintaining (and heavily recoding) old QBX 7 (Microsoft Professional Basic Development System 7, QuickBasic eXtended, whatever) code, with some rare VB4 work. From there, I went to VB6, and VB.Net bears far less resemblance to VB6 than VB6 does to QBX. When I made the previous move, I brought a lot of my QBX code directly into VB6, just adding variable predeclarations; I couldn't remotely do that with VB6 and VB7. However, they're including an upgrade wizard that should take care of most of the changes, like getting rid of set statements and changing variable types. The articles that Microsoft has telling you what to what to avoid are mostly about what the wizard can't cope with.
Anyway, I don't like to talk about what they changed or upgraded, because it's just not the same thing at all. VB7 actually looks like something I won't be embarrassed about making my living at. I am pissed at their making all arrays zero-based, however.
I expect that VB7 and C# development was pretty much parallel. They made a new RAD system, with two sets of syntax, one line-oriented and verbose (VB.Net), and one semi-colon oriented and more cryptic (C#). It's just too bad that my preference is semi-colon oriented and verbose. I want to see QuickPascal.Net, damnit!
P.S. Microsoft Basic goes back to the one Bill Gates personally wrote for the Altair in 1975, not just to the 80's.
7. Distribution. With desktop apps, an x-copy will actually suffice as the install routine. All apps install their custom components into their own dirs. The system repository tracks all versions of all DLLS installed, and automatically produces the proper version for the proper app at launch time. No more DLL hell.
Granted, this will be a massive improvement. However, why not just use static linking in the first place?
I bought a reel mower for the exercise, and because I thought it would bother the neighbors less. As it turns out, it's not much harder to puch than a powered mower. However, it's not a lot quieter, either, and it works terribly. It basically takes two passes one way, and then two passes perpendicularly to cut reasonably well. It bothers the neighbors more because it's being used for so much longer.
Every time I went to mow my lawn, my neighbor would watch with a disapproving look on his face, and he eventually badgered me into hiring a lawn service. It's not worth $40 per month to not mow the lawn, but it's worth it when you throw in not having to listen to my next door neighbor.
Moore's Law isn't a fiction, although calling it a law is putting it a bit strongly. It's really just a guideline for what to expect out of the computer industry.
If you want to look for conspiricy, though, consider that Gordon Moore (who, of course, stated Moore's Law) was a major executive of Intel for many years, and CEO for part of that. I doubt there was anyone else in the world who had as much control over the rate of advance in chip technology as he did.
How about multiple CPU's on the same chip, or putting RAM on the CPU die?
Re:Programmers Make Computers Slower Year by Year
on
Netscape 6 Vs. 4.7x
·
· Score: 1
C itself is very highly tuned to be easily converted into fast asm code by an entity as dumb as a compiler, but the only way it could ever compare to actual asm code would be on a CPU like the old 650X 8-bit series where there are no high-speed registers to speak of. While there are some pretty good optimizing compilers there are none that can juggle the decisions of when to use registers, the stack, and mem storage the way a human being can.
Actually, RISC designs (at least SPARC -- that's the only one I've actually had a class in) are fairly straightforward, as well. When you make a procedure call, you've got 8 registers that are exclusively used for parameter passing. Each procedure also has 8 registers for local variables that it can use without having to worry about saving what was there before. There's really not much that a person writing assembler by hand could do to improve on a good compiler.
In addition to that, the compiler is going to be better about keeping dependant instructions as far apart as possible than a person could be. That means that compiler-generated code (at least from a low-level language like C or C++) is going to have fewer pipeline stalls and, thus, be faster.
It's mainly x86 that has to be heavily tweaked to get the best performance out of it. There were probably older architectures that had similar complexities (VAX? PDP? 68xxx?), but everything but x86 has pretty much died out.
The really frightening thing about the WinNT ship is that it was a Ticonderoga class cruiser, just like the U.S.S. Vincennes, which accidentally shot down an Iranian airliner about 10 years ago. That's not the kind of ship you want having buggy software.
First, Robinson Crusoe was written by Daniel Defoe (No, I didn't know it off the top of my head; I checked Amazon.), but other people have mentioned that here. Second, the story you're describing is Huckleberry Finn. I'm a lot less startled by the troll than the fact that no one recognised that.
I suppose that would explain why I hadn't seen a plain Phoenix BIOS in years. I didn't realize Award was actually Phoenix, and I was starting to think they had gone out of business.
It doesn't matter what The Constitution says. If a judge orders something, no one and nothing but a higher judge can stop that order. There is no check on the judicial system.
I don't really understand much about the .Net framework yet, but I've been playing around with the VB7 beta for a couple weeks (I'm primarily a VB6 programmer, basically because my previous boss, while being a nice guy, and a lot of fun, is a fucking idiot. Under my current boss, we're trying to move our heavy-duty data processing to VC++, but my major app has ~500K of VB source that I wrote over the course of two years.).
My basic impression? VB is dead! Long live VB! My first year and a half as a programmer was spent maintaining (and heavily recoding) old QBX 7 (Microsoft Professional Basic Development System 7, QuickBasic eXtended, whatever) code, with some rare VB4 work. From there, I went to VB6, and VB.Net bears far less resemblance to VB6 than VB6 does to QBX. When I made the previous move, I brought a lot of my QBX code directly into VB6, just adding variable predeclarations; I couldn't remotely do that with VB6 and VB7. However, they're including an upgrade wizard that should take care of most of the changes, like getting rid of set statements and changing variable types. The articles that Microsoft has telling you what to what to avoid are mostly about what the wizard can't cope with.
Anyway, I don't like to talk about what they changed or upgraded, because it's just not the same thing at all. VB7 actually looks like something I won't be embarrassed about making my living at. I am pissed at their making all arrays zero-based, however.
I expect that VB7 and C# development was pretty much parallel. They made a new RAD system, with two sets of syntax, one line-oriented and verbose (VB.Net), and one semi-colon oriented and more cryptic (C#). It's just too bad that my preference is semi-colon oriented and verbose. I want to see QuickPascal.Net, damnit!
P.S. Microsoft Basic goes back to the one Bill Gates personally wrote for the Altair in 1975, not just to the 80's.
7. Distribution. With desktop apps, an x-copy will actually suffice as the install routine. All apps install their custom components into their own dirs. The system repository tracks all versions of all DLLS installed, and automatically produces the proper version for the proper app at launch time. No more DLL hell.
Granted, this will be a massive improvement. However, why not just use static linking in the first place?
I bought a reel mower for the exercise, and because I thought it would bother the neighbors less. As it turns out, it's not much harder to puch than a powered mower. However, it's not a lot quieter, either, and it works terribly. It basically takes two passes one way, and then two passes perpendicularly to cut reasonably well. It bothers the neighbors more because it's being used for so much longer.
Every time I went to mow my lawn, my neighbor would watch with a disapproving look on his face, and he eventually badgered me into hiring a lawn service. It's not worth $40 per month to not mow the lawn, but it's worth it when you throw in not having to listen to my next door neighbor.
Moore's Law isn't a fiction, although calling it a law is putting it a bit strongly. It's really just a guideline for what to expect out of the computer industry.
If you want to look for conspiricy, though, consider that Gordon Moore (who, of course, stated Moore's Law) was a major executive of Intel for many years, and CEO for part of that. I doubt there was anyone else in the world who had as much control over the rate of advance in chip technology as he did.
How about multiple CPU's on the same chip, or putting RAM on the CPU die?
C itself is very highly tuned to be easily converted into fast asm code by an entity as dumb as a compiler, but the only way it could ever compare to actual asm code would be on a CPU like the old 650X 8-bit series where there are no high-speed registers to speak of. While there are some pretty good optimizing compilers there are none that can juggle the decisions of when to use registers, the stack, and mem storage the way a human being can.
Actually, RISC designs (at least SPARC -- that's the only one I've actually had a class in) are fairly straightforward, as well. When you make a procedure call, you've got 8 registers that are exclusively used for parameter passing. Each procedure also has 8 registers for local variables that it can use without having to worry about saving what was there before. There's really not much that a person writing assembler by hand could do to improve on a good compiler.
In addition to that, the compiler is going to be better about keeping dependant instructions as far apart as possible than a person could be. That means that compiler-generated code (at least from a low-level language like C or C++) is going to have fewer pipeline stalls and, thus, be faster.
It's mainly x86 that has to be heavily tweaked to get the best performance out of it. There were probably older architectures that had similar complexities (VAX? PDP? 68xxx?), but everything but x86 has pretty much died out.
Don't forget Palm Pilots.
The really frightening thing about the WinNT ship is that it was a Ticonderoga class cruiser, just like the U.S.S. Vincennes, which accidentally shot down an Iranian airliner about 10 years ago. That's not the kind of ship you want having buggy software.
First, Robinson Crusoe was written by Daniel Defoe (No, I didn't know it off the top of my head; I checked Amazon.), but other people have mentioned that here. Second, the story you're describing is Huckleberry Finn. I'm a lot less startled by the troll than the fact that no one recognised that.
I suppose that would explain why I hadn't seen a plain Phoenix BIOS in years. I didn't realize Award was actually Phoenix, and I was starting to think they had gone out of business.
It doesn't matter what The Constitution says. If a judge orders something, no one and nothing but a higher judge can stop that order. There is no check on the judicial system.
More like a flexible printed circuit board. The instructions say to put whatever chips you need on the second level.