What BS. There are as many styles of parenting and educating 'gifted' kids as there are 'non-gifted' kids. If anything, the parenting paradigm I see most frequently (as the parent of a 'gifted' 9-year-old) trends towards pushing their kids harder.
Well, by definition.NET is Windows-only. The underlying Common Language Interpreter doesn't have to be. IIRC, Microsoft released a couple of non-Windows versions of the CLI when.NET was first released, including one that ran on some flavor of BSD.
Nothing whatsoever? No, there's no user test for TV, hence my saying that they "aren't entirely comparable." But where I think you're missing the point is that it would be relatively trivial for a government to impose a licensing scheme upon users, therefore making the idea not quite so 'ridiculous.'
I mean really, what would the test consist of? How about a series of check boxes attached to your tax/license form stating that the user understands that they need to install anti-virus software/not click on random attachments/not respond to spam/not share files illegally along with another checkbox stating that the user understands that they may be held criminally liable should they fail to follow these or other 'safe computing' practices, oh, and by the way, if we find that you're engaging in any of these things, your ISP will be required to shut you off.
Boom. Done. Pay your fee please, you've just been licensed.
I would have thought so as well, had I not seen how Britain's TV tax unfolded a few years ago. I know the two situations aren't entirely comparable, but still... Many countries charge license fees for television access - how much of a leap would that be to internet access?
I don't think that there's any bidding for data collection - the Census Bureau is already setting up pilot data collection sites for 2008, and it looks like they're performing all the hiring. I'm not sure if they're allowed to oursource data collection under law.
As for the process... The process is already pretty automated; I'm not sure if the Census Bureau has used Computer-Assisted Personal Interviewing (CAPI) for the decennial census before, but they're issuing some sort of handheld device to their field interviewers in 2010. Speaking as someone who has worked in the private sector on large government surveys, the data collection process is pretty robust, even when done with manual forms.
I'm not sure that Google's expertise really applies to crunching census data. Storing and indexing, sure; but analyzing? Not so much. Publishing? Perhaps, but there are tons of rules and regulations that govern the Census Bureau's procedures...
Too many Linux on desktop advocates are waiting for this magical day where 50% of Windows users will wake up, throw out their computers, and buy Linux machines... it won't happen that way.
Never said that it would, and I don't disagree.
A small shop, 2-3 coders, that makes a niche product, or an IT team with legacy code to support, now has a viable path to making Linux/OS X viable options. As Mono is free, it's also not unreasonable to bundle Mono/Application and sell it for OS X and Linux now (if you are a small shop, it's eventually going to become a weekend project), or at least keep that option open.
As it happens, our shop falls into the first category. We've got a niche product that we're going to be marketing to academics; given the degree to which academia uses Macs and FOSS, we've got a very strong interest in being as platform agnostic as possible.
I still think you're overstating the willingness of VB6 shops to modernize. Even here in the heart of Microsoft country, there are still some good-sized VB6 teams. I recently finished reading Dreaming in Code http://www.dreamingincode.com/, and one of the lines in the book really struck me: The majority of programmers never read books about programming. In my experience, I feel pretty safe generalizing this out to "The majority of programmers don't think about programming more than they have to." They do what's asked of them, and there are a lot of people out there who are content to take home a paycheck and don't show any interest in pushing beyond their current skill set (or pushing it any further than their managers ask of them).
In non-ISV settings, there's a lot of bureaucratic disincentive to migrate applications, even those with relatively straightforward paths like VB6 --> VB.NET. And for VBA apps, that automated conversion path doesn't exist at all. That alone will likely guarantee a demand for VB6 devs for at least another couple iterations of.NET.
There are a ton of unconverted VB6 apps out there, largely for the same reason that there are a lot of mainframe apps still out there - they work, so why mess with them? In addition to these straight-up VB6 apps, there are many VBA projects attached to Excel or Access. A lot of the "screwy niche verticals"/in-house apps you're describing are Access & Excel apps built w/ VBA. These will not run on Mono, not now, not ever.
I'd also hesitate to call converting VB6 to VB.NET 'trivial' - the less trivial your VB6 app, the more non-trivial that conversion becomes.
An interesting aside: Microsoft's roadmap for Office-based development involves pushing Visual Studio Tools for Office, a.NET-based (C#/VB.NET) IDE to replace VBA. While I can't see Office ever running on Mono, I can easily see the ability to offer a Mono-based app that includes an Office-/VBA-style IDE for advanced customization and automation options.
Re:If you are that old, ACCEPT IT!
on
Jim Gray Is Missing
·
· Score: 2, Insightful
What's to accept? These days '60-ish' isn't exactly old, never mind 'very old'. My parents are far healthier at this age (mid-60s) than their parents ever were.
Also, sailing isn't an 'extreme sport'. Sailing solo is inherently risky, regardless of age, and regardless of the size of the boat.
Well... Not entirely a single implementation - many apps use the shdocvw.dll, something that has worked since (IIRC) IE4. This has proved to be particularly painful for VB6 developers; one suggested resolution involves writing a C++ COM wrapper around the new version of shdocvw, not something I see a lot of VB6 developers doing...
We've run into a problem with it in a.NET WinForms app as well; not in the apps behavior itself, but in the behavior of Visual Studio 2003. We have a control that displays a dynamically generated HTML doc; updating our classes to reflect the new IE7 architecture was in itself trivial. The problem we're seeing now is that whenever we load a project that uses our control, the new version of shdocvw attempts to load a dll that doesn't exist anymore (dwmapi.dll, I think). This doesn't cause any immediate errors, since dwmapi is a late-bound dll and our control doesn't use any of its functionality. It does, however, cause Visual Studio to do something funky when it loads a project that references our control - it loads the most recently-compiled version of the control and it winds up getting locked, throwing 'access denied' exceptions when the project is compiled.
The error is similar to one thrown when using a COM reference with a corrupted Interop assembly; unfortunately in this case recreating the Interop assembly for shdocvw doesn't fix the problem. The only work-around we've found is to reboot the PC and delete our control's dll before reopening Visual Studio. I'm sure there's a reference in one of the projects in our solution that has gone sideways, and once we find it and fix it we'll be more or less good to go - but we only ran into this issue on Friday, so this cheesy kludge is all we've got at this time... We could rewrite our control to use.NET 2.0 and leverage the new.NET Browser Control (which is what we'll problably wind up doing), but we haven't upgraded to VS2005 yet.
Microsoft has offered an SDK for ISVs since, oh, the mid- to late-90's that allowed them to extend their own products with a VBA environment. I don't see how this is so different.
Not because of word choice, but because of the construction of the title: cause and effect have been reversed - extinctions are causing wobble, not wobble causing extinction.
Re:yet Lunix fags will still hate it
on
Why Vista Won't Suck
·
· Score: 0, Offtopic
Or more specifically, Boston/North Shore... All I could think when I saw the title was old-school WBCN - something along the lines of "'Ricky from Revere' does Java".
What BS. There are as many styles of parenting and educating 'gifted' kids as there are 'non-gifted' kids. If anything, the parenting paradigm I see most frequently (as the parent of a 'gifted' 9-year-old) trends towards pushing their kids harder.
Whoops... I missed the context entirely. I've recently been immersed in a project requiring Java & .NET interop, so I've had it on the brain.
Not to pick nits, but to say that .NET and Java are incompatible with one another isn't true.
Mono is multi-platform .NET is not.
.NET is Windows-only. The underlying Common Language Interpreter doesn't have to be. IIRC, Microsoft released a couple of non-Windows versions of the CLI when .NET was first released, including one that ran on some flavor of BSD.
Well, by definition
I didn't say that I was in favor of such a scheme; just that it would be fairly easy for a government entity to implement...
Nothing whatsoever? No, there's no user test for TV, hence my saying that they "aren't entirely comparable." But where I think you're missing the point is that it would be relatively trivial for a government to impose a licensing scheme upon users, therefore making the idea not quite so 'ridiculous.'
I mean really, what would the test consist of? How about a series of check boxes attached to your tax/license form stating that the user understands that they need to install anti-virus software/not click on random attachments/not respond to spam/not share files illegally along with another checkbox stating that the user understands that they may be held criminally liable should they fail to follow these or other 'safe computing' practices, oh, and by the way, if we find that you're engaging in any of these things, your ISP will be required to shut you off.
Boom. Done. Pay your fee please, you've just been licensed.
I don't think that there's any bidding for data collection - the Census Bureau is already setting up pilot data collection sites for 2008, and it looks like they're performing all the hiring. I'm not sure if they're allowed to oursource data collection under law.
As for the process... The process is already pretty automated; I'm not sure if the Census Bureau has used Computer-Assisted Personal Interviewing (CAPI) for the decennial census before, but they're issuing some sort of handheld device to their field interviewers in 2010. Speaking as someone who has worked in the private sector on large government surveys, the data collection process is pretty robust, even when done with manual forms.
I'm not sure that Google's expertise really applies to crunching census data. Storing and indexing, sure; but analyzing? Not so much. Publishing? Perhaps, but there are tons of rules and regulations that govern the Census Bureau's procedures...
There are wizards that will import office docs and convert VBA modules after they are exported - http://msdn2.microsoft.com/en-us/library/aa537176( office.11).aspx#officevstoexcelvbamigration_migrat ingprojectsfromvbatovsto/ but not UserForms in Excel. I'm curious what the process is like with an Access-based VBA app.
So I'll take that part back - but not the part about inertia and disincentives...
I still think you're overstating the willingness of VB6 shops to modernize. Even here in the heart of Microsoft country, there are still some good-sized VB6 teams. I recently finished reading Dreaming in Code http://www.dreamingincode.com/, and one of the lines in the book really struck me: The majority of programmers never read books about programming. In my experience, I feel pretty safe generalizing this out to "The majority of programmers don't think about programming more than they have to." They do what's asked of them, and there are a lot of people out there who are content to take home a paycheck and don't show any interest in pushing beyond their current skill set (or pushing it any further than their managers ask of them).
In non-ISV settings, there's a lot of bureaucratic disincentive to migrate applications, even those with relatively straightforward paths like VB6 --> VB.NET. And for VBA apps, that automated conversion path doesn't exist at all. That alone will likely guarantee a demand for VB6 devs for at least another couple iterations of
There are a ton of unconverted VB6 apps out there, largely for the same reason that there are a lot of mainframe apps still out there - they work, so why mess with them? In addition to these straight-up VB6 apps, there are many VBA projects attached to Excel or Access. A lot of the "screwy niche verticals"/in-house apps you're describing are Access & Excel apps built w/ VBA. These will not run on Mono, not now, not ever.
.NET-based (C#/VB.NET) IDE to replace VBA. While I can't see Office ever running on Mono, I can easily see the ability to offer a Mono-based app that includes an Office-/VBA-style IDE for advanced customization and automation options.
I'd also hesitate to call converting VB6 to VB.NET 'trivial' - the less trivial your VB6 app, the more non-trivial that conversion becomes.
An interesting aside: Microsoft's roadmap for Office-based development involves pushing Visual Studio Tools for Office, a
What's to accept? These days '60-ish' isn't exactly old, never mind 'very old'. My parents are far healthier at this age (mid-60s) than their parents ever were. Also, sailing isn't an 'extreme sport'. Sailing solo is inherently risky, regardless of age, and regardless of the size of the boat.
Well... Not entirely a single implementation - many apps use the shdocvw.dll, something that has worked since (IIRC) IE4. This has proved to be particularly painful for VB6 developers; one suggested resolution involves writing a C++ COM wrapper around the new version of shdocvw, not something I see a lot of VB6 developers doing...
.NET WinForms app as well; not in the apps behavior itself, but in the behavior of Visual Studio 2003. We have a control that displays a dynamically generated HTML doc; updating our classes to reflect the new IE7 architecture was in itself trivial. The problem we're seeing now is that whenever we load a project that uses our control, the new version of shdocvw attempts to load a dll that doesn't exist anymore (dwmapi.dll, I think). This doesn't cause any immediate errors, since dwmapi is a late-bound dll and our control doesn't use any of its functionality. It does, however, cause Visual Studio to do something funky when it loads a project that references our control - it loads the most recently-compiled version of the control and it winds up getting locked, throwing 'access denied' exceptions when the project is compiled.
.NET 2.0 and leverage the new .NET Browser Control (which is what we'll problably wind up doing), but we haven't upgraded to VS2005 yet.
We've run into a problem with it in a
The error is similar to one thrown when using a COM reference with a corrupted Interop assembly; unfortunately in this case recreating the Interop assembly for shdocvw doesn't fix the problem. The only work-around we've found is to reboot the PC and delete our control's dll before reopening Visual Studio. I'm sure there's a reference in one of the projects in our solution that has gone sideways, and once we find it and fix it we'll be more or less good to go - but we only ran into this issue on Friday, so this cheesy kludge is all we've got at this time... We could rewrite our control to use
Microsoft has offered an SDK for ISVs since, oh, the mid- to late-90's that allowed them to extend their own products with a VBA environment. I don't see how this is so different.
Not because of word choice, but because of the construction of the title: cause and effect have been reversed - extinctions are causing wobble, not wobble causing extinction.
What, you think you're on a WoW server?? WTF?
Or more specifically, Boston/North Shore... All I could think when I saw the title was old-school WBCN - something along the lines of "'Ricky from Revere' does Java".