Incidentally, 22^124 is probably one of the worst examples you could have used, because you're stuck with only two prime factors, one of which won't come up in most measurements (can't remember the last time I had to divide a meter 11 ways).
If you had been any good at trolling, you would have picked something on the order of "By this logic, base 2310 should be even more ideal because it has lots more divisors. Hopefully, even you can figure out why this number is a better choice to troll with here.
the consensus from anyone who has used MFC in anger is what a baroque piece of junk it really is. It's like a dogshit covered icing and marzipan - superficially tempting but take a deep bite and see how much you like it.
Except that those meetings undoubtedly predated.NET.:-)
I agree--had WTL been released before MFC, or even after MFC but before 32-bit Windows, I think it would be the dominant paradigm on the Windows desktop.
But Microsoft really didn't have any incentive at all to market it, and putting it into MSDN was as good an idea (at the time) as any.
Given that Open Source is the latest business world rage, and they no longer have a huge need to prevent it from fragmenting their MFC developer base, this is a smart move (with near-zero cost) for them now, too.
Anyone who is willing to dump MFC for a better thing, and has their eyes on the future, is likely to head.NET-ward anyway.
WTL has been a bit of an embarrassment for Microsoft.
It started life as an MSDN sample app, but (to the surprise of everyone), people started actually using it. It fits nicely between the niches of MFC and ATL, supports a nice big chunk of what you need to do to get a desktop app running, and does it in a very clean, STL-friendly way. I read in an interview that some folks at MS thought it was a major mistake to release it; fortunately for them (at the time) it was pretty obscure.
I remember way back then there were a couple of calls for Microsoft to "give it away" (in terms of control, not price--it's always been gratis), but I suppose the time hasn't been politically right within Microsoft until the recent popularity of their installer program release.
Not that I blame them for not providing assistance to people who violate their copyrights, but I wonder if they actually paid someone to come up with that insightful explanation.
Yes. They're called PR people. And they all sound like that.:-)
The funny thing is, the ones I've know talk like that all the time. It's a little uncanny--having lunch with one feels like reading about your day in PC Week.
I signed up for the 'Webby' nominations last year, and got a reasonable number of emails from them (not all-out spam, but maybe 6-7).
Maybe it's just me, but the whole tone of the thing leaves me with the impression that the Webby folks have an extraordinarily high (but unfounded) opinion of themselves. Reading the mails they sent, I was transported back in time to the mid-1990s, when The New Economy was going to leave the brick-and-mortar dinosaurs choking on comet dust.
I think we may have found the last few dozen people who haven't woken up from the Internet Bubble.
That's true. The converse is that a well-designed system will make it much more difficult (but not impossible, of course) for a user to 'muck it up' than a poorly-designed system.
That's the concept of the poka-yoke or 'error-proofing' school of thought: apply design to the process such that a user will either be unable to inadvertently make a mistake, or such a mistake will be easy to spot before it affects the system.
The original poka-yoke was, if I recall correctly, in a Japanese factory. An assembly line worker had to apply a number of small parts to an assembly, and it was a common error to forget one or more of the small parts before passing the assembly down the line. The poka-yoke method was very simple: provide a tray with sections that held one of each of the small parts. The worker, before assembling, received the tray with one part in each section; after assembling, it was obvious whether any of the small parts were left over. A simple, tiny change like that reduced the error count dramatically.
Similar methods can be applied to software and IT systems.
Actually, it happens all the time. After all, you think Gateway and Dell really make their own TVs?:-)
On a more serious note, HP licenses their handheld designs to a number of folks, Philips never would have gotten very far without licensing CD player designs, Fraunhofer and Unisys did quite well licensing their respective compression technologies, Samsung licensed the design of their laptops to Best Buy (to create the "VPR Matrix" line of machines), and one of the real reasons VHS beat out Beta was that Sony (like Apple) refused to license Beta widely (I think they did, but only in a very limited fashion).
A good point. The idea of reducing the number of lines of code isn't just to reduce the amount of typing--it's mostly to reduce the amount of code you have to _read_ to understand what's going on.
For example, it's easier to see what's going on in:
for line in file("/var/log/messages"): processLine(line)
than in the equivalent C or Java code. Also, terseness isn't the ultimate goal--I could make this more terse (and less readable or efficient) by saying:
[processLine(line) for line in file("/var/log/messages")]
The biggest benefit of Python over Java, as far as I'm concerned, is that code written in Python looks like what it does--that's the source of the "Python is executable pseudocode" meme you often hear from Python fanboys. The lack of a compile step and the dynamic typing help, but they're secondary to me.
Or the Netvision phone my employer has been producing for longer than that... it's been around in frequency-hopping RF models since before WiFi existed (although newer models are WiFi compatible)
You might want to actually benchmark things before you turn off VM swap.
(Quite) a few years ago, I got a then-massive RAM upgrade and did precisely what you did. I did some benchmarking, and found out that turning off swap actually _hurt_ performance (not by much, about 10% or so for the tasks I tested).
The reason was that if the OS swaps out little-used processes, it has more room to eat up the RAM for file caching (probably the real reason XP wants 125MB while idling... the more you have, the more it takes. Linux does this, too).
This was, as I said, quite a few years ago (how long? Well, the 'beefy memory upgrade' was to 32MB, when most of the world was still at 8 or 12). But premature optimization is still the root of all evil.
[Incidentally, I went from 256MB to 512MB on my laptop... XP only ate 40MB more than it did with 256MB, but I definitely have sped up cache-friendly file operations like compiling...]
"Ounce" isn't a metric/SI unit, as far as I know, and using grams when e.g. cooking is in my experience very unusual.
Reparse that, please...
I swear, cooking is probably one of the biggest things holding the metric system back, with its much-prized teaspoons (~5 mL), tablespoons (~15 mL), cups (~200 mL), and ounces (~30 grams).
It's cooking's measurements, not the metric system's.
Although the original poster was making a weak joke, he's not far from the mark.
When our first kid was born, we did the whole childbirth class thing, followed all the advice, etc. One of the things we did which seemed really corny at the time was to take along some object to focus on during contractions to distract from the pain.
It seemed pretty silly at the time, so the second time around, we didn't bother with the 'focus item'. The first time, my wife went through with only a bit of local at the very end; the second time she needed an epidural. So as goofy as it seemed, she says that it did work...
Before outsourcing: employ n knowledgeable technical support workers, who in total field c calls per day, of which c*k require the full extent of their knowledge (k < 1.0), and c*(1-k) do not (i.e., can be handled on-script).
After outsourcing: employ some number of offshore technical support workers < n, who don't have to have as much technical knowledge, but can handle the on-script calls. Now you need some less than n knowledgeable support workers, since you're only handing c*k calls, and you're using the offshore support center to screen out the rest.
Now, your n knowledgeable support workers are competing for less than n jobs, which means you can even decrease the amount you pay them: more supply and less demand leads to lower prices.
I'm not saying this is a good outcome, or even what will really happen, but it's the logic that the purseholders are using.
Indeed, having facts just might help a little. Mosiac wasn't the first browser; it came onto the scene a good two years after the first website, and Tim Berners-Lee invented HTTP and HTML while working at CERN, in Switzerland.
According to NCSA's own page, Mosaic started development in June of 1993. The first webserver, info.cern.ch, went online in 1991.
Probably because there's a greater detectable cultural difference between the nations of Western Europe (and nations occupied mostly by them, like Canada, Australia, and the U.S.) and other nations than there are between two people from opposite ends of the UK.
The magazine and website creds aren't to introduce your brand. They're to establish your bona fides after you've made the initial contact.
Starting at zero, if your aim is a consultancy, you're far better off making personal contact with businesses in your area than advertising. Get the local business to create a buffer zone of cash flow, and then grow. The only companies that advertise out of the gate are the ones flush with investor cash (I've been in those ten years...).
Slashdot Mirror
Try "more divisors that are commonly used".
Incidentally, 22^124 is probably one of the worst examples you could have used, because you're stuck with only two prime factors, one of which won't come up in most measurements (can't remember the last time I had to divide a meter 11 ways).
If you had been any good at trolling, you would have picked something on the order of "By this logic, base 2310 should be even more ideal because it has lots more divisors. Hopefully, even you can figure out why this number is a better choice to troll with here.
Absolutely correct--just a thinko (at least the URL is correct...)
:-)
The placement of 'O', 'S', 'D', and 'N' makes it fly off the fingertips.
the consensus from anyone who has used MFC in anger is what a baroque piece of junk it really is. It's like a dogshit covered icing and marzipan - superficially tempting but take a deep bite and see how much you like it.
:-)
Thank you... this is a keeper.
Yes, it does. Unlike Sun, Microsoft chose an existing OSDN-approved license.
It's the same license, for example, that Eclipse uses.
Except that those meetings undoubtedly predated .NET. :-)
.NET-ward anyway.
I agree--had WTL been released before MFC, or even after MFC but before 32-bit Windows, I think it would be the dominant paradigm on the Windows desktop.
But Microsoft really didn't have any incentive at all to market it, and putting it into MSDN was as good an idea (at the time) as any.
Given that Open Source is the latest business world rage, and they no longer have a huge need to prevent it from fragmenting their MFC developer base, this is a smart move (with near-zero cost) for them now, too.
Anyone who is willing to dump MFC for a better thing, and has their eyes on the future, is likely to head
WTL has been a bit of an embarrassment for Microsoft.
It started life as an MSDN sample app, but (to the surprise of everyone), people started actually using it. It fits nicely between the niches of MFC and ATL, supports a nice big chunk of what you need to do to get a desktop app running, and does it in a very clean, STL-friendly way. I read in an interview that some folks at MS thought it was a major mistake to release it; fortunately for them (at the time) it was pretty obscure.
There's some history of WTL at WikiWiki.
I remember way back then there were a couple of calls for Microsoft to "give it away" (in terms of control, not price--it's always been gratis), but I suppose the time hasn't been politically right within Microsoft until the recent popularity of their installer program release.
Not that I blame them for not providing assistance to people who violate their copyrights, but I wonder if they actually paid someone to come up with that insightful explanation.
:-)
Yes. They're called PR people. And they all sound like that.
The funny thing is, the ones I've know talk like that all the time. It's a little uncanny--having lunch with one feels like reading about your day in PC Week.
I signed up for the 'Webby' nominations last year, and got a reasonable number of emails from them (not all-out spam, but maybe 6-7).
Maybe it's just me, but the whole tone of the thing leaves me with the impression that the Webby folks have an extraordinarily high (but unfounded) opinion of themselves. Reading the mails they sent, I was transported back in time to the mid-1990s, when The New Economy was going to leave the brick-and-mortar dinosaurs choking on comet dust.
I think we may have found the last few dozen people who haven't woken up from the Internet Bubble.
That's true. The converse is that a well-designed system will make it much more difficult (but not impossible, of course) for a user to 'muck it up' than a poorly-designed system.
That's the concept of the poka-yoke or 'error-proofing' school of thought: apply design to the process such that a user will either be unable to inadvertently make a mistake, or such a mistake will be easy to spot before it affects the system.
The original poka-yoke was, if I recall correctly, in a Japanese factory. An assembly line worker had to apply a number of small parts to an assembly, and it was a common error to forget one or more of the small parts before passing the assembly down the line. The poka-yoke method was very simple: provide a tray with sections that held one of each of the small parts. The worker, before assembling, received the tray with one part in each section; after assembling, it was obvious whether any of the small parts were left over. A simple, tiny change like that reduced the error count dramatically.
Similar methods can be applied to software and IT systems.
Actually, it happens all the time. After all, you think Gateway and Dell really make their own TVs? :-)
On a more serious note, HP licenses their handheld designs to a number of folks, Philips never would have gotten very far without licensing CD player designs, Fraunhofer and Unisys did quite well licensing their respective compression technologies, Samsung licensed the design of their laptops to Best Buy (to create the "VPR Matrix" line of machines), and one of the real reasons VHS beat out Beta was that Sony (like Apple) refused to license Beta widely (I think they did, but only in a very limited fashion).
It happens even more in the vertical markets.
Correct. Slashdot's tag ate the opening indent on the second line, and using blockquote made it ugly.
:-)
Anyway, I figured anyone who read it would either have enough Java and Python experience to parse it, or too clueless to catch it.
For example, it's easier to see what's going on in:
than in the equivalent C or Java code. Also, terseness isn't the ultimate goal--I could make this more terse (and less readable or efficient) by saying:
The biggest benefit of Python over Java, as far as I'm concerned, is that code written in Python looks like what it does--that's the source of the "Python is executable pseudocode" meme you often hear from Python fanboys. The lack of a compile step and the dynamic typing help, but they're secondary to me.
Generally, stylesheets overall _reduce_ the bandwidth usage of a site, mostly through the elimination of redundant tags.
Or the Netvision phone my employer has been producing for longer than that... it's been around in frequency-hopping RF models since before WiFi existed (although newer models are WiFi compatible)
You might want to actually benchmark things before you turn off VM swap.
(Quite) a few years ago, I got a then-massive RAM upgrade and did precisely what you did. I did some benchmarking, and found out that turning off swap actually _hurt_ performance (not by much, about 10% or so for the tasks I tested).
The reason was that if the OS swaps out little-used processes, it has more room to eat up the RAM for file caching (probably the real reason XP wants 125MB while idling... the more you have, the more it takes. Linux does this, too).
This was, as I said, quite a few years ago (how long? Well, the 'beefy memory upgrade' was to 32MB, when most of the world was still at 8 or 12). But premature optimization is still the root of all evil.
[Incidentally, I went from 256MB to 512MB on my laptop... XP only ate 40MB more than it did with 256MB, but I definitely have sped up cache-friendly file operations like compiling...]
"Ounce" isn't a metric/SI unit, as far as I know, and using grams when e.g. cooking is in my experience very unusual.
Reparse that, please...
I swear, cooking is probably one of the biggest things holding the metric system back, with its much-prized teaspoons (~5 mL), tablespoons (~15 mL), cups (~200 mL), and ounces (~30 grams).
It's cooking's measurements, not the metric system's.
Although the original poster was making a weak joke, he's not far from the mark.
When our first kid was born, we did the whole childbirth class thing, followed all the advice, etc. One of the things we did which seemed really corny at the time was to take along some object to focus on during contractions to distract from the pain.
It seemed pretty silly at the time, so the second time around, we didn't bother with the 'focus item'. The first time, my wife went through with only a bit of local at the very end; the second time she needed an epidural. So as goofy as it seemed, she says that it did work...
You're missing a big point here.
Before outsourcing: employ n knowledgeable technical support workers, who in total field c calls per day, of which c*k require the full extent of their knowledge (k < 1.0), and c*(1-k) do not (i.e., can be handled on-script).
After outsourcing: employ some number of offshore technical support workers < n, who don't have to have as much technical knowledge, but can handle the on-script calls. Now you need some less than n knowledgeable support workers, since you're only handing c*k calls, and you're using the offshore support center to screen out the rest.
Now, your n knowledgeable support workers are competing for less than n jobs, which means you can even decrease the amount you pay them: more supply and less demand leads to lower prices.
I'm not saying this is a good outcome, or even what will really happen, but it's the logic that the purseholders are using.
If I had mod points I'd mod you up.
Mod him up? What for-- +1, Slob?
Indeed, having facts just might help a little. Mosiac wasn't the first browser; it came onto the scene a good two years after the first website, and Tim Berners-Lee invented HTTP and HTML while working at CERN, in Switzerland.
According to NCSA's own page, Mosaic started development in June of 1993. The first webserver, info.cern.ch, went online in 1991.
Probably because there's a greater detectable cultural difference between the nations of Western Europe (and nations occupied mostly by them, like Canada, Australia, and the U.S.) and other nations than there are between two people from opposite ends of the UK.
Pragmatism trumps literal correctness.
Gird up. When you get to college, you might have to read it for an English Lit class.
They already exist. They're usually called "business incubators", and they're usually about as effective as you might imagine.
The magazine and website creds aren't to introduce your brand. They're to establish your bona fides after you've made the initial contact.
Starting at zero, if your aim is a consultancy, you're far better off making personal contact with businesses in your area than advertising. Get the local business to create a buffer zone of cash flow, and then grow. The only companies that advertise out of the gate are the ones flush with investor cash (I've been in those ten years...).
perl's the perfect language for this. It makes the easy things easy, the hard things possible, and the evil things unreadable.