-
Re: Win32 API future ...?
Quote:
Originally Posted by darwen
It's a very good technology. In my opinion of course, but in many other people's opinion too.
FWIW, I completely agree with you. .Net is by far the most exciting evolution of developer tools in the last decade or so, including Java. Developer productivity will knock socks off IT Managers across the country, as they move to .Net.
My point with the previous rant was just that there will always be room for development at a lower level, closer to the hardware.
-
Re: Win32 API future ...?
Quote:
My point with the previous rant was just that there will always be room for development at a lower level, closer to the hardware.
I agree - there's always going to be room for assembler and C++ for speed-critical parts of applications.
Quote:
Developer productivity will knock socks off IT Managers across the country, as they move to .Net.
I would say that it is quicker to write applications in .NET than in C++/MFC.
However productivity might not imply quality. I've seen some truly awful C# designs in my time.
The same is true of C++ of course : but I really feel with .NET we have the opportunity to bang our drums about good design.
Darwen.
-
Re: Win32 API future ...?
Quote:
Originally Posted by darwen
I would say that it is quicker to write applications in .NET than in C++/MFC.
I completely agree with you there. MFC suffers from poor design, so I usually spend more time looking up obscure methods then actually coding.
I think you should have tried out Java. It existed before .NET and whenever I use it I find it to be extremely productive.
Quote:
Originally Posted by hankdane
.Net is by far the most exciting evolution of developer tools in the last decade or so, including Java. Developer productivity will knock socks off IT Managers across the country, as they move to .Net
This is my main problem with .NET. I see no way in which it is very exciting. It doesn't introduce any new major concepts to programming (maybe some extra keywords, but it does not have any features that are revolutionary). I also doubt that it is more productive than Java. You should look at Java's library before you talk about how good .NETs is. The standard java library that is shipped with the java package has about 3200 classes. The enterprise library has more than 700 many of which are devoted to internet related programming. Obviously quantity does not mean quality, but I think that you will find that most of Java's classes are of very good quality.
-
Re: Win32 API future ...?
Quote:
Originally Posted by darwen
My point was these moves were made possible by faster hardware e.g. going from the ZX Spectrum to a 286.
I don't think that the hardware is the only factor.
The optimization of compilers is a major factor.
Old C compilers were poorly optimized, for two reasons:
They were small and compiled fastly, because they compiled on old machines (even if the developers machines were better than the users machines).
The old processors had few registers, and each register was specific to a task, and optimization was harder to make automatic. Memory segmentation also complicates compilation.
For example, even a relatively recent compiler, like Borland C++ 5, is good for 32 bits code (with optimizations activated), but relatively bad for 16 bits code.
Now, C++ compilers produce machine code with performances very near to assembly.
.NET is probably the "optimized technology", which will promote managed code.
Java, for example is a slow language, since it is generally interpreted (i don't know if there are interpreters that compile internally java code, maybe someone can say me).
-
Re: Win32 API future ...?
Young people see less into the future than older people, who are usually more mature because they have experienced more. When I was young i disregarded every kind of way of programming machines, which was not fast enough or even fastest there is. This is what young programmers like - speed. That is why you have many of them writing computer graphic demos using x86 assembly.
Speed is important. In fact, speed is what has been one of the major factors of computer evolution. Faster, meaner machines. Faster CPUs, faster graphic cards, faster RAM, faster harddisks. We simply cry for more computing power, and when after buying state of the art machine promising a GigaFlop-like number-crunching performance, some piece of software reduces that to a mere 20% of that or less, we cry, but for another reason, that of dissappointment and regret and greed. Because we KNOW we DESERVE the full potential of the machine, and we praise the tool which is able to harvest that potential. We turn to languages which, being at least minimally understandable, produce fast code.
If that wouldn't be true, .NET would already be ruling us all. Because .NET syntactically and logically, in terms of making the programmer type in a more "humane" code, IS SUPERIOR to even C++ in EVERY WAY. Everything is just smoother, better syntax there. Less code, more design. Isnt it nice ? Oh yes. In practice however, as we understand that behind our written code stands the .NET executing machine software, which actually does what the program tells it to, we cant help but smell a cave-at. The cave-at is immediate speed of execution.
At this point I should deviate from my flow of thoughts and say that there exist a number of languages, proclaimed platform independent, and which have very unique and utterly important features, other languages could make use of. These are among others Ada. The thing with Ada is the practical implementation. Perhaps, with proper support, it could be the future, more humane, programming future.However, it is .NET now, and Microsoft which made the effort to push the ideology forward instead. So discussing "all all that could have been" is of no relevance here, because .NET is already here in practical form. Now back to my original topic:
The truth is, speed is a relative thing in computer world. I believe the idea behind .NET is perfect. You distribute very good looking human readable code which gets compiled into native machine languge. You dont need to adapt the code to any platform, because it is rather platform independent. Since the hard work of making the whole .NET-system work is taken out of the programming language part of it (it is nice and readable), it has to lie somewhere else down the line. We may conclude that the efficiency and popularity of .NET heavily relies on the efficiency and popularity of its single, i dare to say, most important component - the "compiler" or, the "program execution program" - the CLR, or however you want to call it.
Machines get faster and faster, and now you buy much faster hardware for the same price or less than its counterpart 2 years ago. The CLR does not stand still either. Microsoft is constantly working to make the code execute as fast as your processor would execute its x86 equivalent if it exist. So why are you **** bent on performance ? Because everybody has opinions, and so, a technology which is surviveable will also be competeable. .NET will find its place among people who value their energy spent on writing a program, more then the actual relative speed, which they know will improve, even though it may not benefit the current version of their product, but only subsequent projects.
And Microsoft will eventually succeed with .NET. There is simply no other way. CLR can only get better. Try to argue with that. They will find new ways to optimize the code, even on the level of semi-intelligent code analysis patterns, which will elevate the CLR almost to a level of a human analysing and altering the code to produce the same result faster. "Compiler" will change to "program analysis, alteration, optimisation and execution".
So to sum this up, my personal opinion is, that in the mind of a true programmer, aware not only of here and now, but also of the past and the future, the idea of .NET being a great start for a new era of programming should sink in sooner or later, while the younger people still rebel and swear to Assembler. These young people would also swear to typing a Windows P-EXE file by hand manually, if they could squeeze some precious cycles out of it, but it takes truly a master of programming to realize how monumental the idea of .NET is. You write in human language, and your program runs on a piece of silicon controlling a number of hardware devices.
Dont be a computer (read: program Assembly all the time), make the human out of machine instead (program a true high-level language adapted to HUMAN logic). You can also meet halfway, then it is a good deal I guess. And, it is not the .NET it is something wrong with, in case you didn't like it, but CLR. Dont blame .NET, blame CLR, because it is CLR which executes your .NET program.
-
Re: Win32 API future ...?
I don't see .NET as a perfect language nor C++.
I would prefer a functional language with support for metaprogramming techniques and templates.
Functional programming languages are superior to OO languages when it comes to creating algorithms that just _has_ to work (because in a functional language a function isn't allowed to have side-effects which is kind of the point with OO languages).
PS. Sorry if I'm OT here, getting late and I haven't seen an interesting article to reply on for days.
-
Re: Win32 API future ...?
Quote:
Originally Posted by SuperKoko
Java, for example is a slow language, since it is generally interpreted (i don't know if there are interpreters that compile internally java code, maybe someone can say me).
Java VMs always compile the bytecode.
As to Amns wonderfully flawed mini-essay. Where were you when Java came out? If you think C#'s syntax is "soo perfect" then maybe you should look at Java's syntax. There is a striking similarity. Microsoft's C# is a slightly modified clone of Sun's Java. Java is an extremely productive language, and whenever I use it, my code fails much much much less than C++. You may wonder then why I don't use Java for all of my programs? Because it is much slower than C++ (like .NET) and it is easily decompilable (like .NET). This eliminates .NET from the commercial desktop application market, and does not make it a serious contender to Java in the enterprise application market. Java is older and, consequently, has had many more years than .NET to improve its design. Although definately not perfect, Java's libraries are extremely easy to use (Swing is like god compared to MFC, I wish there was a C++ version, Javas distributed networking packages are exceedingly better than C++'s).
Since you seem to worship .NET I would recommend you try Java. You will be surprised.
None of the .NET supporters have given any reason why .NET is "revolutionary". It has no special unique features, and suffers many of the same problems as other languages of its type. .NET will get more popular not because it is revolutionary, but because Microsoft will force it on us.
Btw, .NET is not platform independant. It is independant among versions of windows. It will not convert and non-windows users to windows users, because non-windows users already have Java to use.
Another btw, I am not a big fan of Java. I just have to use Javas strengths to point out that .NET is not as revolutionary as some fanatics here seem to think.
EDIT: This will be my last post actually arguing with anybody on the matter
-
Re: Win32 API future ...?
No language is perfect. Everything has is drawbacks. Just take a few:
C
It's not OOP and since it uses pointers it's very dangerous, but powerfull when used correctly.
C++
Just lacks a few functionally that would be needed for good OOP design. And still has the pointers, but references would do the pain ...
Java
It is slow, and in my eyes it has an overcrowded (for example in the java.io.* package) runtime. So many BufferedOutputStringReaderWriterPrinters ... :sick:
C#
Might have some compatibily problems and restrictions for example in using generic types and/or if you try to make a deeper work on the windows platforms. It's hard to break out the universe of the .NET.
Assembler
It's complex, hard to overview but generates the fastest code. It is the basic language.
So you cannot define one language as the best. Neither Java nor C++ nor Assembly nor Fortran and so on and so on
Back to topic: Through the years the native Win32 API has come one of the biggest I know. It is very overcrowded of subsystems, functions and types that it must have an end, and a final OOP solution. And I think when we have a even as powerful .NET as the native WinAPI is, it is the end I always wished to have. And hopefully they don't cut out C++ of the .NET. Sincerly C is a dying race on Windows platforms. :cry:
-
Re: Win32 API future ...?
I agree with NoHero that no language is perfect. Each has its purpose
The problem with .NET is that it might not be an end to the endless clutter of the Win32 API. Judging from Microsoft's MFC, Win32 Api, Foxpro, J#, and other poorly designed languages and libraries, I have see no reason why .NET won't fall to the same fate
-
Re: Win32 API future ...?
Quote:
Originally Posted by Ben_Phillips
I also doubt that it is more productive than Java.
I have more experience with Java and J2EE than with .Net, and I can tell you from first hand and lots of second-hand experience: .Net is a lot more productive than J2EE.
Every Java developer I know that's tried .Net has been impressed.
You keep mentioning the Java libraries, but you don't seem to have taken much of a look at the .Net Framework. The breadth and width is impressive. Moreover, the design in the Framework is far more consistent than the Java packages, making learning curves smoother.
You say there is nothing new in .Net. I don't think that's completely true: the CLR is a new concept; it may get some ideas from the Java Runtime model, but there are significant differences. Saying C# is a modified form of Java is not entirely fair either; or, at least, if you want to say that, you have to own up to the fact that Java, after all, is just a slightly modified form of C++.
Anyway, even if there is nothing new in .Net, there is something to be said for taking all previous working models, pick out the best component(s) of each, and provide a better implementation that combines all of these.
The security model is superb, and is just one example where .Net far surpasses J2EE. For a good overview of the .Net security model, see this Foundstone Whitepaper.
I could go on, but as someone with years of experience in both environments, I can tell you: J2EE can barely hold a candle to .Net. The gap only seems to widen.
-
Re: Win32 API future ...?
This debate has gone way beyond the point of being pointless. Obviously the .NET worshippers have a closed mind, and, I guess I do (though I would argue that if someone could actually show me solid evidence that .NET is really great then I would try to listen)
Quote:
Originally Posted by hankdane
Anyway, even if there is nothing new in .Net, there is something to be said for taking all previous working models, pick out the best component(s) of each, and provide a better implementation that combines all of these.
The problem is that it doesn't pick out the best components. Finding major differences between the actual C# and Java languages is difficult (libraries don't count). Obviously there are small syntatic differences here and there, but nothing major. I'm not saying libraries don't matter for choosing a language (since they really are the major thing), but that when comparing the actual syntax of C# and Java there is barely a difference.
If you want a language that picks some out the best components of other languages check out the D Programming Language. It is a very young language and does not have the backing of a large workforce, but it is still very fun and its versioning, contracting, and debugging options are very attractive. It also has bounds checking, garbage collection, exceptions, etc that are really necessary to new languages. No it is not near perfect, but I am much more impressed by it than .NET
EDIT: Oh and Java is llike C++. It is an improved design though. C# is not an improved version of Java.
-
Re: Win32 API future ...?
I guess for me, the real question is whether Microsoft will rewrite their flagship server products in .NET and how well will that project go.
If .NET is everything that proponents say it is, then why not rewrite SQL Server in .NET?
-
Re: Win32 API future ...?
Quote:
Originally Posted by jack.dingler
I guess for me, the real question is whether Microsoft will rewrite their flagship server products in .NET and how well will that project go.
If .NET is everything that proponents say it is, then why not rewrite SQL Server in .NET?
Even better, how about Exchange Server rewrriten in .NET? Wouldn't that be a cool test?
-
Re: Win32 API future ...?
Actually I think SQL Server IS being incorporated with Visual Studio 2005
-
Re: Win32 API future ...?
The general theme of those posting in favor of .net seems to be ease of use. It makes life as a programmer easier. Funny how haters of vb use that same (dumbing-down of the programmer) argument against it. I have not seen anyone succesfully provide any reasons why .net would make a program do something better, faster, more efficiently or effectively, etc. Only that you can produce a program in less time and with less effort. This will IMHO lead to programmers becomming less like programmers, because something else is doing more of the thinking and actual work.
It's like a painter who, instead of actually having and using talent to paint a portrait, simply takes a photo of the subject, runs it through a computer program to add some fake brush strokes, and prints it out. Such a picture is essentially worthless, no matter who the artist is supposed to be. That's because the value of the work is not in how pretty the picture is when it's done, or whos' signature is on it, but the uniqueness of it, and the WORK and TALENT required to produce it. That's what I hear from people who hate vb: it lets anyone throw a program together, though the results are generally slower and less efficient, therefore less productivity can be derived from using such a program as compared to a well-written one. From what I'm reading of .net, it's along those same lines, yet people seem much more eager to hop on the bandwagon. Maybe it's because of the hype, or the fact that it's the "latest thing", or the promises of faster machines to hide the inefficiencies, or...
Still, the decompiling issue remains, staring us in the face, and it's as if supporters of .net have simply turned a blind eye to it. They seem to actually pretend it doesn't exist, in the hopes it will magically go away.
One or two refreshing posts point out that every language has both good and bad attributes. Every language has some uses in some segment of the market. That's fine, and I'm sure .net will hold to that trend. Java has similar drawbacks to .net, and it found a place in the market.
I suppose one reason why I dislike the whole .net thing is that I see programming as a kind of art. I LIKE the hard work it takes to make something truly good. This applies to any discipline, whether it be programming, woodworking, music composition, culinary arts, etc, etc.. Everyone understands the difference between a fast-food place and a fine dining establishment. You don't pay a large sum of money to have a meal slapped together by some kid just trying to make a few extra bucks on the weekends. You don't expect the equivelent of a walk-in vending machine. You want the chef to prepare you a real treat - better than the every-day junk. You want the atmosphere, the extra attention to details, the aroma, and so on. We are all familiar with the names of musicians who stand out because they are good at what they do, as opposed to those who are hyped up by the promoters. These artists get respect, and their works are not so soon forgotten.
What does all this have to do with programming? You might say that the industry changes to rapidly to bother trying to make an art out of it. However, we still are plagued by the 16 IRQ limitation of years gone by. I'm still waiting for the industry to get its act together and dump the whole kit and caboodle, windows and all. The turm "longhorn" really is befitting, as windows has IMHO outlived its natural lifespan. In fact, the m$ stranglehold on the desktop market is one thing I'd change if I could. There are better alternatives, yet here we sit with some of the worst standards of all which have been conceived. So, if you want to argue in favor of something because you think it's better in some way, take a look at other computer architectures and operating systems. "Don't want to change", you say? Why? Something else is better, so we should all jump on it, right?
That's why win32 is going to stick around. We're stuck with it for better or for worse, just like we're stuck with windows itself, unless you can work in a much smaller market. We're stuck with tons of spam in our email inboxes, even though there is plenty that could be done. Why? Because we have the SMTP standard which allows spam to exist. It wasn't designed to prevent spam, and people with a lower moral standard plague the world. We all know the value of email filters, and you might wonder why the same ideas aren't applied to the sending end, so that the spam can't even make the first hop from the point of origin. Well, that's standards for you, like it or not.
Ask yourself why you don't copy all your music in wave format instead of mp3's. Heck, who cares about space these days? Don't we all have 18000 Terabytes of storage and 240 Terabytes of RAM? Don't we all have a graphics accelerator card with more memory than your whole computer did not long ago?
The point of all this ranting is: To forget about optimization would make things far worse than it already is, for everyone. It's actually a good thing .net is so easy to decompile, because this will mean the software industry won't tend to sink to yet another new low so fast. Still, we are sinking, as hardware gets cheaper, and slow, clunky software is a dime a dozen. It is known that the software market continues to degrade in value. This is one reason why .net can gain appeal, for the same reasons that vb has. It just makes it easier to turn out a program that won't crash or create memory leaks. It does not make a person a better programmer, nor does it make programs execute faster or use less resources. While you can certainly optimize the code, the temptation to ignore that will rule the majority. Over time, this will bring down the value of the typical .net app, as more people begin with it rather than C++ or whatever. Only the availability of faster hardware and more memory will have the effect of closing the gap. It's a race we cannot win. Sooner or later we'll hit the brick wall, Moore's Law or not. Devices can't continue to get smaller and faster, while storage rises, without end. This means windows, .net, AND win32 are all doomed at some point, unless you expect technology to stand still forever in all aspects. The fact is, the computer industry makes continuous advances, and new standards are proposed all the time. However, consumers of this technology can't (or refuse to) change over night. It costs too much, or takes too long, or any number of other arguments. I see .net as just another one of these things, not as some revolutionary concept, or anything so grand that we should all stand and solute.
Win95 consumes about 300 megs with a clean install, and each new version continued to bloat the thing, such that xp takes 1.5 GB, requires more memory, and is notably slower. Moving to .net will add insult to injury. I don't see this as a rise in technology or value. Compare this to athletes: They train the body, optimizing every muscle for performance, speed, endurance, etc. Better understanding of how the human body works has resulted in higher standards for athletes. Today we can jump higher, run faster, swim longer, and much more. All better than in years past. Athletes are leaner than they used to be, because each muscle is more efficient. They don't grow extra limbs or get muscle implants. What we don't do is lower the bar for the fat guy who can't jump, or shorten the track and make the best runners wear high heal shoes to make it easy for those who aren't able to run as well. Taking steroids is illegal. Why? Because it's CHEATING. It's taking the EASY way out, rather than working hard to deserve your results.
I could go into a rant about the intellectual challenge, but I hope I've made my points clear by now.
-
Re: Win32 API future ...?
Just something to add to WizBang's post is that Moore's Law is failing us faster than we think. Not too long ago Intel was planning to have 5Ghz chips out by now, but that is way out of the question. As hardware is reaching its limits (like single CPU processors are nearly at their limit) we will see that the speed of most applications will not keep increasing. Multi-core hyperthreading processors are already planned and will be available faster than many realize (some are already available). Concurrency is becoming more and more of an issue now and "dumbed down" programmers will certainly not enjoy the inherit complications that arise with threads (not that anybody enjoys it, but "dumbed down" programmers will likely just skip threads instead of realizing that they are necessary).
Quote:
Originally Posted by WizBang
Win95 consumes about 300 megs with a clean install, and each new version continued to bloat the thing, such that xp takes 1.5 GB, requires more memory, and is notably slower
AND continues to be bugged. I will give Microsoft the credit of making XP much better than its previous Windows editions (did anybody ever use ME? I might go as far to say as that was the WORST o/s I ever used. Crashed on everything). Some argue that since Windows is the most popular O/S it will be the target of the most crackers, which although valid, still does not explain the massive amounts of bug-fixes that get slapped onto Windows every soo often. Did anyone look at the size of SP2? "Server pack" was an understatement. It basically updated the whole operating system! Although every app has its bugs, generally not everything is bugged. Windows suffers from the fact that each new version just modifies and builds on the previous one, meaning that it inherits the bugs and holes in the old one.
I'm crossing my fingers for Longhorn and I hope that it does not suffer from the same problems as previous versions of Windows. I find the fact that it is being rewritten in .NET promising, not because it is .NET, but because it is actually being rewritten.
Although I appreciate the massive effort that Microsoft puts into Windows, I have never been able to get myself to actually like Windows as an operating system. I want too, but the bugs just ruin it for me
-
Re: Win32 API future ...?
Quote:
Originally Posted by Ben_Phillips
Actually I think SQL Server IS being incorporated with Visual Studio 2005
The developer version of SQL Server is already available.
What I was referring to is whether Microsoft will rewrite the next version of SQL Server or Exchange Server in .NET, to prove that .NET is server ready.
I don't think they will. I think they'll continue to develop these products in C++.
-
Re: Win32 API future ...?
Ben,
When Java came out, I was at Comdex expo in Moscow, sitting in Sun booth, being handed the first russian translated "Introduction to Java" 15 page document. I was 15 and that was the 1994:)
And you ?
-
Re: Win32 API future ...?
Quote:
Originally Posted by WizBang
Only that you can produce a program in less time and with less effort. This will IMHO lead to programmers becomming less like programmers, because something else is doing more of the thinking and actual work.
Quote:
Originally Posted by WizBang
It's like a painter who, instead of actually having and using talent to paint a portrait, simply takes a photo of the subject, runs it through a computer program to add some fake brush strokes, and prints it out.
Quote:
Originally Posted by WizBang
I suppose one reason why I dislike the whole .net thing is that I see programming as a kind of art. I LIKE the hard work it takes to make something truly good. This applies to any discipline, whether it be programming, woodworking, music composition, culinary arts, etc, etc..
i have only been programming for 2 yeas (i am 19), but i think programming has to be fun. I like programming. And what i like about it, is that i have to use my logic and my imagination to make that some code becomes an amazing application (i like game programming), while i have to use those "logic words" (if, else,while,for,etc...) i think programming wont lose it escence.
What do i care if instead of using pointer i use references, or that the compilers takes care about memory managment??.
Better for me, the same logic and imagination but with a "prettier" and clearer code and in less time.
The argument you are saying is like the arguments that ASM programmers would say about the ones who use C/C++ or other "high level languages"....
.NET tech/languages is not THAT different from c/c++ to say that programming will lose its "magic" (art o whatetever you want to say about it) if you use it.
I program in c/c++ (for games), but currently i'm doing a "project" in c#, and have done many in java (for my school of course) and i think is not THAT different to say that......
-
Re: Win32 API future ...?
But you've already programmed in C++. A programmer that starts out with C# (or worse VB), will not have to worry about memory management, pointers, etc, which is obviously convenient, but not necessarily good. There is a lot of code out that is slowed down from the lack of knowledge about what goes on behind the scenes. One major problem I've observed with garbage collected programmers is excessive allocations. This is especially problematic when allocating an Object just to be used once, or inside of a loop that loops hundreds of times allocating new Objects each time it iterates.
I think managed languages are great and fun to use (particularly Java, and D [which isn't really managed but w/e]), but I think too much dumbing down of the languages will end up hurting the community in the end.
-
Re: Win32 API future ...?
Quote:
but I think too much dumbing down of the languages will end up hurting the community in the end
I think that's a bit harsh.
Firstly, let me say again that I came to .NET with a great deal of skepticism. Having worked in a VB6 environment (not for long I might add) I had a huge amount of predjudice about .NET. I started off learning VB.NET - mainly because I wanted to teach my son a programming language. I still didn't like it : but I started to think "maybe this isn't as bad as I thought it was" mainly because of the object orientation - which didn't exist in VB6.
This made me think that I really should go and learn C#.
I don't think that .NET is a 'dumbing down' of a language - yes it's easier to write UIs and memory is managed for you and it's hardly the holy grail of languages but as I've said time and time before I think it's great at object orientation.
Is promotion of design over implementation details dumbing down ? I certainly wouldn't say so. In fact good programming design I would say is harder than hacking things to get them to work. Mainly because it involves a great deal of artistry - and certainly from my experience in commerical programming not everyone can do it.
Yes I still code in C++ - and I still write segments of code in machine language for raw speed but to 'put them all together' I use .NET.
Comparing .NET to VB6 isn't really fair. VB6 grew from a rapid prototyping (at best) and tutorial (at worse) purpose. I would quite happily go back in time and shoot the person who's idea it was to turn it into anything but that. As I've said before (yet again) I think it's pursuaded far too many people that they can develop commercial applications when they can't. And been flamed for it.
Yes .NET isn't perfect, and yes you can decompile it. And yes this is a HUGE problem. I still love it now though.
Even though about 2 years ago I remember getting into such a discussion as this AGAINST .NET on this very forum. (or at least I think I do).
Maybe I just have a writing style which people automatically flame ? Oh well... the story of my life. :blush:
Actually no-one has mentioned the most obvious use of .NET in future : that of mobile devices. As mobile phones and PDA's combine (which they will in no doubt do in future) having a standardised framework on top of which your applications are built (with dlls and exes whose sizes are tiny) is a great advantage. Java will be fighting it out with .NET in this arena of course and it remains to be seen who will win. However it is worth considering.
Darwen.
-
Re: Win32 API future ...?
I think the future of programming is in cross-platform developing and rationalized software
-
Re: Win32 API future ...?
Actually maybe we're all just frightened of having an influx of not-so-good people into the industry ?
As programming languages get easier surely this is going to inject more and more people as base-level programmers ?
Isn't quality going to suffer because of this ?
I would argue that with all the outsourcing to second world countries that this is already happening with C++ anyway. Price versus quality again.
One of the biggest advantages of .NET is the fact that if you write horrible code you are punished speed-wise. In a huge way too.
I went on holiday recently for 2 weeks. When I came back I found that a project had been started on the first day of my holiday and was written in C#.
The application took 20 seconds (yes - you did read right) to start up. I had one look at the code and wasn't surprised. It was the worst piece of code I'd possibly ever seen. If it was up to me I'd have sacked the person responsible on the spot (or move them onto testing - anything so long as it was as far away from programming as possible).
This guy had been writing awful code in C++ for - well as long as anyone has known him. However it ran fine (apart from when it came to maintain it of course).
He applied the same methodologies of 1000 line functions to his C# and was sorely punished for his ineptitude.
By the way : I rewrote the application and startup time was as expected for a .NET application taking JITting into account (i.e. about a second or two).
Just an example of how bad design is punished by .NET.
Darwen.
-
Re: Win32 API future ...?
So you're saying .NET will find its niche in the mobile world? I can see how thats plausible (Java is horribly slow on phones, and according to your statistics .NET is approx 2x faster [Java is 3x as slow as C++ on average)). In the future I'm sure mobile devices will have a big market, but I think we still have a few years before it becomes a major market (as I stated earlier, the vast majority of programmers do not code for mobile devices, and the market doesn't change overnight).
Heres what I've decided too do. Since this debate is past the point of being meaningful, I'll try using .NET for a serious project (specifically C#, VB is not even in the question). I have no specific ideas in mind, but I will not do anything too time consuming (except in the tiny chance that I will like it). This way I'll know more specific features and can give a more professional opinion than the one I have formed. Will I like it enough (or at all) to use it for serious programming? Probably not. BUT I will be able to perform better in a debate like this (I would recommend to darwen to try Java, I know people who would blow up if they heard Java called a "hobbiests" language ;) )
-
Re: Win32 API future ...?
I'm pleased that all my work on this forum has made at least two people consider .NET.
This is not a dumbing down of programming - it's a transferrance of emphasis from getting things to work to a good program design.
I believe I've already said this.
And I hope my articles on Assembler give me a little credibility in this area.
My "Introduction to Assembler" article is the top article at the moment.
I like assembler, I like C++ and I like C#. I use each language appropriately. In other words, I pick whichever language is the best in providing a solution to my current task.
Darwen.
-
Re: Win32 API future ...?
Quote:
Originally Posted by Ben_Phillips
I'll try using .NET for a serious project (specifically C#, VB is not even in the question).
Quote:
Originally Posted by Ben_Phillips
(I would recommend to darwen to try Java, I know people who would blow up if they heard Java called a "hobbiests" language ;) )
Thats good. Knowing more laguages/technologies wont hurt anybody!.
Maybe you can mix them up.
For example, you could use java for a server, c# for an app that needs connection with webservices or so and c/c++ for doing some graphics......
-
Re: Win32 API future ...?
Quote:
... or so and c/c++ for doing some graphics......
At present I'm writing an application which needs high quality graphics. This is written using .NET, C++ and machine language.
I'm only using C++ to mediate between the two, in a static dll.
I'm using .NET rendering of text to a bitmap (4x size on screen) to calling (using p/invoke) to a C++ dll (not optimised because it's 2002 C++ standard) calling Assembler (compiled in MASM) to place surrounds and blurred shadows on the bitmaps. The text is then scaled down to correct size to produce antialiasing (using Assembler).
I can render 5 rows of 30 characters accurately (i.e. no problems with Times New Roman Italic 'f'") at 160ms.
That's on a 2.8GHz laptop with 256Mb of RAM.
This isn't the fastest that I've ever seen (I used to work for Xara) but I've already proven that GDI+ is pretty darned fast considering. This is 10 times faster than anyone else in my particular market.
And what does .NET do ? It manages the whole rendering process. The entire UI to the application is written in .NET (C#).
EDITED:
.NET creates the bitmaps. .NET requests the bitmap size from my dll (in C++ and Assembler). It creates a 32-bit DIB bitmap which is filled from my dll. All the alpha-blending (i.e. the transparency overlay) is handled by calls in .NET. All my dll does is to produce a 32-bit bitmap with appropriate alpha channel. .NET does the rest.
Please stop trying to tell me that .NET is slow. It isn't.
Also please stop trying to tell me that .NET can't be used for graphical applications. I have proven it can.
You need to know enough about it - same as any programming language - and work with it, not against it.
EDIT AGAIN:
I could have written my .NET code in C#, VB.NET, Delphi.NET or C++.NET. I wouldn't have mattered one jot. I have proven that used correctly .NET can be an effective language - because it interfaces so well with dlls.
I have given away far too much in this post about my future plans, but I really believe in .NET as a management language (i.e. like C++ manages calls to Assembler) and that's the way I feel it should be treated.
Darwen.
-
Re: Win32 API future ...?
Quote:
Originally Posted by darwen
Comparing .NET to VB6 isn't really fair. VB6 grew from a rapid prototyping (at best) and tutorial (at worse) purpose. I would quite happily go back in time and shoot the person who's idea it was to turn it into anything but that. As I've said before (yet again) I think it's pursuaded far too many people that they can develop commercial applications when they can't. And been flamed for it.
This is exactly the point I was making! I agree that vb lures many into trying to be a programmer when they just aren't the sort who should attempt it. That's how I see .net, because of possibly even more of this kind of thing.
Quote:
Originally Posted by darwen
Actually maybe we're all just frightened of having an influx of not-so-good people into the industry ?
As programming languages get easier surely this is going to inject more and more people as base-level programmers ?
Isn't quality going to suffer because of this ?
Absolutely. Again a point I've been making.
Quote:
Originally Posted by darwen
One of the biggest advantages of .NET is the fact that if you write horrible code you are punished speed-wise. In a huge way too.
True again, but it's not as much of an advantage when everything is slower than it can obviously be, because the bad programmers won't actually know they wrote bad, slow code. If a lousy programmer has a fast machine compared to the average user, he's even less likely to notice. And of course many of these same individuals do exactly that - they go and get the most powerfull system they can get their hands on, believing that as a programmer, it is somehow necessary for them to be ahead of the curve in that regard. This leads to more slow/buggy programs all over the place, thus more end users find that their systems are too slow, and/or crash a lot. The first thing they do is download all the service packs, and if they're lucky this won't hurt (too much). When that's not enough, they decide they must "upgrade" to the newest OS, which of course only compounds the problem, so then they go and buy new hardware, and the entire process starts all over again, because the "programmer" knows the end users might be catching up to his level of hardware. It's a vicious cycle without end. Now, I'm all for advances, but for the right reasons. We aren't actually getting the benefits of the new technology when these sorts of things happen, and from what I see, .net will make this problem larger.
There is good reason for learning math problems without a calculator first. Then once you have a good understanding of how it works, a calculator makes more efficient use of your time. The same goes for programming. If you are already proficient in something like C++, then .net will be like candy, but you'll know when you've written horrable code. On the other hand, starting in .net will (for most) be worse than starting in vb.
As for longhorn being written (even partially) in .net, that's highly doubtful IMO. It may be designed to favor .net code though, which would of course encourage programmers to use it if win32 is turned into a bottleneck. Perhaps this is part of the plan? By getting a bunch of apps built in .net out there, this would lay the groundwork for longhorn, since moving from the current OS would ostensibly help speed-wise. Get enough of that momentum going, and presto - a new OS takes the market share once again, which it can't otherwise do if the move to it made everything slower by comparison. So essentially, they both create a problem and then a solution. Nice trick.
-
Re: Win32 API future ...?
Quote:
Originally Posted by darwen
Please stop trying to tell me that .NET is slow. It isn't.
Also please stop trying to tell me that .NET can't be used for graphical applications. I have proven it can.
in comparsion with c/c++ yes it is. And that is something nobody can negate.
When i say for graphics, i meant 3D graphics (sorry, that was my fault).
As far as a i know, .NET (with c#) has only 2 commercial games.
By that i dont mean you cant do it, but it is still in a growing procces (in that area of course), and while .NET 2.0 (or "newer" versions) comes out i think no big company will risk to make a game with .net if they still have c/c++....
I also beleive .NET is the future.....thats why i'am moving from java (to c#), but i wont leave c/c++ and J2ME....at least for a while.
-
Re: Win32 API future ...?
Quote:
So essentially, they both create a problem and then a solution. Nice trick.
Absolutely WizBang. I totally agree with you.
Let me tell you a little anecdote :
I had my annual staff appraisal today.
It was done by the Project Leader (there's only 2 people on my project, myself one - so he's my immediate superior and I sit almost next to him).
He asked me a simple question.
Out of 100 software companies how many do you think adheres to even one philosophy of object orientation - for example never writing the same code twice ?
I replied to him statistically zero - you'd have to go to 10,000 companies to even find one or two which took object orientation seriously enough to implement real code sharing - in whichever form be it libraries or dlls.
I really hope that with the .NET languages companies will HAVE to adhere to even the basic object orientation rules : that you don't write anything twice.
If they don't they'll end up with horrendously slow applications.
This is all because of the JITting of course - if you have a piece of code duplicated all over the place then it all has to be JITted individually. However if you have a single function called in many places it only has to be JITted once.
I know this isn't going to happen.
I've said for a long time that programming isn't considered to be a profesision by any government.
Look at the other professions : lawyers, architects, doctors, nurses, surveyors... all have to pass an additional qualification after their degrees to ensure quality in their particular profession.
Anyone can be a programmer. Road sweeper one day to training course to programmer. This of course is a generalisation, but you can see what I'm saying.
It's about time that governments considered our profession important enough to start exerting the kind of standards that other professions require their students to meet.
Until that happens the whole industry will be lost.
Whether you write in C++ or .NET it doesn't matter. What matters is that you should have attained a certain level of competency. Otherwise we will continue to be flooded with VB6-like programmers who mess up the industry and pursuade our clients that applications are full of bugs and are generally awful.
Darwen.
-
Re: Win32 API future ...?
Quote:
therwise we will continue to be flooded with VB6-like programmers who mess up the industry and pursuade our clients that applications are full of bugs and are generally awful.
OUR clients ? How is that THEY mess up industry, and yet pursuade OUR clients ? Aren't those clients THEIR clients ? I think you ought to worry about YOUR clients, with your own bugs, and let THEM deal with THEIR clients.
-
Re: Win32 API future ...?
Quote:
Originally Posted by BlackWindzx
in comparsion with c/c++ yes it is. And that is something nobody can negate.
Yes, it is slower, but if correctly used (that means, critical routines written in C++ or assembler, and global manipulation done with .NET), it can slow down the application by a so little factor that it is not noticeable.
And the code is more maintainable, less buggy, and have no memory leaks.
And for the user point of vue this application is really better, because many programmers don't remove all memory leaks (personally, i remove all memory leaks, even smallest, and i deallocate all remaining memory at application exit, even if it is not necessary, because virtual space is automatically deallocated, but all programmers are not like me).
Moreover many programmers write buggy applications and sell them.
Of course, with .NET, there will remain buggy applications, but with less bugs, and no memory leak.
And, yes, the fact that bad coded applications on .NET are slow, but runs, is really a problem, because many bad programmers will not notice that their design is bad, and sell slow applications that need the last processor on the market to correctly run.
But is .NET bad for this reason?
Good programmers can use it, and not doing so will not resolve the problem!
Moreover, i think that programming in C#, for example, is better that programming in VB (VB promotes static structures and non-OO projects).
VB has already introduced bad programmers in the programmer world, and new bad programmers will directly use C#, or VB.NET, and that is better than old VB.
-
Re: Win32 API future ...?
Quote:
OUR clients ? How is that THEY mess up industry, and yet pursuade OUR clients ? Aren't those clients THEIR clients ? I think you ought to worry about YOUR clients, with your own bugs, and let THEM deal with THEIR clients.
What I meant was the programming community is all getting the same reputation.
Firstly, VB6 programmers aren't inherently bad. I've seen some really good programmers who use VB6.
However I've seen a lot of bad ones.
Again, the C++ community have bad programmers too. However since C++ is harder to learn and use than VB6 I like to think that we have fewer bad ones.
Unfortunately VB6 is used a great deal in commercial applications directed at PCs. Therefore we are all "getting tarred with the same brush" i.e. the whole industry's reputation is affected by all the bad code being produced.
.NET doesn't solve this issue, and neither does Java. I don't really think that there's a 'holy grail' out there. The whole industry is in somewhat of a mess.
I'm just doing my best to prove that it is possible to produce high quality software rapidly : and I think .NET is a better tool to do this than C++.
I personally NEVER have memory leaks in code. A memory leak in my mind is a show-stopping bug and should be fixed immediately.
However from my experience most companies ignore memory leaks and 'blame the operating system' when their applications fall over.
So I go back to my previous statement that we should have standards of practice the same as all the other professions have.
Darwen.
-
Re: Win32 API future ...?
Quote:
Originally Posted by darwen
So I go back to my previous statement that we should have standards of practice the same as all the other professions have.
Isn't that what m$ kinda sorta did with the whole "xp certification" thing (whatever it's called), which hardly anyone seems to be doing anyway?
-
Re: Win32 API future ...?
No. It's not.
With Doctors, Lawyers, Surveyors, Nurses and every other profession governments have set up bodies to regulate their industries and prescribe exams for people wanting to go into their professions.
The exams are set by an external body which decides the standards which must be met by all people.
Microsoft is a company. Besides the fact that to attain a Microsoft qualification (apart from MVP) costs a great deal of money.
I'm suggesting that we should have bodies such as the "Royal College of Architects" or "The Royal College of Law" or the equivalent in every country in the world. I would like the governments of the world to see that programming is a profession - and should be treated as such.
If that happened we won't have companies employing large numbers of people producing rubbish code, and charging ridiculous amounts of money for what will in the end be a bug-ridden solution.
Darwen.
-
Re: Win32 API future ...?
Well, not sure how things go where you are, but in the USA, the government would truly screw things up for everybody if they got involved with the formation of any required standards for programmers. It would cost huge amounts of money, and provide no value in return. In short; a bad idea. That's my take on it.
Some questions for you darwen:
In your example of a program written with .net, utilizing a C++ dll and so forth, It would be interesting to know the following:
1) Does any part of your code access win32?
2) If (1) is yes, can you do without, and at what cost in speed, and how practical would it be to do?
3) What impact on speed would there be if all of it was written in .net, and can you still avoid using win32?
-
Re: Win32 API future ...?
It is in fact written 99.9% in .NET. I have machine language for some realtime bitmap manipulation as well as using DirectShow (with an interface written in .NET, no C++ involved).
I couldn't see any real speed improvement by using Win32 : in fact some of the things I'm doing which involve events, reflection and GDI+ would be considerably more complex to do in C++.
Darwen.
-
Re: Win32 API future ...?
Quote:
Originally Posted by WizBang
Some questions for you darwen:
In your example of a program written with .net, utilizing a C++ dll and so forth, It would be interesting to know the following:
1) Does any part of your code access win32?
2) If (1) is yes, can you do without, and at what cost in speed, and how practical would it be to do?
3) What impact on speed would there be if all of it was written in .net, and can you still avoid using win32?
but is it not supossed that every .NET app acces the winapi? or it's not the same saying win32 and winapi?
-
Re: Win32 API future ...?
Quote:
Originally Posted by darwen
I couldn't see any real speed improvement by using Win32 : in fact some of the things I'm doing which involve events, reflection and GDI+ would be considerably more complex to do in C++.
But GDI+ is still part of the current API, just a newer part presumably because the functions couldn't be added to GDI without messing it up.
Quote:
Originally Posted by BlackWindzx
but is it not supossed that every .NET app acces the winapi? or it's not the same saying win32 and winapi?
Well, yes. Since the winAPI as of now is win32. This is sorta the point of the thread, which is if .net will somehow replace win32, right? So, my questions are aimed at the idea that if the application were to be run on a win32-less, .net version of windows, would it still work? I find it extremely hard to imagine phasing out win32 unless .net somehow eventually becomes faster. Even then it will take a long time. What I think is more likely, is that .net and/or longhorn will "pretend" that win32 is being used when it isn't. That is, when an app tries to call a win32 function, the system will re-route it to whatever the replacement is. This will inevitably, or even purposly result in a loss of speed, and the users will cry for a new version. Then the author will be forced to make the updates, or loose customers. Basically, will it not have to benefit the programmer to avoid win32 in longhorn? Lets face it, if calling a win32 function in longhorn still achives a speed increase, we're gonna keep using it.
-
Re: Win32 API future ...?
Maybe I'm working on the first commerically saleable application in .NET.
So far I'm really impressed by the speed and inherent object orientation of .NET.
I just made a leap forwards towards deployment today (i.e. doing things speedily, because I've designed the application well) - and again .NET has proven its worth.
I really can't say much more than this. WizBang - why don't you just try C# ? I think it'll surprise you.
Anyway that's it. I think I've said all I'm going to say on the subject. You can take my posts as either a Microsoft advertisement or as they are intended as a long-term C++ programmer thinking that it's a very useful technology.
We can fight about this forever. But I'm going to leave it now.
Darwen.
-
Re: Win32 API future ...?
Quote:
Originally Posted by darwen
However from my experience most companies ignore memory leaks and 'blame the operating system' when their applications fall over.
Never heard of such incidents. Nowadays whoever manages to ship a medium sized product, implies understanding that the platform doesnt just throw out bugs, even though their app is 'perfect'. I remember such things in days of Windows 95 and 98, but with NT 5.0 core, i never heard of people ignoring their own memory leaks. Besides, whoevers fault it is, usually the vendor of the product fixes the product either way. If WinSock 2.0 is not stable, use WinSock 1.1 - simple as that and wait until the ws232.dll will be stable.
Quote:
So I go back to my previous statement that we should have standards of practice the same as all the other professions have.
I wouldnt assume this for every and each programmer. For me, programming is a form of art, and standards do not apply to me automatically, unless they are good and useful. I have yet to see a standard like this. Even ID softwares code, whom many consider really professional coders, looks crap, with all the macro bullshit and C style chaos. .NET is indeed a step forward from all that stuff.
I agree with you on everything else you said though.
-
Re: Win32 API future ...?
Here is a thread which deals with more of what m$ has in store for us and .net: http://www.codeguru.com/forum/showthread.php?t=338407
-
Re: Win32 API future ...?
Well, I think thats an interesting concept, but what advantage would subscription applications have over desktop applications?
-
Re: Win32 API future ...?
Quote:
Originally Posted by Ben_Phillips
Well, I think thats an interesting concept, but what advantage would subscription applications have over desktop applications?
No actual advantage from my point of view, but .net developers will cry for some way to sell their apps and not have them stolen, which they can't do if distributed.