My wife is getting her Ph.D. at CWRU, so I've had a chance to check out their infrastructure. CWRU jumped on the ATM bandwaggon in the early 90s, back when ATM was the holy grail of networking (was there any Byte edition that didn't have an article on ATM?), so they deployed ATM-over-fiber to every office and every dorm room on campus. Talk about misreading the future. Now I guess since they've got all that fiber in place already, they're probably thinking they might as well capitalize on it and move to gigabit. I can only assume that they're making use of the same fiber, otherwise they'd be out a whole lotta money. This is more of a case of a lucky second chance than exceptional foresight.
I'm also not particularly impressed with their IT department. They like touting their computing horn, but my wife wasn't able to obtain one of their elusive ethernet-over-ATM adapters for two summer sessions now, being forced instead to connect via their notoriously flakey PPP dial-in at glacial modem speeds--while on campus. So much for their leadership in advanced campus networking. Oh, but they do have 802.11b in their main library, so I guess they get one point for that.
Good conclusion, poor article
on
Qt vs MFC
·
· Score: 5, Insightful
While I wholehartedly agree with the conclusion, I must say that the article is a mess and feels like it was written by a 16-year old. It's barely comparative, sticking to the format that feature X is messy in MFC and much easier in Qt, and here's an example of just how easy. He doesn't give any MFC code examples, mainly limiting himself to explaining the horrors of Unicode and resources. An objective reader could hardly take this for a serious comparison of the two frameworks.
Besides, it's really comparing apples and oranges. Anyone who's used the MFC at all knows that it's hardly OO. A much fairer comparison would be that of Qt to Borland's VCL. In many respects they're very, very similar, but it seems that the nod of more consistent OO design would go to the VCL. I base this mainly on the event-handling semantics of both toolkits. While Qt falls back to straight C (or possibly even a macro? shudder!) for connecting an event handler to a component, the VCL stays faithfully OO, implementing event handlers as method pointers (exposed as properties) on components.
Continuing the example used in the article, Qt reads:
Anyway, as I said, while I support the conclusion of the article, based on its lack of maturity I wouldn't use it to try to convert existing MFC programmers.
If I remember correctly, the original Moxi system had optional set-top boxes that you could string via Ethernet throughout the house to watch content off the main box on other TVs. That's what I found the most appealing about the Moxi. The rest is hardly an improvement over the current TiVo devices.
There's one type of code generation that I appreciate, and that's auto-generated event handlers (such as when double-clicking on a button on a form in design mode). But even there I prefer Borland's way of doing things: smart enough to keep element and event handler names synchronized, and to know that when an event handler isn't used anymore to delete it at compile time. VS.NET seems to have better two-way synchronization, but I haven't used it that much yet.
VCD data rates are around 1150 Kbps, and since this device most likely compresses the video on the fly on-board and uploads it to the computer, there's theoretically plenty of bandwidth in the 12 Mbps spec of USB 1.1, even allowing for lots of overhead and other data streams.
Use an existing (cheap) sat tuner and use the composite out. Then you connect a COM port to the data port on the sat tuner, leaving you with just one problem: software support for tuning via the COM port. Maybe they'll include that later in a software update, who knows. That's what the TiVo does anyway.
There are plenty of shows on the History channel and TLC that I haven't seen yet, plus I can time-shift European news from ungodly hours to when I'm awake, plus I can timeshift HBO (or Starz etc) movies from 1am on some week night to the weekend, plus I can fill the drive with Clifford and Little Bear for my toddler twins. Right now for example I'm watching "From the Earth to the Moon" on HBO (which I never got around to seeing when it first came out) piecemeal here and there when I have a few moments, always staying nicely bookmarked when switching to other shows. And yes, Enterprise keeps showing up in the What's On list, but they're all re-runs until this fall.
Of course, that requires moving to Object Pascal (for now). But if you're using the CLX, you're in for the easiest porting job of your life. It also requires shelling out some money for Delphi Professional on Windows, since the Personal Edition (free) doesn't support CLX development. But since you're considering the MFC anyway, I assume you're not afraid to pay for your tools.
Later this summer, Kylix 3 will support cross-platform C++ development via C++ Builder on Windows. But even learning Object Pascal is not that daunting--I've seen many C++ programmers become proficient in a matter of weeks.
> I always felt if someone thought VS's "automatic code generation" is anything > other than an annoying waste of time, you've either never used it, or are only a > cookbook programmer
Yeah, automatic code generation is great if you know exactly what you want from the beginning. It'll spit out megabytes of code for you, which even compiles. But start fleshing out this code a bit, and then change your mind about GUI layout or program structure, and you're in one-way-wizard hell. Basically, duplicating the type of code the wizards generate by hand is a massive amount of very tedious work. Rather than delegating (and hiding) tedious setup code to base classes that your code inherits from, the MFC instead relies on wizards to take the tedium away. According to Microsoft, Inheritance + Polymorphism = Wizards (essentially).
Re:Clarifications on VC++, Qt
on
wxWindows vs. MFC
·
· Score: 3, Insightful
> VC++ and wxWindows both require lots of macros, however.
Learning MFC is learning Microsoft Macro(TM). It's the most shallow and unambitious class framework I've ever seen, almost to the point of making you wonder why they even bothered with C++ (the templates I guess). Doing anything remotely interesting with the GUI requires falling back to messages and win32 calls. If you look at serious class frameworks (Borland's original OWL, then VCL, Java,.NET), they're so similar in many respects (not by accident either) that learning one makes you comfortable in all the other ones. Leaning MFC OTOH prepares you for not much else. You might as well learn win32 API (well, you have to anyway), since at least you could then create your own framework.
> As I understood it, a later version or Kylix (one this fall, maybe?) is > supposed to support coding in C++.
Yes, Kylix 3, which is expected sometime this summer supposedly. And the CLX is indeed based on Qt, so on Windows you'd essentially end up with a run-time DLL a la MFC42.DLL for Qt. Not a major thing really, but as an alternative you could stick to plain VCL on Windows and try to isolate (and keep to a minimum) any necessary win32 code such that you could rewrite that code in Kylix using available Linux libraries. VCL code tends to port over to CLX code pretty easily (often verbatim if I remember correctly, at least for many GUI elements), so on Windows you can still have Qt-free code and still have a pretty portable project. This tends to be harder for database apps, since I believe the CLX introduces a new db abstraction model, but for GUI and networking code (use Indy) it's pretty straight forward.
I grew up in a household where TV was banned because of religious dogma and only had my first TV after I moved out. I've since given up any sort of dogmatic principles I'm aware of, so giving up the TV would transponse me mentally too much back to that time of the Book of Sins. Besides, TiVo has seriously reduced my dependence on TV and despotic scheduling. If I'm watching a show I enjoy, but would rather be doing something else at the moment, I simply record and pause it, making it trivial to come back at a later time to continue where I left off. In principle not that different than VCR taping, but oh what a difference in impulse TV switch-off it makes.
Most Mac users I've met fall in the category of superficially computer literate people: to most of their friends and relatives they appear computer savy because they don't seem intimidated by computers and know most of the lingo, when in fact they gravitate to the Mac because it has a reputation of simplicity and because they do tend to be intimidated by most other platforms. I've also noticed that Macs tend to be prefered by the aesthetically inclined: the sort of people that have a spotless home with lots of art on the walls and an inkling for sophisticated personal appearance. A Mac is simply artsier than most other platforms.
If you were to really make any generalizations regarding the intelligence of a certain platform's users, I think traditional Unix in general tends to be the hands down winner. The knowledge and memory required for just average productivity tend to be much higher than for most other platforms, and the arcane nature of accomplishing many tasks requires the sort of tenacity and persistence that only true conviction can provide.
The convenience of mobility is great. My wife has an Inspiron 8000 with a huge display, and in most respects it's a complete desktop replacement--except for the keyboard. I have yet to see a laptop keyboard that's any good for coding for extended periods. The cursor and Home/End/Insert/Delete keys are always compromised in size and especially position and arrangement. The Dells for example place the Ins/Del cluster at the top right, well out of easy reach, and they're also half size, seriously increasing the probability of hitting the wrong key. I love using my wife's Dell for most things, but when it comes to editing text, I pass.
> But to offer "all-you-eat" access, and advertise it as such, and then say "Oh, wait a > minute- it's only all-you-can if you don't eat much" is a bit ridiculous.
You're exactly right, and that's where the providers will have to make up their minds: keep advertising broadband as this limitless multimedia experience and risk not being able to deliver, or set more realistic expectations? Frankly, I think they're still making it easy on themselves by not really improving their infrastructure. The initial cable modem deployment went relatively swiftly because they already had the wire in place. But now in many places that one wire isn't enough anymore, and they're in the same position as the DSL providers.
You're talking about how you think broadband SHOULT work, not how it works today. For all practical purposes cable service and all-you-can-eat buffets today work the same way: they charge you a flat rate for an ostensibly unlimited amount of product. That is what the restaurant advertises, and that is what Comcast advertises. What exactly are the "fundamental differences" that you're talking about (other than that one sells food, while the other sells a data service)?
The buffet analogy is perfect in this case. In your toll bridge case, the car would have to expand or contract based on the number of people on board, which it doesn't. Think of it as a gate of a certain fixed width and you're selling tickets for people to pass through. Five fat people can pass through side-by-side, or ten skinny ones. Would you rather be selling five tickets or ten?
Ideally cable providers should be throtteling bandwidth and providing bandwidth service levels. If they sell you 1.5Mbps for $50 a month, you should be able to download at 1.5Mbps all year long, every second of the day. But then you shouldn't be able to ever burst 6Mbps. However, this isn't the case with most providers. Comcast provides me with what they term a peak of 1.5Mbps, but in actual fact I often get much, much more than that. Depending on the time of day and day of week, I can max at 6Mbps. If they're not having a bandwidth crunch in my area, that might be fine, but if they're hurting and still not capping the bandwidth, whose fault is that? Certainly theirs. I don't know if bandwidth throtteling is such a technically challenging issue, but it seems that enforcing download caps in MB/month rather than bits/second is taking the easy way out.
The most useful audio gadget in the car to me would be a radio version of the TiVo. So often I listen to a piece of music, or an NPR story, but have to leave the car for half an hour or so, and miss out on the rest of the program. When I get back in the car I would love to be able to continue where I left off before. This sort of thing would be so easy and cheap to do nowadays, with a 5G HD or less, and fairly little power consumption to run off the car battery for an hour or so. Since all the hardware is in the anyway, it might as well play MP3, but thinking of (and marketing) more than one feature seems beyond the capabilities of most companies, so I'll just take the radio TiVo.
> Americans typicaly spend much more money on things like mortgages, > cars, and insurance than the Japanese do.
Nice theory, but not likely. Have you seen typical Japanese rents? For that matter, even the average European apartment rent is higher than the average American mortgage. Cars maybe, but not apartments. Even so, cars might not sell well in large Japanses cities, but overall Japan is still one of the largest automobile consumers in the world, so someone must be buying them.
> a computer could conceivably generate realtime holographic displays by > calculating the interference pattern
I think that's where the real future of holograms lies. Conventional (high resolution, non-rainbow type) holograms are extremely hard to produce for two reasons: they can only create 1:1 scale images, and require an extremely stable benchtop, since the slightest movement or vibration will still be much larger than the wavelength of light, seriously disrupting the interference patterns. OTOH, a computer-generated hologram has none of these limitations, since it doesn't require an actual physical object. In fact, you could generate holograms of actual physical scenes by photographing them Matrix-style with cameras arranged circularly and then generating the interference patterns from that. Or you could even use one of these newfangled camera setups with position and attitude sensors to "paint" a scene and then generate a hologram at any scale from that.
IIRC, high-rez holograms use emulsions with about 1000 lines per mm, so that's the type of display resolution required for high quality holograms. You might get by with less for acceptable quality, though. I think we'll see holographic displays like this along with the requisite computing power within the next 10-15 years.
Heh, that should be a new law: as a Slashdot thread grows longer, the probability of Monty Python or one of their characters or sketches being mentioned approaches one.
> The basic premise is that you get very light, very aerodynamic, much lubrication, and thin > tires with a large diameter to reduce rolling resistance.
And that you find two perfectly serviceable engines and working batteries in a junkyard full of stuff that people threw away because it didn't work anymore to begin with.
Slashdot Mirror
My wife is getting her Ph.D. at CWRU, so I've had a chance to check out their infrastructure. CWRU jumped on the ATM bandwaggon in the early 90s, back when ATM was the holy grail of networking (was there any Byte edition that didn't have an article on ATM?), so they deployed ATM-over-fiber to every office and every dorm room on campus. Talk about misreading the future. Now I guess since they've got all that fiber in place already, they're probably thinking they might as well capitalize on it and move to gigabit. I can only assume that they're making use of the same fiber, otherwise they'd be out a whole lotta money. This is more of a case of a lucky second chance than exceptional foresight.
I'm also not particularly impressed with their IT department. They like touting their computing horn, but my wife wasn't able to obtain one of their elusive ethernet-over-ATM adapters for two summer sessions now, being forced instead to connect via their notoriously flakey PPP dial-in at glacial modem speeds--while on campus. So much for their leadership in advanced campus networking. Oh, but they do have 802.11b in their main library, so I guess they get one point for that.
While I wholehartedly agree with the conclusion, I must say that the article is a mess and feels like it was written by a 16-year old. It's barely comparative, sticking to the format that feature X is messy in MFC and much easier in Qt, and here's an example of just how easy. He doesn't give any MFC code examples, mainly limiting himself to explaining the horrors of Unicode and resources. An objective reader could hardly take this for a serious comparison of the two frameworks.
Besides, it's really comparing apples and oranges. Anyone who's used the MFC at all knows that it's hardly OO. A much fairer comparison would be that of Qt to Borland's VCL. In many respects they're very, very similar, but it seems that the nod of more consistent OO design would go to the VCL. I base this mainly on the event-handling semantics of both toolkits. While Qt falls back to straight C (or possibly even a macro? shudder!) for connecting an event handler to a component, the VCL stays faithfully OO, implementing event handlers as method pointers (exposed as properties) on components.
Continuing the example used in the article, Qt reads:
connect( button, SIGNAL( clicked() ), SLOT( action() ) );
while the VCL would read:
button.OnClick = action;
Anyway, as I said, while I support the conclusion of the article, based on its lack of maturity I wouldn't use it to try to convert existing MFC programmers.
You'd think they'd come up with something a little less slabby given all that background.
If I remember correctly, the original Moxi system had optional set-top boxes that you could string via Ethernet throughout the house to watch content off the main box on other TVs. That's what I found the most appealing about the Moxi. The rest is hardly an improvement over the current TiVo devices.
There's one type of code generation that I appreciate, and that's auto-generated event handlers (such as when double-clicking on a button on a form in design mode). But even there I prefer Borland's way of doing things: smart enough to keep element and event handler names synchronized, and to know that when an event handler isn't used anymore to delete it at compile time. VS.NET seems to have better two-way synchronization, but I haven't used it that much yet.
VCD data rates are around 1150 Kbps, and since this device most likely compresses the video on the fly on-board and uploads it to the computer, there's theoretically plenty of bandwidth in the 12 Mbps spec of USB 1.1, even allowing for lots of overhead and other data streams.
Use an existing (cheap) sat tuner and use the composite out. Then you connect a COM port to the data port on the sat tuner, leaving you with just one problem: software support for tuning via the COM port. Maybe they'll include that later in a software update, who knows. That's what the TiVo does anyway.
There are plenty of shows on the History channel and TLC that I haven't seen yet, plus I can time-shift European news from ungodly hours to when I'm awake, plus I can timeshift HBO (or Starz etc) movies from 1am on some week night to the weekend, plus I can fill the drive with Clifford and Little Bear for my toddler twins. Right now for example I'm watching "From the Earth to the Moon" on HBO (which I never got around to seeing when it first came out) piecemeal here and there when I have a few moments, always staying nicely bookmarked when switching to other shows. And yes, Enterprise keeps showing up in the What's On list, but they're all re-runs until this fall.
Of course, that requires moving to Object Pascal (for now). But if you're using the CLX, you're in for the easiest porting job of your life. It also requires shelling out some money for Delphi Professional on Windows, since the Personal Edition (free) doesn't support CLX development. But since you're considering the MFC anyway, I assume you're not afraid to pay for your tools.
Later this summer, Kylix 3 will support cross-platform C++ development via C++ Builder on Windows. But even learning Object Pascal is not that daunting--I've seen many C++ programmers become proficient in a matter of weeks.
> I always felt if someone thought VS's "automatic code generation" is anything
> other than an annoying waste of time, you've either never used it, or are only a
> cookbook programmer
Yeah, automatic code generation is great if you know exactly what you want from the beginning. It'll spit out megabytes of code for you, which even compiles. But start fleshing out this code a bit, and then change your mind about GUI layout or program structure, and you're in one-way-wizard hell. Basically, duplicating the type of code the wizards generate by hand is a massive amount of very tedious work. Rather than delegating (and hiding) tedious setup code to base classes that your code inherits from, the MFC instead relies on wizards to take the tedium away. According to Microsoft, Inheritance + Polymorphism = Wizards (essentially).
> VC++ and wxWindows both require lots of macros, however.
.NET), they're so similar in many respects (not by accident either) that learning one makes you comfortable in all the other ones. Leaning MFC OTOH prepares you for not much else. You might as well learn win32 API (well, you have to anyway), since at least you could then create your own framework.
Learning MFC is learning Microsoft Macro(TM). It's the most shallow and unambitious class framework I've ever seen, almost to the point of making you wonder why they even bothered with C++ (the templates I guess). Doing anything remotely interesting with the GUI requires falling back to messages and win32 calls. If you look at serious class frameworks (Borland's original OWL, then VCL, Java,
> As I understood it, a later version or Kylix (one this fall, maybe?) is
> supposed to support coding in C++.
Yes, Kylix 3, which is expected sometime this summer supposedly. And the CLX is indeed based on Qt, so on Windows you'd essentially end up with a run-time DLL a la MFC42.DLL for Qt. Not a major thing really, but as an alternative you could stick to plain VCL on Windows and try to isolate (and keep to a minimum) any necessary win32 code such that you could rewrite that code in Kylix using available Linux libraries. VCL code tends to port over to CLX code pretty easily (often verbatim if I remember correctly, at least for many GUI elements), so on Windows you can still have Qt-free code and still have a pretty portable project. This tends to be harder for database apps, since I believe the CLX introduces a new db abstraction model, but for GUI and networking code (use Indy) it's pretty straight forward.
I grew up in a household where TV was banned because of religious dogma and only had my first TV after I moved out. I've since given up any sort of dogmatic principles I'm aware of, so giving up the TV would transponse me mentally too much back to that time of the Book of Sins. Besides, TiVo has seriously reduced my dependence on TV and despotic scheduling. If I'm watching a show I enjoy, but would rather be doing something else at the moment, I simply record and pause it, making it trivial to come back at a later time to continue where I left off. In principle not that different than VCR taping, but oh what a difference in impulse TV switch-off it makes.
> Channel surfing is addictive.
Get a stand-alone TiVo with a sat receiver, and you'll never channel surf again--because it's too painful.
Most Mac users I've met fall in the category of superficially computer literate people: to most of their friends and relatives they appear computer savy because they don't seem intimidated by computers and know most of the lingo, when in fact they gravitate to the Mac because it has a reputation of simplicity and because they do tend to be intimidated by most other platforms. I've also noticed that Macs tend to be prefered by the aesthetically inclined: the sort of people that have a spotless home with lots of art on the walls and an inkling for sophisticated personal appearance. A Mac is simply artsier than most other platforms.
If you were to really make any generalizations regarding the intelligence of a certain platform's users, I think traditional Unix in general tends to be the hands down winner. The knowledge and memory required for just average productivity tend to be much higher than for most other platforms, and the arcane nature of accomplishing many tasks requires the sort of tenacity and persistence that only true conviction can provide.
Godwin's law is supposed to occur at a lower point in the thread, not preemptively abort it at the root.
The convenience of mobility is great. My wife has an Inspiron 8000 with a huge display, and in most respects it's a complete desktop replacement--except for the keyboard. I have yet to see a laptop keyboard that's any good for coding for extended periods. The cursor and Home/End/Insert/Delete keys are always compromised in size and especially position and arrangement. The Dells for example place the Ins/Del cluster at the top right, well out of easy reach, and they're also half size, seriously increasing the probability of hitting the wrong key. I love using my wife's Dell for most things, but when it comes to editing text, I pass.
> But to offer "all-you-eat" access, and advertise it as such, and then say "Oh, wait a
> minute- it's only all-you-can if you don't eat much" is a bit ridiculous.
You're exactly right, and that's where the providers will have to make up their minds: keep advertising broadband as this limitless multimedia experience and risk not being able to deliver, or set more realistic expectations? Frankly, I think they're still making it easy on themselves by not really improving their infrastructure. The initial cable modem deployment went relatively swiftly because they already had the wire in place. But now in many places that one wire isn't enough anymore, and they're in the same position as the DSL providers.
You're talking about how you think broadband SHOULT work, not how it works today. For all practical purposes cable service and all-you-can-eat buffets today work the same way: they charge you a flat rate for an ostensibly unlimited amount of product. That is what the restaurant advertises, and that is what Comcast advertises. What exactly are the "fundamental differences" that you're talking about (other than that one sells food, while the other sells a data service)?
The buffet analogy is perfect in this case. In your toll bridge case, the car would have to expand or contract based on the number of people on board, which it doesn't. Think of it as a gate of a certain fixed width and you're selling tickets for people to pass through. Five fat people can pass through side-by-side, or ten skinny ones. Would you rather be selling five tickets or ten?
Ideally cable providers should be throtteling bandwidth and providing bandwidth service levels. If they sell you 1.5Mbps for $50 a month, you should be able to download at 1.5Mbps all year long, every second of the day. But then you shouldn't be able to ever burst 6Mbps. However, this isn't the case with most providers. Comcast provides me with what they term a peak of 1.5Mbps, but in actual fact I often get much, much more than that. Depending on the time of day and day of week, I can max at 6Mbps. If they're not having a bandwidth crunch in my area, that might be fine, but if they're hurting and still not capping the bandwidth, whose fault is that? Certainly theirs. I don't know if bandwidth throtteling is such a technically challenging issue, but it seems that enforcing download caps in MB/month rather than bits/second is taking the easy way out.
The most useful audio gadget in the car to me would be a radio version of the TiVo. So often I listen to a piece of music, or an NPR story, but have to leave the car for half an hour or so, and miss out on the rest of the program. When I get back in the car I would love to be able to continue where I left off before. This sort of thing would be so easy and cheap to do nowadays, with a 5G HD or less, and fairly little power consumption to run off the car battery for an hour or so. Since all the hardware is in the anyway, it might as well play MP3, but thinking of (and marketing) more than one feature seems beyond the capabilities of most companies, so I'll just take the radio TiVo.
> Americans typicaly spend much more money on things like mortgages,
> cars, and insurance than the Japanese do.
Nice theory, but not likely. Have you seen typical Japanese rents? For that matter, even the average European apartment rent is higher than the average American mortgage. Cars maybe, but not apartments. Even so, cars might not sell well in large Japanses cities, but overall Japan is still one of the largest automobile consumers in the world, so someone must be buying them.
> a computer could conceivably generate realtime holographic displays by
> calculating the interference pattern
I think that's where the real future of holograms lies. Conventional (high resolution, non-rainbow type) holograms are extremely hard to produce for two reasons: they can only create 1:1 scale images, and require an extremely stable benchtop, since the slightest movement or vibration will still be much larger than the wavelength of light, seriously disrupting the interference patterns. OTOH, a computer-generated hologram has none of these limitations, since it doesn't require an actual physical object. In fact, you could generate holograms of actual physical scenes by photographing them Matrix-style with cameras arranged circularly and then generating the interference patterns from that. Or you could even use one of these newfangled camera setups with position and attitude sensors to "paint" a scene and then generate a hologram at any scale from that.
IIRC, high-rez holograms use emulsions with about 1000 lines per mm, so that's the type of display resolution required for high quality holograms. You might get by with less for acceptable quality, though. I think we'll see holographic displays like this along with the requisite computing power within the next 10-15 years.
Heh, that should be a new law: as a Slashdot thread grows longer, the probability of Monty Python or one of their characters or sketches being mentioned approaches one.
> The basic premise is that you get very light, very aerodynamic, much lubrication, and thin
> tires with a large diameter to reduce rolling resistance.
And that you find two perfectly serviceable engines and working batteries in a junkyard full of stuff that people threw away because it didn't work anymore to begin with.