Mood:
specialNow Playing: 'Mickey Finnish' A dame's night out on the town gets cut short when somebody spikes her punch. (Comedy/Thriller)
Topic: Microsoft and VCSY
When the rabbles begin rabbling, old Rasta is gonna set the burning tire blockage to light. We'll smoke the bastids out dammit.
rastamafoo's Comments on Slashdot
In particular, this comment heya. RESPECT MY AUTHORITIE!!!
For the casual reader, consider what Microsoft was doing circa 2001 in pursuit of some sort of .Net Framework (of which they've only recently arrived at in 2007...??? where has their XML capability been before now? Hmmm? Buried in client systems no doubt. ooooo I wonder what those clients will say to Microsoft now that they may receive a cease and desist order similar to what Microsoft received February 2007 [the 6 year anniversary of VCSY introducing the XML Enabler Agent).
Do you think Mister Softy's clients will be able to excise the offending stuff out of their systems? I don't.
http://www.perfectxml.com/articles/xml/dotnet.asp [perfectxml.com]
Excerpts from end of article. More at URL.
# .NET in the short term
The final versions of the full set of .NET components (whether this concerns the development tools, or products from the .NET server family) are unlikely to be available before mid -2001, going by the most optimistic predictions.
"Old" applications built on the Microsoft DNA architecture will still function on Windows 2000 servers equipped with .NET generation tools. The two generations of applications will be able to cohabit without interference.
We therefore do not see any short-term threat for current and future DNA-based applications.
Microsoft points out that tools and assistants to help with migration will be provided with the .NET platform. However, we do not feel that this is an ideal solution, for various reasons. Firstly, migration assistants can never carry out 100% of the modifications necessary. Consequently, it would be advisable to devote sufficient time and resources to this migration. Secondly,transforming an ASP/VBScript application into ASP.NET/VB.NET will not automatically make it a.NET application. It will in all likelihood be necessary to alter the application architecture, so as to benefit fully from the new possibilities offered by .NET.
In future articles we will try to answer some of the questions that you are undoubtedly asking yourself if you have Microsoft DNA applications in production. We will try and draw an accurate schema of the optimum .NET architecture, and will show you the best way to write DNA applications which can be ported to .NET.
# .NET in the long term
Whether or not Microsoft achieves what it has set out to achieve with .NET, it cannot be denied that the way we design applications is going to undergo some changes. With the advent of e-commerce and B2B exchanges, there is already a need for interconnected applications which communicate via an enterprise network or through the Internet.
With this in mind, we can see that with .NET, Microsoft's main aim is to supply tools which can be used to develop applications as easily as Visual Basic did a few years ago, during the golden age of the client-server application.
# What's the verdict?
Pragmatically speaking, and casting aside any preconceived ideas about the Redmond vendor, a clever strategy would be to carry out sustained technology tracking of .NET and as its alternatives, together with the technologies on which all of these are based, i.e. XML and SOAP.
Until the final version of .NET appears, we will continue to keep you informed of technological and strategic developments, with further TrendMarkers articles on Microsoft's DotNet. Stay tuned!
And, in conjunction with the above masterfully stated opinings, I do dearly love little blurbs like this (Thanks to POS at the PH for finding this minor linken gershlobben.):
Applications are portable (as long as they are Microsoft applications... and Microsoft OS no doubt)
Applications compiled as intermediate code are presented as Portable Executables (PEs). Microsoft will thereby be able to offer full or partial implementations of the .NET platform over a vast range of hardware and software architectures: Intel PCs with Windows 9x, Windows NT4, Windows 2000 or future 64 bit Windows versions, microcontroller-based PDAs with PocketPC (e.g. Windows CE), and other operating systems too, no doubt. (yea. no doubt.)
All languages must comply with a common agreement (the agreement being there be absolutely no arbitrary code in the system. hmmm... I guess dotNet isn't quite as advanced as SiteFlash which is able to run on any operating system with any code and any language. What is this dotNet junk anyway? A woodent decoy duck?)
Computer languages are numerous. Traditionally, new languages have been created to respond to new needs, such as resolving scientific problems, making calculations for research, or meeting strong needs in terms of application reliability and security. The result is that existing languages are heterogeneous: some are procedural, others object-oriented, some authorize use of optional parameters or a variable number of parameters, some authorize operator overload, others do not, and so it goes on.
For a language to be eligible for the range of languages supported by the .NET platform (PING - SiteFlash architecture allows the use of ANY language), it must provide a set of possibilities and constructions listed in an agreement called the Common Language Specification, or CLS. To add a language to .NET, all that is required in theory is for it to meet the requirements of the CLS, and for someone to develop a compiler from this language into MSIL. (Why? Because dotNet at the core does not run on a web based virtual engine beyond Java. It therefore can not do what SiteFlash or any of the other VCSY technologies do easily. VCSY even uses dotNet to do things even dotNet has not been able to accomplish. Am I baiting all you expurts out there? Of course I am! How else can we drag you limp-linguinied bs-shooters out of the bushes into the skreet? And we can hear your spurs jingle jangling as you try to sneak away so you might as well turn around and face the music. I'll call the dance, ok?)
This seems fairly innocuous at first glance, but the restrictions imposed by CLS-compliance on the different .NET languages mean that, for example, Visual Basic .NET ends up becoming a new language which retains little more than the syntax of Visual Basic 6. (Did you get that all you people pretending to be in the arbitrary coding business?)
The fact that all the .NET languages are compiled in the form of an intermediate code also means that a class written in a language may be derived in another language, and it is possible to instantiate in one language an object of a class written in another language. (Wow)
Today, if you want to create a COM+ object, you generally have the choice between VB6 and Visual C++. But VB6 does not give access to all possibilities, and for certain requirements, you are restricted to VC++. With .NET, all languages will offer the same possibilities and generally offer the same performance levels, which means you can choose between VB.NET and C# depending on your programming habits and preferences, and are no longer restricted by implementation constraints. (Wowie wow wow)
At this point, you may be wondering how this can all be possible. Magic? Not really. In our opinion, there is no magic wand being waved here. To give a more even view of the multi-language aspect of .NET, we would prefer to say that .NET only supports one language, MSIL. Although Microsoft does let you choose whether to write this MSIL code using Visual Basic syntax, or C++ syntax, or Eiffel… (OH YEAH EIFFEL... Hey treeforters... remember the orange and white eiffel tower in the IBM commercial? heh heh heh)
To put it frankly, in order to be able to provide the same services from languages as remote as Cobol or C#, you have to make sure these languages have a common denominator which complies with the demands of .NET. This means that the .NET version of Cobol has had to receive so many new concepts and additions that it has practically nothing left in common with the original Cobol. This applies just as much to the other languages offered in .NET, such as C++, VB, Perl or Smalltalk. (And you business IT guys are dedicating the future guts of your systems to THIS sort of wordplay? Oh yeah we can do that... mumble mumble mumble moo)
So what we need to understand is that when Microsoft announces the availability of 27 languages, we should interpret that as meaning there are 27 different syntaxes. (Damn. So we have to learn all that to work with dotNet? That's some learning curve boss.)
The most symptomatic example concerns Java. It is one of the intended .NET languages, thanks to Rational, who are currently working on a Java to MSIL compiler. But what kind of Java are we talking about? It is a Java which runs as MSIL code, not byte-code. This Java does not benefit from the traditional APIs offered by the J2EE platform, such as JMS, RMI, JDBC, JSP. This is a Java in which EJBs are replaced by .NET's distributed object model. The label says Java, the syntax says Java… but Java it ain't! (and 'arbitrary' it all ain't)
Of course, the case of Java is a bit of an exception. Indeed, Java specialists see .NET overall as a rather pale copy of Java itself, and consider it to be proof of Microsoft's successive attempts to undermine Java's future. Relations between Sun and Microsoft have been peppered with disputes and lawsuits in recent years. It was out of the question that Microsoft would participate in the construction of Java by offering total support for the language in its new .NET platform. (Oh my goodness Sun... I had forgotten about Sun since Tim Bray called SOA 'vendor bull***' back when they were working with Microsoft on SOA and services. I wonder where Sun is working with SOA/SaaS now?)
From our perspective, the support for Java in .NET is, as it stands, totally unusable if one intends to maintain a degree of compatibility with Sun's J2EE platform. (Whose perspective?) We believe that its only justification is that it reinforces Microsoft's campaign to seduce developers. Microsoft's strategy is to win over developers in order to benefit from their prescriptive powers, with the aim of eventually imposing .NET on a wide scale. (Wasn't that Bill's plan from the beginningk? Vas ist loss? Der schpiegelshprechen vas inmittzvissing der sprockenvarren unt der larrygehaben? Acht meinen fartzenchaffen!)
Similarly, Microsoft is cleverly entertaining certain rumors, such as the recurring whispers predicting the eventual availability of .NET on Unix systems, even Linux. Linux is increasingly popular among developers, and is becoming a potential alternative to Windows NT as far as server architectures are concerned. By keeping details hazy around the issue of Linux support for .NET, Microsoft can win over fans of the free operating system. (Or you can always pay them to let you play.)
I gotta say you Microsoft people are about as soft-spined and amoral as an urchin. It it weren't for all your big spikes you would be a fleshy mussel nestled in some cocktail sauce. As it is, you're going to get baked out in the hot Sun glare while the seagulls peck you to doom and gloom. Damn what a turrble way to go... spittoee
Sounds like a run on somebody else's bank.
(Score:1)