My problem with .NET is exactly the same as MFC or the Delphi OWL - that you are just using boilerplates. You are not really programming, you are just learning how to use specific pre-made chunks of code. In a professional setting that is supposed to make sense as you can rapidly throw together an application. However that application is bloated beyond all decency and plods along like a pregnant Hippo... I am a hobbyist. I take pride not in producing a final product but in doing things the 'right way', or the most optimal way or a way that uses some cleverness in the fundamental architecture of C++. If your going to use MFC or .NET and CLI then in my onion you might as well just use C#, or go the whole 9 yards and flop it out in visual basic!
Additionally it is all heading towards 100% 'managed code'. With the combination of the 'trusted computing' platform in modern EFI BIOS's and the CLI infrastructure we are just one step away from having to beg our corporate masters for the right to run our own programs on our own machines. Way back in 1999 people were starting to talk about getting licences to allow programmes to run - and hobbyists being granted the amazing privilege of a 'free' licence so long as they did not want to sell their code. This is on top of paying through the arse for the development environments themselves. Back then the idea was universally condemned. Now nearly 20 years later no one seems to care. THIS has already happened if you want to write device drivers. Your driver code has to be approved of by Microsoft and signed before it will run - unless you want to boot to some jury-rigged bullshit 'compatibility mode' every time you start up windows.
I really don't care about MS specifically. I am against corporate parochialism in any form, whether the shiny woo of Apple or the jack-boot thuggery of SCO. Even the supposed shining castle on the hill of Linux is not without its petty childishnesses.
That is why I have become so enamoured of perl. It takes all the supposed goodness from RAD, but makes it REAL without simultaneously stabbing you in the kidneys while you go to shake its hand. And best of all it is free like William Wallace AND Beer.
"Aure Entuluva!" - Hurin Thalion at the Nirnaeth Arnoediad.
| [reply] |
Just using boilerplates? You'd better go back to assembler then! Perl and it's plethora of modules are just as boilerplaty and by no means smaller or quicker.
Of course you should go to C# and forget C++ except in case you need to integrate with some old code written in C++.
The end is nigh!
Jenda
Enoch was right!
Enjoy the last years of Rome.
| [reply] |
I agree entirely!
That is exactly why I like perl - CPAN is one colossal warehouse of boilerplates. BUT it is meant to be that way. It has not taken a massively powerful language and handcuffed it and trammelled it down with a ball and chain. Critically it is FREE(Free, free). MS does not own it, MS cannot tell me how to use it. Neither can Cupertino nor the kernel chaps at Linux, not that I think the latter group would want to.
Moreover I do actually AGREE with you about C# as well. IF you are willing to blithely accept all the control and potential abuse of power that .NET/CLI offers and want to programme for strictly the windows platform then yes. You would be stupid NOT to use C#/.NET. It integrates directly a lot of the functionality that you have to spend a long time fashioning for C++. Just the total integration of window-object and WndProc DIRECTLY into the C# class structure is a beautiful thing with a liberating utility akin to perl's dynamic strings.
HOWEVER... I do not believe that MS have our best interests at heart - or at least only when those interests accidentally align with their corporate greed. Under CLI they can flip a switch and every non-licensed, non-certified, non-signed programme on the planet that runs in Windows will stop working. Just look at how their totally proprietary environments are locked down HARD. The 360 and the embarrassment that is the Bone are perfect examples. XNA??? They must have had a good old laugh at THAT position meeting! But they can only do this if we let them. As programmers we are some of the most creative individuals on the planet - just as entitled as artists or musicians to our own ideas and methods. However you don't get Freedy Jonston or Neko Case prevented from playing the songs they want by the manufacturers of their guitar strings!
Perl is beautiful and undemanding without ever once losing its core beliefs, individuality and drive. And suddenly I realize I am starting to think of a programming language in the same ways I do my wife!!! Oh dear...
"Aure Entuluva!" - Hurin Thalion at the Nirnaeth Arnoediad.
| [reply] |
I, for one, never thought that dot-Net had a bad design. I certainly would not call it “worst of all,” except in the good-humored jest that I recently used in reference to Java. The dot-Net framework is a very good design for the “single-vendor centric environment that is Microsoft Windows.” There are millions of deployed copies of just such an environment. Its biggest problem is, admittedly, a conscious design decision: it is made for Windows, for Internet Explorer, and it depends quite heavily upon client-side functionality that is also built-in to Windows (and/or to the “Silverlight®” plug-in which Microsoft provides). Therefore, if you are deploying within a company’s internal network, you can do amazing things ... but the moment you wish to go out, you have a problem.
And where, exactly, do people (within the company ...) “wish to go out?” You guessed it ... mobile devices. Whether they like it or not, Microsoft lost that battle. So, to a lesser extent, did Blackberry. Windows-CE et al is simply not on the radar at all. Microsoft never will own that environment, nor will they own the deployment avenues leading to it. Never. “Game Over.™” What the Executive Vice-President is carrying in his jacket pocket might be an iPhone, but it is just as likely to be an Android-driven device that does essentially the same thing for hundreds of dollars less. Your challenge now happens to be an extremely big one: to bring the functionality of that internal application securely to the EVP’s jacket pocket, and to make it robust and reliable, without access to the dollars needed to re-do the whole thing in a sensible language, such as Perl. ;-)
But we can’t blame that on dot-Net, nor should we count-out Microsoft’s very capable development team (which has produced many miracles in the past). They simply based their system on the assumption that they could control both the server and the client side ... and, in many still-existing cases, they can. It wasn’t a “flawed” design. In many ways, IMHO, it was a brilliant one. (And is the game really “over?” Heh, in this business, “never say ‘never.’”)
| |
| [reply] |