Friday, February 04, 2005

Why BMCS and Why not MBAS ?

Earlier I had blogged about my intention to focus my spare time on contributing to bmcs. Therein I had declared my intention to make bmcs as "The future defacto Open Source VB.NET compiler".

An interested VB.NET user has raised the following questions - "This will delay a lot the VB.NET compiler development. All mbas compiler work will be discarded?"

The concerns of this VB.NET user is very valid but is totally unfounded. This is because folks from Novell - Manjula, Satya Sudha with additional help from Sudarshan and Ritvik Mayank - are continuing their work on mbas and making it better day by day. So mbas is not only thriving, it is all the more likely to see the light of the day much sooner than bmcs.

Some people might be tempted to think of bmcs as being positioned in direct competition with mbas. Let me clarify that it's actually the other way round. bmcs will coexist with mbas and try to leverage as much work done on mbas as possible. The birth of bmcs needs to be viewed as one creating a better, more futuristic and robust choice of for the Open Source VB.NET developers.

Let me explain why bmcs is "better", "robust", "scalable" and "futuristic".

bmcs is grown from a more mature C# compiler code base that has already seen the light of the day. If one carefully happens to look at the history of mbas, one would realize that it was also cultured out from the mcs code base - but one that's more than 2 years old. So the code emission modules in bmcs is that much more thoroughly tested and feature rich as compared to the one available in mbas.

bmcs is "futuristic". This is because bmcs is grown out of gmcs - Mono's next generation compiler supporting Generics and Partial Classes in C#. Hence bmcs can start supporting these features almost out of the box in no time.

To appreciate why bmcs is more "scalable", one need to carefully consider how mbas is going to mature. As someone, who had spent significant time working on mbas, I see development on mbas proceeding on the following two levels - neither of which is non trivial.

  1. Purging of C# language semantics with VB.NET language semantics
  2. Making the code generation and emission modules more robust and scalable

The task (1) above is something that needs to be done from scratch for both mbas and bmcs.

The only sensible alternative to task (2) would be to borrow liberally from the existing mcs or gmcs code base. That's easier said than done. This is because the class orgnization in mbas is very old and the class structure of mcs has evolved in to a totaly different beast since the fork. The differentiation has been rendered more pronounced by the aggressiveness with which mcs had grown in the intervening two years.

So bringing in new features like generics and partial classes means a significant refactoring and the attendant testing on mbas code base. Any sensible developer could see the enormity of this task.

It's in relation to task (2) that bmcs is going significantly outwit and outlive mbas . It can not only leverage the work that is being done on mbas but can also leverage the work done on the generics C# compiler. A periodic merging of patches is all that's required to make the later task possible.

Personally I am very upbeat about bmcs. The mood is as well shared by Rafael Texeira - the brain behind the Mono's VB.NET compiler


At 4:33 pm, Anonymous Anonymous said...

Thank you!
[url=]My homepage[/url] | [url=]Cool site[/url]

At 4:33 pm, Anonymous Anonymous said...

Good design!
My homepage | Please visit

At 4:33 pm, Anonymous Anonymous said...

Good design! |


Post a Comment

<< Home