|
Microsoft's propaganda machine has been trying to portray .NET as being
a built-from-ground-up technology. But the fact of the matter is this is
simply a repackaging (with some sugar coating) of the their obsolete Windows
Foundation Class (WFC) library (the Java class library for Windows).
The big giant has yet to learn how to tell the truth.
|
|
|
|
|
I say there is a lot of new stuff that is in dot net.
Microsoft obviously doesn't want to say that its roots, at least in some respect, come from Java - to me this was like asking Ex-President Clinton "Did you have sexual relations with Ms. Lowinski" (or however you spell her name). I mean you already know the answer, but for it to be uttered aloud is a mere formality. Did it make Clinton a bad president? Well no, I don't think so. Does MS not mentioning its bedfellows of dot net make it bad? No, I don't think so.
Who cares where it came from (do you remember the guy who first got fire going? do you remember who invented the wheel?), its to evaluate if it works, and works well. And that's where our time should be spent.
Have fun,
Paul Westcott.
|
|
|
|
|
I disagree - you're right that M$ is repackaging stuff they couldn't sell/ couldn't get away with previously, but I don't think they have failed to add to what they did before, even if they DO lie on it's origins.
I don't think it's a desire to lie, it's simply marketing. Anyone who thinks .Net is not being marketed to us is fooling themselves, and that can only mean it needs to be pushed to succeed. Like Java, it may well be a solution looking for a problem ( to steal a Bjarne quote ).
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
So many of you seem to be complaining about having to learn something new ... why the hell did you get into the high tech field then? Did you not know that the only constant is change?
Note: This does not necessarily include the people who voted "Definitely not", just the ones complaining without a valid argument.
Isn't it the challenge of learning and mastering a new technology what drives most developers? Being on the bleeding edge? Let me know if I am wrong.
On another note ... some people believe that MS is shoving this .NET stuff down our throats, not. The change that you are seeing is Microsoft keeping up with the demands of Fortune 500 companies, and .NET is a large jump in that direction.
Hey, if you want to keep programming in C++, MFC, ATL then do that. There will still be quite a bit of work in that field for years to come. I am sure that I will be using C++ all the time along with C#.
I believe that one should use the right tool for the job, not the other way around ( "Ok, I have the screw driver, what do you want me to do?" - "Please hammer in some boards!" ).
|
|
|
|
|
I agree with a lot of this ( surprised ? ). I agree we should use the right tool for the job, but I don't agree that M$ is following the F500 - I believe they are trying harder and harder to kill platform independant code and languages we can use to write it. There is a ton of stuff for which C#/managed C++/VB.Net will make things easier, once you learn it's annoying syntax changes. I'm not working on any of them, so I will not be changing. When the dust settles, maybe it will survive and I'll find myself using it one day, assuming a major change in my direction. If it's the best tool, sure, I'll use it. But why change for it's own sake ? Not for me.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Agreed. Why change when it does not make sense. But there will be quite a few situation that do make sense.
Many developers will not need to change, but many will and they seem to be afraid or defensive about it (sort of like an animal backed into a corner ).
I guess I am just really confused as to many developers reactions to .Net.
|
|
|
|
|
Oh please.
You say you believe that people should use the right tool for the job, then chastise developers who are aprehensive about jumping on the .NET bandwagon?
Smart developers will wait until .NET is released and proves itself as a solid platform before embracing it.
PS. Have you taken a look at MSDN Online recently? How can you seriously say .NET isn't being shoved down our throats?
|
|
|
|
|
I am not chastising developers who are not jumping on the .NET bandwagon. For many it does not make sense, however there are developers out there that it would make sense for.
I guess the questions really should of been, "If so many of you hate what Microsoft is doing, why are you developing products on the MS platform?"
You wrote "Smart developers will wait until .NET is released and proves itself as a solid platform before embracing it.", and I agree with you. However there seems to be many developers who already have make up their mind, which is ".Net is crap" ... this hardly seems reasonable to me, don't you think?
I find this "Love/Hate" relationship that most developers have with MS quite amusing.
|
|
|
|
|
I suspect a lot of people who, like me, answered that they will not use it meant they won't use it until it has proven to be useful. I know there was another spot for it, but we like to balance all those mindlessly fawning over it in the assumption that if you don't love what M$ are doing you will never work again.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
I believe that one should use the right tool for the job, not the other way around
My complaint about .NET is that I can't get a straight answer about what job it is the right tool for. Many things about it sound good, but whenever I have posted a question in the Lounge asking how to plan for .NET in terms of figuring out what parts of my work it might be appropriate for, all I have gotten is a lot of "I can't comment because I am under NDA."
It would be really nice for people here at Code Project to start a serious discussion about where .NET is helpful and where it's not.
Right now, I do a lot of hard-core C++ for performance-critical work and a lot of Python to tie things together (with a mixture of MFC, Pythonwin, and wxPython for the UI). I am very interested in .NET for the UI portion of my work, since ActiveState promises great things with Python.NET, but I have not seen a good paper in all the hype surrounding .NET to help me figure out how to strategize planning ahead for it.
He was allying himself to science, for what was science but the absence of prejudice backed by the presence of money? --- Henry James, The Golden Bowl
|
|
|
|
|
Jonathon, why don't you get a list of specific questions together and I'll ask one of the guys at Microsoft (or Wintellect, or DevelopMentor, or...) to come up with some definitive answers.
Everyone I have talked to who has seriously looked at .NET and had a play around with some of the samples has been impressed - especially those looking to use multiple languages in the same app.
It may be that in the initial release of .NET there are areas where .NET is only appropriate for a subset of you work. Maybe you have n-tier apps and you write the client using traditional methods and the server using .NET (or the other way around - who knows). Maybe you need to support vanilla Win9x so .NET is just not an option, or maybe you can pick and choose your OS so it comes down to ease of use.
Personally I see the migration of Web apps to .NET will be fairly speedy, but traditional GUI apps may take a little longer. Managed extensions in C++ are a little funky but are certainly there for when you need to port existing code. I can't see many people writing managed applications from the ground up using C++. C# is so much easier, and in the end it all compiles down to MSIL anyway.
Just my HO, and is, of course, subject to change without notice
cheers,
Chris Maunder
|
|
|
|
|
Here is a start. I will gather a better list and post it to the lounge later on.
- Most of my work is on traditional GUI applications that run on a workstation (no client-server). For such applications, how should I think about factoring the design between managed code and non-managed code? Where will I take performance hits and how bad can I expect them to be? Where would .NET offer any great advantages?
- How hard is it to interface managed and non-managed code? I do a lot of direct hardware control (data acquisition, video capture, instrument control) and a lot of numerically intensive work. If I have a high-performance C++ signal-analysis library, how hard is it to pass lots of data back and forth to it from managed code? How hard is it to interact with non-managed 3rd-party libraries for frame-grabbers, GPIB interfaces, etc? Where should I expect performance hits?
- For client-server (2-tier), one big project I am working on is moving a workstation application written for Windows 9x and NT to a client-server model because many customers want to run it in client-server mode and access it from UNIX and WinNT workstations. How should I think of .NET in the context of Win2K server with heterogeneous clients? The application in question here does fairly involves analyzing large (millions to tens of millions of character) strings and producing graphical representations of patterns it finds, which the client should be able to interact with in a GUI. The server must also be able to interact with processes on remote UNIX machines. The requirement to play well with UNIX is driven by the customers' demands (UNIX is their industry standard and comparatively few of them use Windows extensively).
- Right now, I'm investigating CORBA (with various Python ORBs) for the cross-platform C/S work and would want to know how .NET would play in a CORBA context. Perhaps SOAP would be a better protocol, since I don't need all the bells and whistles of CORBA. Again, MS does not give me much to go on regarding cross-platform work.
- On the subject of your comment "I can't see many people writing managed applications from the ground up using C++. C# is so much easier, and in the end it all compiles down to MSIL anyway," one big feature of C++ for me is the ability to do generic programming (STL, etc.). I write a lot of template classes to implement design patterns and algorithms. From what I understand, C# does not support generic programming. Is this correct?
He was allying himself to science, for what was science but the absence of prejudice backed by the presence of money? --- Henry James, The Golden Bowl
|
|
|
|
|
Hello!
Your question about support of generic programming in C#/.NET was probably answered by Anders Hejlsberg in his well-known interview
for O'Reilly (http://windows.oreilly.com/news/hejlsberg_0800.html)
There Anders stated (about adding generic-programming features) that:
"It's not going to happen in the first release, that much we know,
but we are working on making sure that we do things right for the first
release so that generics fit into the picture."
Just note that it seems (this is my conclusion based on info from this
interview) that support for generic-programming was built to the common language runtime and it will available for other .NET languages, too (not only for C#) with support for cross-language use.
Slavo.
SlavoF
"I hear and I forget. I see and I remember. I do and I understand."
--Confucius
|
|
|
|
|
Hello!
Your question about support of generic programming in C#/.NET was probably answered by Anders Hejlsberg in his well-known interview
for O'Reilly (http://windows.oreilly.com/news/hejlsberg_0800.html)
There Anders stated (about adding generic-programming features) that:
"It's not going to happen in the first release, that much we know,
but we are working on making sure that we do things right for the first
release so that generics fit into the picture."
Just note that it seems (this is my conclusion based on info from this
interview) that support for generic-programming was built to the common language runtime and it will available for other .NET languages, too (not only for C#) with support for cross-language use.
SlavoF
"I hear and I forget. I see and I remember. I do and I understand."
--Confucius
|
|
|
|
|
I think Chris Sells summarized how I feel about .NET on the ATL mailing list:
"When I first learned VB (version 5), I tried to use it for every new
project. For simple things it was great, but for things even a little
interesting, I found myself forced to use C++ for the pieces I couldn't do in VB. On most projects, I eventually gave up and went to all C++. After enough projects doing this, I don't try VB anymore.
Now that I'm learning .NET, I'm going to try it on my new projects. We'll
see how it goes."
That's how I feel as well. But that being said, I have a few complaints as well which make me resent .NET already:
1) As I understand it, all the really cool stuff about .NET that would be really nice for C++ programmers is wrapped up inside the CLR. (GDI.NET, ADO.NET, etc.) This is really freakin' annoying. All that effort expended, and we have to write managed C++ (or C#, VB.NET) to get to it. Someone please tell me if I'm wrong.
2) Bug fixes and needed updates in other C++ libraries (ATL, MFC, STL) have been ignored.
3) Innovations in MS's C++ libraries (MFC, WTL) have been ignored. Witness the 105 comments to Walter Sullivan in the lounge on a new MS C++ class library, if you are in doubt.
4) Don't get me started on the lack of VC++ compiler standards compliance.
No wonder there is a resentment from C++ developers. I feel we have been second-class citizens to MS for a long time. Now we get a language that is supposed to appeal to us -- but no one seemed to be asking what we were really looking for.
In summary, how about better support for a language that is already a STANDARD?
As Chris Maunder says, just my HO.
|
|
|
|
|
Its great to hear opinions that make sense and are properly backed up
In my original post, I was trying to rattle some cages and see what fell out.
|
|
|
|
|
>> I feel we have been second-class citizens to MS for a long time.
>> Now we get a language that is supposed to appeal to us -- but
>> no one seemed to be asking what we were really looking for.
"Those who cast the votes decide nothing. Those who count the votes decide everything."
—Joseph Stalin
|
|
|
|
|
Not only is your premise insulting - that developers are "afraid" of change - but your attitude itself is an indication of one of the big problems in the high-tech world: developers who are more concerned about the latest thing than they are about producing good, reliable applications for their users.
Of course change is constant. But change at the pace we are seeing today is not helpful. Things change too quickly for developers to keep up. The result is that we learn something halfway, release a buggy or half-baked app based on the new technology, and then move on to the next technical challenge.
Microsoft has a history of releasing buggy and poorly documented technologies, and then announcing the next one before developers have figured out how to get something useful out of the previous technlogy. Remember COM+? Neither do I.
For a hilarious, yet accurate take on this, check out www.wdj.com/archive/1112/forum.html
|
|
|
|
|
I remember laughing my head off when I read that issue of WDJ. Well said, BTW, I could not agree more.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Whether you know it or not, you gave me one of the answers I was looking for. My main premise for the posting was to try and provoke developers into saying their opinion instead of just saying "I don't like it".
Also, don't get me wrong, I also think that technology changes prematurely. But many developers solely blame MS for the rapid changes... in fact a common business strategy among many software development companies is "Version early, version often." It's really a catch-22 situation, where companies who don't do this generally go out of business.
|
|
|
|
|
My problem is that I still can't see clearly what advantage .NET and C# will bring me... I'm a freelance C++ developer doing mostly business utility-applications for big companies (so I don't do huge programs, only the smaller ones that can be used outside the corporate framework) and frankly, I see no advantage in C#.
I expect that eventually, some managers will start demanding C# development once the MS buzz-machine has stuffed their heads with .NET propaganda, but so far, I haven't encountered an application that could not be written in C++ (eventually using MFC) or that took an incredible effort making me wish for a new development platform.
I would really like to see a poll where developers are asked which feature of C# they are craving for. I can not imagine that language independence would be number 1... nor pointer absence or yet another garbage collector...
jeroen
|
|
|
|
|
Personally I think that you are one of the people who would most benefit from C#. Like I have been stating in a number of the posts here, C++ is "easy" for those who have done it for a while (like minimum a year), but why bother doing the hard things?
The only reason I can see for staying on C++ is if you are a ATL/WTL fan. I really like the use of templates to customise a implementation of an interface to inherit from. And that will be sorely missed.
But the absence of pointers and a garbage collection are GOOD (unless you are doing very time dependant operations). Would you consider using "goto" or having a program with line numbers in this day and age? These things are the same. Read "The Structure of Scientific Revolutions" by Thomas Kuhn.
Have fun,
Paul Westcott.
|
|
|
|
|
Depending on what you are developing .Net may not give you many great advantages. The greatest advantages I see so far are:
- Web site development - Web Services, faster page processing, ability to use custom control without having to get them registered in the server first, better debugging, just plain better
- Better security model
- No more unknown memory leaks
- Processor independent - build once, run on any proc. MIPS, x86, PPC, etc.
- more standard built in functionality – pre-built forms builders, property sheets, grids, etc.
|
|
|
|
|
Seriously, when you say 'no more unknown memory leaks', you're suggesting that it is taken for granted that programmers don't know how to manage memory. Yes, sometimes we need to find them, but one MAJOR thing I have against .Net is that it presumes to manage memory for me. Stroustrup says the reason C++ didn't have memory management is you can get any number of 3rd party garbage collectors if you want, but had the language included one, it would have been stillborn.
If I wanted my hand held I would have learned VB.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
If I wanted my hand held I would have learned VB.
"Real programmer program in assembly."
Sound familiar?
Paul.
Have fun,
Paul Westcott.
|
|
|
|
|