.NET only solves problems I don't have! (Was: advocacy help ( Python vs VB ))

[Max M]

Alex Martelli wrote:

> Ah, but WHAT VB are we "selling" against?  Microsoft is in the process
> of changing VB *incompatibly* -- you would need to study it again and
> rewrite just about all of your code to migrate to old VB6, which MS does
> not like any more, to new VB.NET, which means betting your company
> on MS's unproven, fascinating but risky .NET strategy.

What I find most amusing about com and .NET is that they are trying to 
solve a problem I only had when programming using MS tools.

Ie. when I coded webpages in JScript and wanted to upload a file I had 
to buy a component for it (Or write it in JSCript from scratch :-( )

If i wanted to send mail I had to buy a component for it.

Etc. etc.

And most of the modules I bought had bugs in them. Ie. they would work 
under one version of Microsoft Scripting Host (MSH) in both VBScript and 
JSCript but in another version of MSH the module would only work under 
VBScript ... So depending of you servicepack your components might stop 
working in your language of choice.

Under Python I have several excellent modules for what I want to do. If 
I need something there is usually almost a library available for it. Or 
it is easy to make my own library using other Python libraries.

And the available libraries have ALLWAYS been better than the commercial 
cr^H^H stuff I have spend my cash on in MS land.

To take an example: If i had to write something like the file-upload 
modules for IIS in JScript I would be in trouble because I would have to 
write my own MIME parser and other stuff in JSCript.
In Python I can use the MIME library to parse the multipart data and get 
it done relatively painlessly.

So often it is easier to roll your own in Python than to find the right 
COM-component, reading the docs, checking it out, write code for it, 
only to find it lacking.

I believe that the main driving force behind .NET is to make it easier 
for people to develop and sell closed source components. And I am ok 
with that. I write software for money too. But as a developer using open 
surce tools I have NO need for it at all.

All they have is a great solution to a non-issue.

So MS is developing this massive strategy and technological toolset to 
solve a problem that could be solved simply by switching to Python ;-)

As any programmer worth his salt knows, you can have too many layers of 
abstractions in your code. And I don't think that this common runtime 
solves any significant problems.

  - I can develop in any language I please
  - well I allready do

  - I can share objects written in othes languages
  - Well I allready do

  - Compiled code written in your language can run unchanged on .NET
  - Well it allready runs on most any platform. Including Windows.

I believe that mixing languages at several meta levels makes great 
sense. So a combination of Scripting, c and even assembly, as C. Tismer 
has shown in stackless, is a great toolbox. But for me to change to 
another scripting language it would have to be an order of magnitude 
better than Python. Or else it is not worth the time and energy.

So why should I care that I can write components in C#, J.NET, 
VBScript.NET, JSCript.NET etc. ?? I will bet that any language running 
under the common runtime will not be an order of a magnitude better than 
Python.NET, as those languages will have too much in common by design.

I am shure developers using other languages will think the same. Oh yeah 
should I choose to develop in Python.NET and use a class written in C# 
what do I do when it's buggy.? Will I have to learn every language under 
.NET to be shure I can debug other peoples poor classes? Using other 
peoples classes is only fun if they are good and open source. An 
preferably in a language you know. Otherwise they might as well be closed.

Beside, using classes made for all languages will allmost certainly 
lower the expressive level of my favourite language.

MS are trying to take a massive detour around problems they have created 
for themself with their closed approach.

A few good languages at different hardware abstraction levels and good 
open libraries I can read and debug is what I need.

Oh wait. I allready have that.

regards Max M