It's about time.
http://www.wtop.com/?sid=150989&nid=25
http://zdnet.com.com/2100-1104_2-5120673.html?tag=zdfd.newsfeed
Excerpts from Derrill Holly's article, WTOP:
Two North Carolina men were the first people charged under Virginia's anti-spam law, authorities said Thursday.
The two allegedly sent e-mails promoting investment schemes, computer software and other products. Both men are expected to be extradited to face charges in Loudoun County, Va., because many of the e-mail servers which handled the spam messages are located there.
Kilgore said although these are the first indictments, it is likely his computer crimes unit will be busy for an extended period to come.
Paschal asks What about other .NET languages? I have my own thoughts on C# and VB.NET. But to extend his question, I would ask is having them a good thing in the first place?
Scenario:
Suppose a company, perhaps a government department or a government contractor has a staff of COBOL developers supporting the mainframe (I know of some that still do), but the *young* blood has a .NET initiative (they have seen the light) that needs to be manned with no funding available for outside consultants, new employees, etc.
By using COBOL.NET for a piece of the application, you can leverage the talents of the more *seasoned* developers and lessen the learning curve.
Yes there is still OOP to consider and you cannot just say “well I know COBOL so I should automatically be productive in COBOL.NET and therefore the .NET platform.” This is not the case when transitioning from VB to VB.NET, and it’s not the case when transitioning to .NET through other languages either.
Making the transition to the .NET platform via C# was easier for me than VB.NET. I had to change my approach to the way I write code. You cannot just map old language habits to .NET. This assumption is partly the cause for .NET getting a bad name. Low quality consultants are being marketed as .NET experts after only three months of experience; I saw this happening firsthand. When the application does not perform to expectations because of poorly written code, .NET gets the blame (a blog for another time).
There are a lot of *antique* developers out there that think .NET is just a new syntax for their favorite language. Switching to .NET is a paradigm shift. It’s a new way of developing. Some say Java has had this type of framework for years, and .NET cannot hold a candle to J2EE. I'll let the Petstore benchmark fight that fight.
The above company can now begin to focus on an organization wide framework to build upon. This framework can be utilized by all the departments, unifying the company infrastructure. This will allow the *antiques*, the *young* blood, and everyone in between to get on board with a unified development environment. This would increase code reuse between departments which is normally difficult to accomplish, and it would decrease development time of future initiatives regardless of the language used. Its all about the runtime.
So having these other languages under the .NET umbrella is a good thing.
This may be a maintenance nightmare later on, but for the above scenario, it is acceptable.