 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / July 2007.NET is much worse than VCL
I have been used .NET for few years. Before that I used Delphi (VCL) for many years. My conclusing is that .NET is much worse than VCL. Here are the reasons: 1) VCL comes with full source code. .NET has none. Even if the documetation is good nothing beat source code that you can use to check how framework really works 2) No possibility to include 3rd party libraries inside the EXE. Delphi can put eveything inside one EXE. No need to deploy and maintain several DLLs. 3) .NET needs huge and exactly right runtime enviroment. VCL produces plain and simple WIN32 EXEs 4) Localization support for .NET is a joke. .resx format is very bad. It does not contains complete imformation about the form (e.g hierarcy). VCL DFM contains eveything your need. In .NEt you have to actually disassebly .EXE or analyze source code to dig out all the information needed for proper localization. Also this Localizable property is bad. You have to turn it on every for single form. In VCL eveything is localizable by default. Also satellite assembly must be in a separate sub directory. 5) 3rd party controls are hard to install manually and really huge compared to VCL's counterparts. There is some many things .NET that is fundamentally flaw. I am unhappy to the fact this this is the enviroment we have to cope for the next 10-15 years. Best regards, Jaakko One thing I forgot: How could a great guy, Anders Hejlsberg, that developed Delphi do so bad work with .NET framework. Delphi's .DFM format is great. Why the hell MS did not use something similarrt but used to this .resx format. > I have been used .NET for few years. Before that I used Delphi (VCL) for > many years. My conclusing is that .NET is much worse than VCL. Here are > the reasons: Why are you posting them here? Isn't there a VCL newsgroup where you could post, where you wouldn't wind up looking like a jerk for trolling the people who on a daily basis use and enjoy the thing you are bitching about? As far as your specific conclusions go, I like the way you ordered them, because you left the most important, easiest one for last. Let's look at them all... > 1) VCL comes with full source code. .NET has none. Even if the > documetation > is good nothing beat source code that you can use to check how framework > really works I agree that's it's nice to have source code. But there are lots of examples of places where you don't have the source code, and people get by. The biggest one being the operating system API. This is not only for Windows, but for a variety of other operating systems as well. Yet, people still manage to successfully write excellent applications for those platforms. Beyond that, I think it's unreasonable to expect Microsoft to release the source code for .NET. It's not an open source project and they have a vested interest in making sure that .NET remains primarily a Windows thing. Release the source code would make it a lot easier for projects like Mono to exist, and would undermine Microsoft's intellectual property ownership benefits they enjoy today. > 2) No possibility to include 3rd party libraries inside the EXE. Delphi > can > put eveything inside one EXE. No need to deploy and maintain several > DLLs. I don't know what you mean here. I compile multiple projects into a single .exe on a semi-regular basis. I can deploy a DLL if I want to, but there doesn't seem to be a problem creating a project that simply links statically into my .exe. If the third-party libraries aren't provided to you as non-DLL libraries, then that would prevent you from doing what you want. But that's an issue you have with the third-party developer, not .NET. Complain about them, not .NET. > 3) .NET needs huge and exactly right runtime enviroment. VCL produces > plain > and simple WIN32 EXEs I guess ~20MB is still "huge"? I do remember the days when a 1MB application was considered _enormous_. But these days? 20MB really isn't all that big, and the simpler applications I ship are tens or hundreds of _kilobytes_ in size. IMHO, it's an advantage to have a single 20MB install that multiple applications can use, allowing each of those to be very small. Perhaps you prefer having multiple megabyte-sized applications installed on your computer. I don't. By the way, very few .NET applications require a specific version of the .NET runtime. Some do take advantage of features in more recent versions, but that's no different than an application only running on XP and not Win9x. For those few .NET applications that are tied to a specific version of the runtime, that's the application's fault, not the runtime's. > 4) Localization support for .NET is a joke. .resx format is very bad. It > does not contains complete imformation about the form (e.g hierarcy). VCL [quoted text clipped - 5 lines] > every for single form. In VCL eveything is localizable by default. Also > satellite assembly must be in a separate sub directory. Again, this sounds like you simply don't know the tools. I've seen a number of people comment on how .NET enables localization for them in a relatively easy way. If you are having trouble, it's probably because you are not taking advantage of the features .NET offers. For sure, if you are complaining about the file format, that strongly suggests you're going about things the wrong way. Why should you have to touch the internals of the file format at all? There are tools available for localization that handle that for you. > 5) 3rd party controls are hard to install manually and really huge > compared > to VCL's counterparts. Again, you need to complain to the third-party developers then. I have written a number of custom controls for my own use, and they are not hard to install, nor are they "huge" in any possible interpretation. In fact, they enjoy the same efficiency of size that my .NET applications themselves enjoy. > There is some many things .NET that is fundamentally flaw. I am unhappy > to > the fact this this is the enviroment we have to cope for the next 10-15 > years. And here is the "easy" comment to which I referred (not like your others were all that hard to refute, but still)... If you are forced to "cope with" .NET, then I guess that means that Delphi/VCL is no longer a viable development platform. Why in the world would you want to commit yourself to a development platform with no future of support? Why post a diatribe about some other development platform, extolling the supposed virtues of another, when that other one has apparently been abandoned, leaving you to "swing in the breeze", so to speak. Conversely, you yourself admit that .NET is likely to be around for another 10-15 years, which in the computer industry is a _remarkable_ degree of longevity. There are operating system APIs that don't last that long (see Mac OS). Longevity is one of the most important aspects to a development platform. You don't want to commit your development resources to something, only to find that in a few years you have to pull up your stakes and start all over. So, by your own assertion, .NET has one of the most important attribtues of a development platform in its favor: guaranteed long-term viability. Pete > > 1) VCL comes with full source code. .NET has none. Even if the > > documetation [quoted text clipped - 14 lines] > like Mono to exist, and would undermine Microsoft's intellectual property > ownership benefits they enjoy today. On this one (and only this one), I have to disagree with you Peter. Sun has shown that having the source code for the platform (Java) available doesn't undermine the platform at all - instead, it allows a better developer experience (particularly with respect to debugging), allows developers to submit bug fixes, and encourages collaboration. MS is under no real threat from Mono - but Java is still a very popular platform, and Sun recently open sourcing it (the source for the libraries has been available for ages, but now it's all going GPL) is likely to *extend* its appeal rather than limiting it. I can only hope that one day the .NET libraries will be available...  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too > [...] Release the source code would make it a lot easier for projects >> like Mono to exist, and would undermine Microsoft's intellectual [quoted text clipped - 6 lines] > developer experience (particularly with respect to debugging), allows > developers to submit bug fixes, and encourages collaboration. You probably don't disagree as much as you think you do. :) My use of the word "undermine" refers only to Microsoft's perception of their ownership of the platform. I did not intend it to mean that the platform itself would suffer. Only that Microsoft takes their ownership of it seriously, and is no more likely to release the source code for .NET than they would for Windows. IMHO, it is always better for the developer to have access to the source code. Because of this, I think that having the source code available is in fact likely to be more conducive to the adoption and robustness of the platform. However, that's just not how the Microsoft business model is configured. Keeping in mind, of course, that there is no single "Microsoft". There are lots of different fiefdoms there, all with conflicting goals. I would not be surprised if many of those who actually produced .NET would love to see the source code available, but there are others (with more power, generally) who want to restrict access to Microsoft IP as much as possible. So, when I write "Microsoft" what I really mean is "those individuals at Microsoft who impose the restrictions under which we who use Microsoft products operate". It's just too long to write the latter on a regular basis. :) Pete > You probably don't disagree as much as you think you do. :) Certainly sounds like it :) SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too From a technical standpoint, they are already, as you can use tools to reverse engineer them. There are some exceptions, of course, in the underlying engine, which might be what you guys are talking about. SignatureGregory A. Beamer MVP; MCP: +I, SE, SD, DBA http://gregorybeamer.spaces.live.com Co-author: Microsoft Expression Web Bible (upcoming) ************************************************ Think outside the box! ************************************************ >> > 1) VCL comes with full source code. .NET has none. Even if the >> > documetation [quoted text clipped - 30 lines] > > I can only hope that one day the .NET libraries will be available... Hi Peter, I don't want to start any war here but only wanted to point out the problems in .NET programming. >> 4) Localization support for .NET is a joke. .resx format is very bad. It >> does not contains complete imformation about the form (e.g hierarcy). VCL [quoted text clipped - 15 lines] > touch the internals of the file format at all? There are tools available > for localization that handle that for you. I know the tools and I know the formats. The problem with .NET is that it does not store all the properties to .resx. Still most of the data is left to source code such as: - most color properties - menu hieararcy - parent properties of most container controls The resource format like .resx should contains all the infromation needed to be able to localize the format properly. For sure you can translate .resx file either manually or using any localization tool but the problem is that without the source code or discompiling the assembly the localization tools can not fully show forms visually. In order to do that they have to a lot of extra work that was not needed with .RC or .DFM files. WPF has a better resource format (.xaml) but it also has problems. There is no type data on the XAML file. You have to look for the component type and property name in order to figure out the type of the property (e.g. interger, string, etc) Both RC and DFM has type data included to the resource format. Overall the resource format of .NET is not good. It is almost as rudimentary as Java's .properties. Centainly much less sophisticated as VCL's DFM. .XAML is a step to a better direction but it is not even closely as good as 15 years of .DFM! Best regard, Jaakko In general, I prefer to customize the providers and then reuse my custom implementation. I find that I fall out of the 80 too often and become an exceptional case. With custom providers, I can avoid being burned. SignatureGregory A. Beamer MVP; MCP: +I, SE, SD, DBA http://gregorybeamer.spaces.live.com Co-author: Microsoft Expression Web Bible (upcoming) ************************************************ Think outside the box! ************************************************ > Hi Peter, > [quoted text clipped - 54 lines] > Best regard, > Jaakko >I have been used .NET for few years. Before that I used Delphi (VCL) for >many years. My conclusing is that .NET is much worse than VCL. Here are the [quoted text clipped - 3 lines] > documetation is good nothing beat source code that you can use to check > how framework really works If you need source code to figure out how things work, you can reverse engineer it using tools like Reflector. .NET code is byte code. This means, unless obfuscated (etc.), it is an open book. > 2) No possibility to include 3rd party libraries inside the EXE. Delphi > can put eveything inside one EXE. No need to deploy and maintain several > DLLs. Monlithic applications are things that most people have shied away from. With the interactivity of bits, you are more prone to errors if you embed everything. In addition, you cannot update one piece of the software when everything is in the EXE without updating the entire EXE. While you might be more familiar with this methodology, I am not sure it is something most people would want, as it reduces maintainability and extensibility. If you absolutely need to deploy several DLLs as one big monolithic chunk, you can do it with the al.exe tool. > 3) .NET needs huge and exactly right runtime enviroment. VCL produces > plain and simple WIN32 EXEs So, you like the runtime embedded in the OS instead of on top? The COM Framework is much larger than .NET, but it is hidden from you. As time goes by (say with an operating system named something like Vista) the Framework will be included in the OS, so it will be hidden from you, as well. But, both runtimes are still large and still there. > 4) Localization support for .NET is a joke. .resx format is very bad. It > does not contains complete imformation about the form (e.g hierarcy). VCL [quoted text clipped - 3 lines] > turn it on every for single form. In VCL eveything is localizable by > default. Also satellite assembly must be in a separate sub directory. resource files are one way to localize, and you can compile them into libraries, if you want to reuse them. You can also easily extend with custom resource providers. > 5) 3rd party controls are hard to install manually and really huge > compared to VCL's counterparts. This might be true for some, but I have never had an issue with any third party control I have used. > There is some many things .NET that is fundamentally flaw. I am unhappy to > the fact this this is the enviroment we have to cope for the next 10-15 > years. I think you just have not made the paradigm shift in thinking yet. Most of what you state here are, from my experience with a variety of languages, detriments for VCL rather than strong points. In many ways, it is like listening to the ASP programmers when .NET first came out. Most of them have now assimilated and find .NET a much better environment. Please note, I am not saying all of the features you desire are wrong, as they are not. I just do not see them as features that should be used for every application. IN fact, I see they are specialty cases, when it comes to a disconnected world. SignatureGregory A. Beamer MVP; MCP: +I, SE, SD, DBA http://gregorybeamer.spaces.live.com Co-author: Microsoft Expression Web Bible (upcoming) ************************************************ Think outside the box! ************************************************ >> 3) .NET needs huge and exactly right runtime enviroment. VCL produces >> plain and simple WIN32 EXEs [quoted text clipped - 4 lines] > Framework will be included in the OS, so it will be hidden from you, as > well. But, both runtimes are still large and still there. On this one, I've got to agree with the original poster. Native code is much preferred over non-native for desktop applications. No versions of XP come with the .Net framework 2.0. This means I'm stuck getting it deployed if I want users to run my apps. Vista comes with .Net 3.0, which is great for the 3 people who use Vista. But based on past expereince, this time next year, I'm going to be using .Net 3.5. ... 1 year down the road, Microsoft is NOT going to push .Net 3.5 out to Vista machines. This means I'm going to be in the same boat next year, as I'm in this year. ... and 3 years down the road, I'll be coding in .Net 5.5, and Vista won't have it, but I'll be hearing promises the "Windows Stellar, due out any day now, will ship with the latest version of the Framework.". SignatureChris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP http://www.coversant.com/blogs/cmullins Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.