Finally

[SoftwareMaker]

Heard that from MSoft recently, Linux has begun to develop a JIT Complier for the .NET Platform Intermediate Language (IL)

In other words, apps that you write with .NET languages are complied to only IL and they are then read and complied with the JIT Compiler. These JIT Compilers are provided by the Different OS platform vendors. Therefore, you can now write VB.Net, C++, C# apps that can run on Linux. (If Linux kept up to their promise and develop JIT Compiler successfully)

So hopefully , your typical Window Apps can run on Windows, Mac, and Linux. Take that, Java !

I have been studying the .Net recently and I must say its amazing. Actually, the greatest transformation is the maturation of VB into a true OOP Language. That is what most advanced VB developers have been asking for and they got it. Previously. VB has lost out to its other OOP brethren because (altho VB is supposed to have some OOP capabilities) its OOP tools are not very intuitive and it doesnt support real application implementation. You can have interface implementation with the IMPLEMENTS keyword and you can (more or less) have application interface with the DELEGATION and CONTAINMENT methods but its not good enough. Now with .Net, you can actually use the INHERITS keyword and have real true-blue application implementation and you can also have visual implementation which means you can create many many forms (say many Dialog Box forms) by just creating one copy of the Dialog Box Form (Parent Class or Super Class) and have all the other Dialog Box Forms visually inheriting from the Parent Super form class. Thats right...Finallly Forms are Real Classes Now !!

I know a lot of old codes will break and I am just as frustrated as the next developer. I have been developing and written tons of apps since VB5 and all those codes will break, no matter how good the .NET upgrading wizard is. The wizard may be able to move the codes effectively (I doubt efficiently) but it cant change the mindset of VB developers worldwide.

However, I looked at it from a more positive note tho, in the past, VB Developers have always been looked upon as smaller brothers to the C++ counterparts and a joke compared to JAVA. Some even said VB are actually wrappers around C/C++. The main reason being the difference in its OOP capabilities and tools. Now VB has matured and MS is out FULL-TIME to claim back the developement environment (right from the user to the enterprise level) from SUN's JAVA where it has lost out. (MS says it never really push its developement tools before and therefore lost out to SUN...I dunno abt that and who to believe )

I have explored tons of forums like these around and I must say I agree with MS view that altho there are many many VB developers around in the world...only half of them understand and knows how to use its OO tools. The rest of the developers seemed content to write VB apps in the procedural way and let me tell you...OO way of developing provides so much code reuse and maintainablity. Last time before OO, I would kill any body who told me to change my app because of some damned policy changes in the company...NOW, I can roll out new upgrades in half the time and companies are so impressed they pay me more. HEHEHE...I have learnt to use classes instead of modules and understood COM and what its all about.

Yep...altho .NET framework is slightly different from COM. Some say COM is "dead" when .NET is out. I say that the concept and architecture of OOP is still there and thats learning to create and use objects.

For all those VB developers (like me) out there who are always looked down upon and told to GET A LIFE and LEARN A NEW PROGRAMMMING LANGUAGE...I says its time to roll up your sleeves, learn the new VB.NET and kick some OOP ASS !!!

[parksie]

No matter how good VB.NET is, it'll never match C++, even with the managed extensions. Because you can mix managed and unmanaged code, you can spot-optimise your routines, which are fully-compiled for the target system. Sure, it's a little bigger, but runs a lot faster than IL in some cases.

Although I like the way that they do a "compile" of the IL into native before it runs rather than on the fly, or even a JIT approach.

[SoftwareMaker]

Yes,

Parksie, you're right...I never would believe that VB and C++ would ever be on par. C++ has that tremendous ability to utilize unmanaged code even in C++7.NET, even VB.NET cant do that.

What I meant and think is that VB has made significant changes and improvements that made it comparable to its OOP peers is the significant upgrade in its OOP tools and its capabilities. Tools and capabilities that were absent in previous versions of VB that made creating enterprise-level VB apps very difficult and a nightmare to maintain. Now with the new and better OOP tools and capabilities, creating enterprise-level apps in VB is more possible and feasible.

[parksie]

True. I agree with you on that one

.NET finally consolidates COM into something useful. This is where VB programmers had it easy - COM is a doddle in VB, but you don't have anything like the OOP features. C++ has the OOP, but COM sucks when you use it with C++

Now, Microsoft's dream of multiple languages working seamlessly is starting to appear, and for once, I agree with them.

[SoftwareMaker]

Hi Mr Parksie,

A caveat tho...COM's architecture is "DEAD" in .NET !!! because of the .Net's Garbage Collection features...COM's reference Counting methods and functions of AddRef and Release is GONE...which means the Death of deterministic finalization. Urrgh...

According to Msoft, you can still port your COM Objects to .Net but they will have to be accessed through a WRAPPER...and that word WRAPPER means a Performance Hit

I have no idea what kind of performance compromise we are dealing with here. But from what I know (correct me if I am wrong) .Net platform 's recommended memory usage is a MINIMUM 128 MB which means 256MB or 512MB for normal to enterprise usage. If an app runs on 512 MB, I doubt we'll see too much performance degradation. Another Hardware-Software conspiracy ???

[parksie]

Hmm...performance hit...is that like a bong hit?

.NET still requires COM+ installed (when it's in there, look at the Internet Explorer client tag (the bit with Mozilla 5.0/Compatible and whatnot).

Not sure what the advantages of COM+ are, but I'm sure they're well hidden. Which is what I like - no more messing around. You just say what you want it to expose, and it handles it for you. None of this messing around querying interfaces (ouch).

I only played around with .NET long enough to love WinForms, because I messed something else up and then couldn't be bothered to reinstall it again When beta 2 arrives I expect I will. So if COM is required, how can it be "dead"?

(it being 5am probably doesn't help my thought processes, but oh well )

[SoftwareMaker]

Hi Parksie,

Well...maybe not DEAD "DEAD" but some of its architecture and its interface will change and that is to suit the new Garbage Collection of .NET.

Because, everything downright to string and interger data types is an object in VB.NET, MS claims that COM's way of disposing so many small objects requires too much overhead and is inefficient. Therefore COM's architecture has to change to accomodate Garbage Collection (which evidently uses its own algorithms to dispose of objects and free up memory) to replace COM's native deterministic finalization's way of freeing up objects.

In other words, objects not used by your app is not freed right away but as and when the garbage collector frees it. How good is that ? I dunno but garbage collection in software has been around since the 1950s. With 50 years of software evolution, I think it must and should be efficient enough to deal with the software problems of today.

Maybe COM is not "DEAD" but the COM as we developers, know it will change with .NET.

It was nice talking and discussing .NET with you. You should get some sleep

[parksie]

Oh well...so much for the whole "sleep" idea...whoops

Okay I see your point on the whole GC thing now