I was kidding about the Microsoft thing, I was just frustrated with all of this. Let's hope that the learning curve for .NET isn't too steep, or otherwise I won't be happy.
/*Here Linux Linux Linux Linux!!*/
Printable View
I was kidding about the Microsoft thing, I was just frustrated with all of this. Let's hope that the learning curve for .NET isn't too steep, or otherwise I won't be happy.
/*Here Linux Linux Linux Linux!!*/
Well, I'd be a liar if I said no. I invested some time into understanding WinAPI and now Microsoft wants to kill it, doesn't seem like the best decision, but that's Microsoft for you.Quote:
Originally posted by Mick
people fear change :D
Well, Microsoft isn't really pro-Linux either :rolleyes: , they're 2 different entities trying to kill each other and come out on top.Quote:
Originally posted by indiocolifa
Ahh...
and about Linux, I don't feel comfortable developing with it. I'm not pro-Microsoft... but, nothing beats the Microsoft development tools for Windows. That's my experience.
True, Microsoft does have better development tools, but Linux is free and you're never affected by Microsoft's quircks, security problems, changes in thought, etc. That and Linux(in my opinion) will become the next big thing, companies have been investing alot of money into this, most notably IBM, not something that should be ignored.
It's been around for awhile. I for one welcome our new .NET overlords...Quote:
Originally posted by YourSurrogateGod
Well, I'd be a liar if I said no. I invested some time into understanding WinAPI and now Microsoft wants to kill it, doesn't seem like the best decision, but that's Microsoft for you.
It will make strides in the server side that's about it.Quote:
Originally posted by YourSurrogateGod
True, Microsoft does have better development tools, but Linux is free and you're never affected by Microsoft's quircks, security problems, changes in thought, etc. That and Linux(in my opinion) will become the next big thing, companies have been investing alot of money into this, most notably IBM, not something that should be ignored.
and, what about programming WinAPI under Linux!?
Solution for all WinAPI + Linux fans...
:D
www.winehq.org
Well, what do you know, Windows in Linux...
This still gives me some hope...
I hope Linux becomes the new way of things when it comes to desktops(most importantly at home).
It is true that from an economic point of view, basically forcing .NET development is one of the best thing MS can do.
It also makes programming easier and less time consuming, which is a good thing.
I am no expert but I find .NET easier than Win32 API...Quote:
Let's hope that the learning curve for .NET isn't too steep, or otherwise I won't be happy.
It just takes getting used to, and learning how it works.
As for Linux, it is getting a lot of focus today, but lets face it, Linux always has, and imho, always will be the programmer's OS.
I agree VS is a great development tool. But Linux is full of useful tools as well. Some good IDE's are Anjuta, Eclipse (which has great C++ and CVS support, but is slow cuz its Java), and Qt tools. And then there are the debuggers, memory profilers, and so on. It truly is the "programmer's" OS. Most of my work is in Linux, and while there is no "single ultimate tool" for dev, alltogether there isnt much Linux cant do for you.
Latem
and the fun will not be reading about what interface microsoft documents. The fun will be discovering what they don't and all the goodies that implies :DQuote:
Originally posted by RussG1
I really do not know much about managed code, but from reading TheCPUWizard comments:
The underlying .NET framework will basically be the new Windows API, and will have it's own functions in support of OpenGL, etc. Imagine learning to program windows later, without having ever learned the current Windows API, or MFC, etc, I imagine it will be much the same as learning the Windows API now (or learning to program using any new library, etc), but less error prone.
from what I've seen (that's a good amount) MS has excellent documentation for all of its products. Microsoft's new business is technology to empower developers. They develop...we develop...they make $....we make $....they make more than us...you know how it works. But they have the best documentation and backwards compatibility I've seen.
And while we're talking about business strategy the need for fast development is obvious. Where is all the money? Developing for business. Remember the first .NET ads? Those were obviously geared toward business development. And in business fast development time is key. MS is just trying to stay on top. API will still be there, but if you don't know .NET when Longhorn comes out don't go whining to microsoft. They're trying to keep up and so should you.
Just common sense. It would be product suicide for the LongHorn OS if they didn't have backward compatability. Your customers use your products and if those products do not run on LongHorn without a total rewrite of the code then your customers will be upgrading to LongHorn when you have completed the port. That could take a long time depending on the size of your codebase and the resources you have to throw at it...again common sense.Quote:
Originally posted by briball
But they have the best documentation and backwards compatibility I've seen.
So I guess that it's safe to say that if we get into .NET, we can forget about pointers, we'll use the "references".
Plus, correct me if I'm wrong, but Linux is taking quite the jump lately, alot of companies(IBM) and governments(Germany, China, etc.) are into Linux. I'm quite confident that Linux will be the next big thing in business, just like Windows was.
I'll go with the late 80's/early 90's model, with SCO (and various other UN*X vendors), OS/2, NeXt...catch me in 10-15 years if linux makes strides in the desktop market, I'll buy you a beer if yer right ;)Quote:
Originally posted by YourSurrogateGod
Plus, correct me if I'm wrong, but Linux is taking quite the jump lately, alot of companies(IBM) and governments(Germany, China, etc.) are into Linux. I'm quite confident that Linux will be the next big thing in business, just like Windows was.
Buisness server side, yes...I will give you that. Personal desktop market...that's where I do not see much market gain.
Unless the U.S and MS suffer an economic catastrophe, Windows will be dominating the desktop OS market
I always find the slow performance in the languages which doesnot have pointers. Thanks DMR for providing pointers in C.Quote:
Originally posted by Latem
I share the same concerns. It just doesnt make sense, how even if .NET is the "native" api for Longhrn, it will solve this issue. whenever you have intermediate code and garbage collection, you lose performace, and there is no way around it. I guess everything will be slower? and MS just doesnt care cuz we will all have good computers anyway. Or am I wrong about this?
Latem
I don't have any special interest in any of the OS we have at present but I love C/C++ always.
regards,
collin.
IMHO, C++ is the best all-around programming language.
Today I was writing some GDI+ apps in C++/.NET. Microsoft must speed up the IDE in Visual Studio for .NET development. Terrible slowdowns are common when working with a form with just three or four controls... and my machine is pretty fast, XP2600/512k, 1GB RAM.
So,.NET is slower not only in terms of runtime performance developing with WinAPI or MFC (or WTL), but also in the speed of the IDE.
Ok, ok, I give up, you guys chased me into a corner on this. God it's going to be painful to get used to .NET now. Probably the only thing that I'll use Longhorn in the future is to play games on and .NET, but I'll definitely have Linux.
Hi
no dought .NET performence is not really good on WIN32 OS , that is why i dont like it at all.
But as i was seeing the longhorn beta 2 or 3 days before , I found that longhorn is quite fast i did not find any perfromence dif as compared to my WINXP.
I was really expecting that due to completely based upon .NET it would be quite slow as my managed C++ program when i run them on my WIN32 OS.
So now my point is if longhorn perfromence is quite OK , why cant MS Make .NET perfromence better in WIN32 OS.
Is it due to routing of .NET calls to win32API.
Now my second point is about the individual specialities of dif langauges
Such as VB for Business App , C++ for Scientific and Perfromence Critical App etc.
With .NET , languages are no more than syntax , to access same .NET libraries.
wont it effect the productivity of future softwares market.
SO Why a programmer would learn new lanaguges , if i have to do programming in .NET i would learn say C# and good byes to all other languages.
I think .NET performance will be much faster when developing under Longhorn.
.NET learning curve is steep... from time to time I try to program something and I can't become comfortable with it ... I think I've developed a good affinity with WinAPI.
Yes. As winapi on win2k now.Quote:
Originally posted by indiocolifa
I think .NET performance will be much faster when developing under Longhorn.
Also winapi calls need a translation.
I'm worried about the winapi in longhorn. Will C/C++ be the same powerful language as it is now in win2k?
regards
collin.
that's for a 2600/512k, 1GB RAM machine..Quote:
Originally posted by indiocolifa
IMHO, C++ is the best all-around programming language.
Today I was writing some GDI+ apps in C++/.NET. Microsoft must speed up the IDE in Visual Studio for .NET development. Terrible slowdowns are common when working with a form with just three or four controls... and my machine is pretty fast, XP2600/512k, 1GB RAM.
remember that many clients don't have such (fat) computers.
I can't dare to ship a .NET App. to a 500MHz/128MB RAM Client... :)
So what wold be the overall concensus on whether to embrace the new .NET(even though I still have reservations about it) or just jump the Windows bandwagon and get on the Linux train?
/*just currious*/
for me I want to catch the linux (open source in general) train to feel myselft a (free) programmer,, not a MS products user..Quote:
Originally posted by YourSurrogateGod
So what wold be the overall concensus on whether to embrace the new .NET(even though I still have reservations about it) or just jump the Windows bandwagon and get on the Linux train?
/*just currious*/
but I must still improve my .NET skills because the market in Egypt is too much MS oriented :(
Your poor guy.Quote:
Originally posted by hspc
for me I want to catch the linux (open source in general) train to feel myselft a (free) programmer,, not a MS products user..
but I must still improve my .NET skills because the market in Egypt is too much MS oriented :(
.NET will probably become the standard (for Windows) eventually, so it cant really heart to learn it. You never know what your next job may require.Quote:
So what wold be the overall concensus on whether to embrace the new .NET(even though I still have reservations about it) or just jump the Windows bandwagon and get on the Linux train?
Latem
Oh well, I guess I should learn how to do that. I just hope that I can make some of the things that I did in WinAPI and that it could work draw just as well and quick. The bezier exercise for example.
in terms of quantity of coding, your program can be done easily with Gdi+ which resides on System.Drawing and System.Drawing2D namespaces in the .NET framework.
About the speed, I don't know if GDI+ is faster than the old GDI.
How would you use Managed C++ with a Win32API project (using only Managed code (or is it not possible to build Win32API app using only Managed code?))?
i.e.
How would you define the WindowProc?
Would it be the same, except in the message handlers you would convert LPARAM/WPARAM to Managed objects?
Anyone have skeleton code for a basic Win32API application using only Managed code for example?
hi all,
I have read this discussion after about six pages where filled,
oh my eyes went bad.....................
But what made me mad is that you all talking about API's in longhorn and now one have talked or came near the WinFX which is the new API for longhorn.(by the way, it's not all of it .NET).
http://www.c-sharpcorner.com/Longhor...onghornFAQ.asp
please see this link and read what is in it??
by the way, I don't like .NET either. I think it doesn't do anything better than slowing the performance of the computer programs.
There is someone who said that Assembly is history, I don't think so. and I don't do so either. Actually I'm an assembly programmer.
Assembly makes me feel better. It makes me have the control on everything (sorry out of the topic).
Regards,
Amrsfmt
I read parts of the article quickly but it needs more attention..
did you note that when it talks about backward compatibility, it means backward compatibility with .net programs not the win32 APIs !!!
Quote:
However, Longhorn supports backward compatibility, which means you can still use .NET Framework class library to write an application and run it on Longhorn.
Thanks for the link. Interesting stuff. One thing though, the description seems to be more for C# programmers which allready uses .NET technonlogy, so the changes may not be that big for C# programmers as it might be for VC++ programmers. I would like to see a description intended for VC++ programmers.
I'm glad I'm not the only one who's noticed. After all, it seems that with every new line of processors that become available, we end up slowing them right down with a "new and improved" OS. The more this trend continues, the less attention programmers give to optimization. It's like "who cares since everybody has a fast machine". It just leads to ever more sloppy code.Quote:
Originally Posted by amrsfmt
While nothing lasts forever, it would be nice to actually get a new product out of the box before it becomes unusable.
For me, Linux is looking better all the time, though it would be nice to see some lesser known operating systems get the attention they deserve. We can't (and shouldn't try) to unify the entire world on one platform or standard. Diversity is essential for the long run. It's how we find better solutions, but man has always been short sighted in many respects. Innovation doesn't come from those who blindly follow someone else. No single programming language is "the way to go".
It really is amazing how with all this, we're still stuck with a crippled hardware standard (16 hardware IRQ's for example). Just how do we always end up using the worst hardware and software combination, and then keep piling on new layers of patches and workarounds?
OK...I better stop this rant or I'll...
Not true. Eiffel has garbage collection but compiles down to C. Therefore performance is comparable. In fact there is a case study where a bunch of C developers said the same as you but went ahead and rewrote their existing C application in Eiffel and found that it was 10 times faster.Quote:
Originally Posted by Latem
It is possible that garbage collection does not slow down the execution (or just a little), with good garbage collection algorithms, but it is not possible to multiply by a factor 10 the speed. I think these C developers are really very bad programmers :p who uses many many memory copy operations, instead of using pointers.Quote:
Originally Posted by Kevin McFarlane
Of, course there is many case where a reference counter is really needed, and it is easy to implement in C++. And reference counting is as fast as garbage collection, and generally even faster.
A real problem with garbage collection, is the long interruptions it produces.
For example imagine a video game with 90fps, but which as interruptions of 0.1 second every second.
The same video game with only 80fps is really better, but no interruptions.
But, i think that longhorn kernel is not managed, and there will be at least good old memory allocations functions like VirtualAlloc.
Or, longhorn will sign the death of microsoft.
The garbage collection is not that matters. But the Intermediate code.Quote:
Originally Posted by Kevin McFarlane
By examining the steps for executing the intermediate code itself we can find it requires more time. I think this is a contradiction to time and space complexity.
There may be cases which some portion of the intermediate code may be faster than the C code but not the entire application.
To allocate using new without deallocating with delete looks like bad coding to me. I dont care if your using garbage collection, my spider senses are tingling when I do it.
What about malloc and free? Same deal?
ahoodin
Must be.
I still dont like it.
This is a quote from an Eiffel case study:Quote:
Originally Posted by SuperKoko
"AXA Rosenberg started to move from its legacy software to Eiffel by building its new software applications in Eiffel, a purely object-oriented programming language. As a proof of concept, AXA Rosenberg’s first Eiffel application permitted the company to access fundamental data much more quickly than with its legacy software. Initially, AXA Rosenberg software developers questioned Eiffel’s ability to perform as fast as C, because of the tradeoff between garbage-collection and speed. Eiffel proved to be not only 10 times faster than C, but also prevented memory leaks – a classic problem in C and C++ programming."
http://www.eiffel.com/executives/cas...xa/study1.html
Probably the speed gain came about by the more efficient OO redesign with genericity and multiple inheritance. I've come across cases where the same applies to C#, i.e., re-implement in C# and get better performance.
I think exactly what you think!Quote:
Originally Posted by ahoodin
It hurts the heart!
But, i can add something.
Garbage collection can automate memory managment.
But memory is only a particular resource.
Files, mutexes, and all kernel resources, and shared 'user32.dll' resources, need to be manually created/deleted, or can be automatically by a garbage collector that has been specifically programmed for these resources.
So with garbage collecting, you are not FREE (like java programmers), you depend on what has been implemented by the garbage collector conceptors.
Okay, i lied, this problem can be solved by adding the possibility to write destructors for a class.
But, i maintain that files must be explicitly closed.
Imagine you open a file, write in it, and that the file is closed ten seconds after, because there was no garbage collection between.
Moreover, if you open a file for write, without write sharing, and that you close it, and reopen it just after, it will make an error, because the first handle has not already been released.
This problem can be solved by garbage collecting file handles and retrying, if a file open function fails, but it is ugly, and it does not let the programmer FREE.
So, garbage collecting can only solve the problem of memory management, only memory.
I would echo the sentiment about freedom.
Furthermore, this "garbage collection" sounds like a license for programmers to be even more sloppy, and turn out even more poorly written code. After all, it would be all the less likely for you to notice your own mistakes. It is a known fact that the quality of software in general has declined significantly over the years. This whole .net thing will not help that, only encourage it, and cover it up.
If I write bad code, I want to know about it. I want to see an error or a crash when I make a booboo. I want to see resource depletion if I forgot to clear something. If the program keeps going as if there isn't anything I should or should not have done, I'll be less inclined to make improvements or find ways to optimize the performance. I cannot tell you how many times I think I have something working perfectly well, only to find out that certain operating systems or configurations exhibit a problem. We all know how it goes: "This can't be happening. My code is fine...". Then after much frustration, we find that little thing which fixes the problem. We find a better way to do whatever it was we were doing.
What we don't need is yet another layer between the program and the system. Performance has decreased with each new version of windows. New versions of programs often do the same - hogging more memory, slowing things down, etc.. This drives the consumer to want faster CPU speeds, more memory, and so forth. Then programmers take even more liberties, thinking "Heck, everyone has resources to spare...". It's a vicious, never ending cycle.
Sure, we all want better performance from our systems. However, these days the slowdowns are not so much due to a lack in the hardware, but the software. This "managed code" stuff will only exacerbate the problem.
I believe programmers need to take more responsibility for their code, not less. I get the impression that m$ is doing with programmers what they have done with the consumers: Make them stupid. Keep them stupid. Control everything. Hide things from them. Just look at how a simple thing like hiding file extensions has worsened the problem of viruses. The consumer is not encouraged to know what the extensions are, or what they mean. "Don't think. Just click here". It puts computers into the hands of even more inept consumers, and causing nightmares for system admins and maintenance/repair personnel. It seems .net will do this with programmers to some extent. It's a defense mechanism which gives rise to even more of the problem it aims to solve - Bad Coding Practices.
Quote:
Originally Posted by WizBang
bad programmers will be bad programmers.
not beacuse you use a managed language means you wont know what you are doing. You can go and learn how to use it, and improve it. If you dont have the curiosity to learn more, it will be the same if you use c#, c/c++ , java, pascal...etc. You may do the things, but you wont know what is really happenning.
I like more "normal" c/c++, but i accept that .NET is the future......at least, if what it seems to be..
learning c# and .net wont hurt you.......
True to an extent, but .net will make more of them, thus more bad programs.Quote:
Originally Posted by BlackWindzx
It's not what it seems on the surface. You have to dig past the hype to see what awaits. There is a lot planned at m$ for the windows PC user, and not in the favor of the consumers or programmers. That's probably too far off topic to go into here.Quote:
Originally Posted by BlackWindzx
As for learning .net, I do think it would hurt in my case, as it simply cannot be used for commercially distributed software. That again is part of the m$ plan.
Oh, what surprizes are in store...
Can I jump in here ?
Firstly : speed. .NET has been proven (by myself and others) after JITting to be around about 1.5 the speed of optimised C++. Not bad really.
The efficiency of .NET depends on how you write code. Small, well formed and highly re-used classes containing small methods are fast in .NET because once JITted they remain in memory.
Large, badly formed classes with huge methods and no code reuse (i.e. lots of copying and pasting) are slow in .NET because the JIT compiler has to recompile the same code over and over again.
I've seen apps (some done by people at my work) which take 20 seconds to fire up ! This is not a fault of the language (I find .NET surprisingly fast actually) but a fault of the programmer and their lack of object orientated methods.
For anything truly speed critical (i.e. raw bitmap manipulations) I just write a static dll or COM object in C++. Or more likely in machine language. My present application is starting to grow rather large and I don't believe it has more than about 200 lines of C++ in it (it's got about 500 lines of ML though).
So : right language for right job.
Secondly, I think we're missing the point of .NET here. What you lose in speed you infinately make up for in functionality.
.NET is a true object oriented language - i.e. everything is an object down to basic types such as int (System.Int32) etc.
In .NET we have things like events & delegates, reflection and a standardised class library which raise it so far above C++ in terms of the ease of implementation of a true object oriented design that I personally love it.
You can write truly elegant, reusable code in .NET. True you can do the same in C++ but let's face it it's somewhat of a pain.
And this is besides the fact that the network protocols and distributed application facilities in .NET go far beyond what C++ (or even Java) has. Take these other instances of .NET over C++ :
(1) Databasing. Databasing in .NET is a breeze and in C++ is a pain. I suppose that's why so many people turned to VB6.
(2) XML support. The XML support in .NET is truly fantastic. It covers just about every single thing you could ever hope to want to do with XML, and then some. C++ has the XMLDOMDocument stuff which is (again) a pain.
(3) Encryption. .NET's encryption is simple and easy to use. C++'s encryption is a pain.
As more and more technologies emerge .NET will wrap them up nicely and only the underlying C method calls will be exposed to C++. If at all. Take Windows Messaging, the Windows Management functions. All take 2 or 3 lines in .NET to use but take massive amounts of code (usually taking hours to write) to get them to do anything simple in C++.
This is what .NET is. Microsoft have made it as fast as they possibly could, and have done a great job in my opinion, because if they didn't people wouldn't start using it until Pentium XI's had come out running at 10,000GHz.
But that is not the point. The point is that it's a truly object oriented language with some exceptionally powerful features. And in this respect I wholly support it.
I believe I said in a seperate thread that we are all working in a subject which changes rapidly. Why do we oppose change so much then ? Let's face it commercial computing on any kind of scale has only been around for about the last 20 or so years. In this respect it's extremely young. And so of course everything is going to change every 10 years or so. Only time will tell whether the change is good or not.
However I think .NET is a great step forwards, and I'm sure most other people motivated by good design will agree once they've given it half a chance.
Darwen.
That is why i am using Windows 98 (and not the XP thing that has a 32 bits user32.dll, but is slower than the 16 bits one!).Quote:
Originally Posted by WizBang
Moreover, i am lucky and Windows 98 never crashes without any reason (of course it crashes because of my code when i am debugging).
New OSes adds very few new features, and programmers who think that everybody has a recent computer with the last OS, use these features, and the program don't work on old OSes.
When i program, i try to use only the features of Windows 95, NT 3.1, so that it works an all windows.
I program Win32 programs, not Windows XP programs!
I think that the compatibility must not always be done in the sense of new OSes that can executes all code, but also new code that works on old OSes.
That is wrong, if you program in C/C++ without knowing what you do, your program will crash. You MUST understand POINTERS to use C.Quote:
Originally Posted by BlackWindzx
The programmers that don't understand pointers are not recruted as C programmers, and cannot polute the universe with bad software.
But, with C#, more stupid programmers can program, but their code will correctly works on some machines, but will not be really good.
Moreover, since a C++ programmer must know how things works, he has learned how things works, and can program well, both in C++ and C#.
But if you want C# programmers to program correctly, they must start by using C++ and after they can use C# correctly (and gain in productivity of course.).
Finally, old C++ programmers that migrate to C#, can be happy to gain in productiviy.
For example:
I entered in the programmation world, by using BASIC (on a CPC computer, with a Z80 processor), and after i used Visual Basic.
After that, i programmed C++, and when i wanted to program interfaces, and fast coded applications, i reused Visual Basic.
But what i saw, is that before the C++ experience, my Visual Basic code was correct (i mean bug-free), but used big STATIC TABLES, no structures (instead of using a structure table i used many tables which correspond each to a field), and many, many GLOBAL variables.
My old code was ugly, it used very few functions, etc.
After using C++, i programmed very well, and fastly in Visual Basic, and used all the powerful features of Visual Basic.
The same could be applied for the shift from Assembler to higher languages.
How can you possibly write in C++ without knowing the instructions that the compiler generates ?
You can't write good, efficient C or C++ without knowing what the stack is, how many registers there are etc etc.
Let's face it I can write applications in Assembler which are
(1) Faster
(2) Smaller
(3) I have more control over what's happening 'beneath the surface'.
than the equivalent C++. Why should I use C++ over Assembler ?
Sorry SuperKoko, you're argument about C# programmers first learning C++ doesn't really hold water. That's like saying that every programmer in the world should start off with Asssembler.
As to using W98 and never upgrading... if we all had that attitude we'd still be using DOS. DOS is MUCH quicker that W98 - no graphics etc. Nothing to slow the processor down.
Darwen.
These discussions i.e.
(1) Speed.
(2) 'closeness' to the processor/operating system.
have already been covered in the last big technology shift - from assembler to 3rd generation languages.
Even to a certain extent from C to C++.
There's nothing new here which wasn't said 15 years ago.
The same arguements stand as do the same answers.
What I'm trying to get at are managed languages BETTER than statically compiled ones ?
I'd argue that they are : they are faster to write in and have considerably better support for object orientation and design. Besides the benefits of interopability/compatibility between platforms and even languages such as VB.NET and C#.
The shift towards Java has already demonstrated the readiness to move to managed object oriented languages. Microsoft have just taken it one stage further in .NET. I always considered Java to be more of an 'academic' language, the same way that smalltalk is an 'academic' language. Yes it's nice, and it's good at what it does but it's not GREAT and it's not designed for commercial use.
Microsoft have designed .NET with commercial use in mind : of course. Now people could say that it's "Microsoft trying to make more money" which undoubtably it is. But is that a bad thing ? They've done a great job in my opinion whatever their motives were.
Let's face it - we wouldn't have put a man on the moon if it wasn't for the Cold War. Most of man's greatest acheivements have been borne out of adversity, wars or shere need. Microsoft's need is to make money. Hence .NET was born, tested heavily, made commercially viable and more importantly designed to be USED in real applications.
The only way they could do that was to make it significantly better for the developer than existing languages. All the people arguing against are saying that it isn't better than C++. I am saying it is. A difference of opinion maybe, but don't base your judgements on the fact that your years of C++ code are going to have to be binned. Base your judgements on .NET on its own merits and whether it improves the development process of software. And I certainly think it does.
Darwen.
I think Sun would disagree with you here!Quote:
Originally Posted by darwen
;)
ahoodin
How can you say that when all .net programs can be easily decompiled back to source code? How will this help developers of commercial software? It might be easier than C++ to write apps for in-house use, but the same can be said for Visual Basic. One argument I see all the time against vb is that it dumbs down the programmer, and to some extent that is true. What I see is that .net furthers this trend, and many including yourself seem to embrace the whole idea of taking the "easy way out".Quote:
Microsoft have designed .NET with commercial use in mind : of course. Now people could say that it's "Microsoft trying to make more money" which undoubtably it is. But is that a bad thing ? They've done a great job in my opinion whatever their motives were.
Heck, we all like things to be easy, but time has proven that the more layers of fluff you put between the code and the heart of the underlying system, the less efficient it is. While .net can be "not so bad" if you optimize, it cannot help with the problems I cited earlier, namely poorly written, memory hogging, slower programs. If vb and Java are any indication, .net will only worsten these issues. You said it yourself that it will require the programmer to use good techniques to keep it from becoming inefficient, but there's no way it will improve performance over the same app being thoughtfully designed in C++ or other more efficient languages. Your main incentive to like it appears to be because it's easy. That's why so many C++ programmers hate vb!! There is a saying: "Nothing worthwhile is easy". Another saying is: "Everything comes with a price".
The reasons to upgrade a system should not include things like "because everybody writes crapola". Having a program not crash doesn't justify this.
I too use an older OS. I keep xp on another partition just for testing, and I can tell you with out any reservation that it is significantly slower. My system doesn't crash either, while everyone I know routinely upgrades and continues to experience problems. Everytime something goes wrong, they put in more "service packs", exchange hardware, etc.. It never seems to end for them.Quote:
That is why i am using Windows 98 (and not the XP thing that has a 32 bits user32.dll, but is slower than the 16 bits one!).
Moreover, i am lucky and Windows 98 never crashes without any reason (of course it crashes because of my code when i am debugging).
You cannot tell me that .net will make better programmers or faster programs. I'm sure it will make programs less likely to take down a system because of bad code, however systems will tend to need even more upgrading because of the loss in performance, and this will cost the company money. Consumers will essentially remain uneffected by .net, accept for freely distributed apps, in the same way Java does now.
What surprizes me is how so many can be led like lemmings off the proverbial cliff. Will you be so eager to return to C++ after awhile being pampered by the .net easy street? That's something I'd say m$ is counting on - programmers becoming "hooked on the .net drug", like many who never progress past Visual Basic. It will be like asking you to loose the GUI and return to a command prompt.
Would you argue that the trend should be toward programs you can't possibly sell? How will this help the commercial software industry? Plainly, it cannot, but this I think m$ is counting on. How you ask? From the sound of things, you'll find out, along with quite a number of others. This was first reported years ago, but few actually caught on. Perhaps some will be able to connect the "dots".Quote:
Let's face it commercial computing on any kind of scale has only been around for about the last 20 or so years. In this respect it's extremely young. And so of course everything is going to change every 10 years or so. Only time will tell whether the change is good or not.
Personally I hope that .NET will produce fewer better programmers rather than more worse ones.
I hated VB6. I still do. I approached .NET with grain of salt the size of Ayer's Rock. For a long, long time I slagged it off without actually knowing about it.
Now it's my language of choice.
I agree that being able to disassemble the code is a huge loophole - but there are ways to prevent this. I myself have written one which requires just one line of code in the application class.
The more I learned about .NET the more I kept thinking "that's nice". And it is - nice. It's a lovely language to work in.
It is easier of course than C++/MFC. However it shifts the difficulty of implementation over to the difficulty of design. Get the design wrong and you get SERIOUS speed implications.
I hated VB6 for pursuading some people that they were software engineers when in actual fact compared to C++ programmers they were the equivalent of the mail-boy. Cheap and plentiful.
Now we have .NET I hear VB6 programmers are having a serious problem moving to .NET. Good ! Maybe some people out there will learn that there's more to good software design than hacking something together which works.
As to not being able to sell it... that has yet to be proven. Isn't DevStudio 2003 written in .NET ? I'm not sure about that point but I'll put money on the fact that Office et al will be upgraded to using .NET and I bet that'll make Microsoft millions.
Java is a hobbiest's language. .NET is a professionals language.
Anyway there's no way that I'll ever win this argument - no-one will. Only time will tell. And I think we're all going to find that in time .NET will take over from C++. If it doesn't, no-one has lost anything. .NET could just be another tool in the arsenal which you can use to develop software. Use it or not, like it or not it'll always be there for those of us that do.
Darwen.
darwen:
Yes, even if Visual basic is easy to implement a GUI, it has many stupid limitations, and promotes static structures, it is why i was programming badly with VB before using C++.
But, you are probably right about .NET.
Maybe in a few years i will use .NET as my main language.
But, what i hope, is that Longhorn will maintain a maximum compatibility with previous OSes.
A perfect example of easy migration is migration from C to C++.
C++ maintains a quasi-full compatibility with C, and C++ compilers are generally also C compilers, so programmers can mix C code and C++ code.
I asked a question about Longhorn on the general developer topics forums.
Basically the answer was : Windows was always designed to support multiple platforms communicating with the OS.
Win32 is called Win32 because it's an interface to the OS. When you use Win32 you're not talking to the OS directly : you're going through its interface.
Now, a lot of the OS is presently written using Win32. Win32 and the OS are heavily linked.
What Microsoft is talking about with Longhorn is that the .NET framework won't go through Win32 as it does now, but instead talk to the OS directly. Even parts of the OS (rumoured) are being written in managed code.
Therefore the heavy linking between the OS and Win32 will end and instead .NET will replace it in this role.
So you'll have two ways instead of one to talk to the OS : Win32 and .NET.
So yes, Win32 will be supported but will gradually be phased out. Or rather support for new features, controls, protocols etc will be withdrawn.
I can't see Win32 going away just yet : but I would think that in about 5-10 years we'll see the role that Win32 has to play in the OS being drastically reduced whereas the role of .NET increasing exponentially.
Now to put your mind at rest Assembler will never not be supported by the OS. Parts of the OS will continue to be written in Assembler (device drivers, time-critical parts etc) and so therefore C++ compilers will still work. Presumably Win32 will continue to work well into the next decade too.
However with the potential enhancements in the UI engine, new standard controls, new management tools and APIs : these will only be supported by .NET.
You'll begin to find that your C++ applications are actually accessing .NET code instead of static C libraries and dlls, and at that point the purpose of writing application UIs in C++ starts to become rather silly. Again C++ will still be around for optimisations, time-critical and real-time code but more and more of the everyday tasks like interfacing with databases, serialization and certainly UI will be written using the .NET languages.
Personally I can see VB.NET being dropped too... especially if its pitiful takeup continues. After a few years if more programmers haven't turned to it I can't see that Microsoft will be able to justify the cost of keeping a minority language alive.
From what I've heard even VB6 programmers are turning to C# as their .NET language when they upgrade.
Let's face it : VB6 is now a dead duck. C++ will take considerably longer to die because of its multi-platform capabilities and the fact it's a standard. However as managed languages start to take over the programming community C++ will fade into the background (not go away all together I might add, just fade) to be used by the same kinds of people who still write Assembler today.
Maybe all of this is complete rubbish, but it's just my thoughts on the subject from what I've read so when the throwers turn on me, try to make sure the flames aren't too hot please.
I've tried to be very diplomatic so far, and I hope you appreciate it.
Darwen.