|
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
|
|
|
|
|
- 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.
|
|
|
|
|
At risk of stating the obvious, when I had an Apple ][ and the OS was written in assembler, I used assembler because it gave me the greatest speed. Now my OS is written in C, C++ is the best tool for speed and direct access to the way my platform operates.
By all means use VB to write a simple database, or something that is not demanding. I don't because I don't write such things and when I do I am better able to use C++ due to my familiarity with it. VB is certainly a tool, so is .Net. The former has never been for me, and the jury is still out on the latter.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
From the looks of it, dot net is really an OS (virtual machine, "execution engine", whatever they want to call it!), and they say that it has mainly been written in c# since being bootstrapped, so maybe your comments are very apt =)
By all means use VB to write a simple database, or something that is not demanding
Although I don't personally use VB much at all, I think it has received more of a bad rap that it deserves because of the laxness of many of the developers rather than its failing. As for "not demanding", well, the vast majority of what keeps us all employed is "not demanding" I would argue. Complex maybe to some degree, but not demanding. And if you CHOOSE to structure VB you can - but let us not concern ourselves with VB, as I haven't used it enough to really be arguing its virtues! (I don't think it has that many, I just believe that it isn't THAT bad).
Have fun,
Paul Westcott.
|
|
|
|
|
I'm not afraid of change (or .NET). But i'm resiting .NET because MS has a horrible record of changing the hot new technology every three months. I have almost no idea what DNA or COM+ or DCOM are and i know it doesn't matter. MS will abandon all of them in a year or so.
-c
|
|
|
|
|
Yeah... the evolution of software development is a real pain in the #$%&*@!!!, but it keeps things interesting.
|
|
|
|
|
I agree that things do change way too quickly, but this is hardly MS's fault. If you go back and look at Mary Kirkland's (sp?) article from 95? 96? 97? about where COM was going you will find that the vision looked remarkably like what dot net is delivering.
Okay, so it's not COM. Why? Because Java changed the technology playing field (how dare a company bring out a new technology!) and MS instead of being stubborn and trying to fit the shoe onto the wrong foot saw that the basic structure was a better plan of the future, so they changed direction (how dare they change to something [at least analysed as] better?)
Oh, I agree that technologies come and go, and that "silver bullet" keeps changing (COM, Java, Design Patterns, UML, XML, COM+, dot net, to name a few!). The trick is just to have at least a passing glance at all of them so that you know when to use them. In my passing glance at dot net I have seen a gem which I will be panning for.
Its a tough life, keeping up, but if you don't like change, why be a software engineer? Retrain in civ eng and build some bridges if you don't want the technology to change with every day... God knows, thats probably want I'll be wanting to do after another 10 years of this  !!
Have fun,
Paul Westcott.
|
|
|
|
|
all true.
but, there is a lot more to programming than chasing MS around. I consider myself to be a "programmer", not a student of MS's various silver bullets.
-c
|
|
|
|
|
I'm surprised by the number of people who say "definetly not" (currently 62%).
Is this because you don't want to learn a new technology?
...because you don't believe the hype?
...because you don't think it could be any better than what we currently have?
Personally I am waiting with baited breath for a project to jump to dot net. I have been programming c++ w/ COM for a fair while now, and I find it "makes sence" but when I try to teach other people I realize that there are just so many "gotchas" that I went through, but have now forgotten (ie. I avoid them with my eyes closed), and I think its time to move on. (Example: playing between ASCII/UNICODE/BSTRs - something that should be a total no brainer, just takes too much effort.)
I think dot net is simplifying a lot of things which have become too complex, I see it as the equivalent step as the multiple memory models of 3.1 to the flat memory model of Win32. I mean if you were used to programming under the old memory model, you got used to it, and could do it, but it was a whole lot of wasted effort.
I don't like chance for the sake of change, but I think that it's not that at all.
Have fun,
Paul Westcott.
|
|
|
|
|
I believe it's the same reason as not admitting VB as a programming tool - mostly snobbism. . Believe me, you can write 80% of almost any application as efficiently in VB as in C++ if you understand what is going on behind the scene, but you'll spend much less time on writing type conversion code, etc. I've talked with a Microsoft's guy from the compiler group some time ago and he told me a sad story how they improved efficiency of the compiled code by 30% but the overall impact was negligible - any call to memory management subsystem eats for breakfast any compiler level improvements.
I understand that a lot of people just don't have a choice - you can't write device drivers in VB or C-sharp - but if you are writing server side code then CLR should be as good as Java. And some people just don't realize that there is no difference between managed C++, C-sharp and VB in the CLR environment. Paul is absolutely right - it's just different runtime model (or different C runtime library, or different virtual machine if you wish) and if you are going to use it depends entirely on your needs and trade-offs between safety, speed, availability and time to market.
BTW, in some (many?) situations CLR's memory management will be even more efficient then conventional heap-based memory management - it's very fast in the allocation phase.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
