More thoughts on the acceptance of .Net
-
With all the recent conversations about .Net, VC++, VB and the future of different languages, a thought struck me this morning as I was browsing through some of the code postings here at CodeProject. A lot of the articles present excellent, well written classes that will save other developer's a lot of effort and that is very worthy. However a lot of these articles start off with lines similar to this. To use this class in a project, add the .CPP and the .H files to your project and away you go. While there is absolutely nothing wrong with this, it highlights that we as developers here are sharing code at a *SOURCE* code level. Doesn't anyone build a DLL to export these classes? Or doesn't anyone wrap up these classes in a DLL and expose a set of interfaces to them? And if some of us do, why not post this source as well? I apologize if that sounds critical, because I don't mean it to be. But it strikes me that if we as developers are still sharing our code all at a source level, all of these other technologies such as COM, COM+ and perhaps by inference .Net still have a long way to go, before ever being accepted and put into general use. I also realize that this site is dedicated to sharing code and so I'm not surprised that a lot of source is available. It is just the manner of it's suggested implementation that strikes me as why all these other technologies have a long way to go. Comments welcomed and no I'm not always this serious ;) Chris
Take for example a small collection of MFC classes. I can't tell upfront how the ones who use the code will want it built. Only considering the combinations of how MFC is linked (shared DLLs or static), ASCII vs UNICODE, and if my code is going to be statically linked or used as a separate DLL, I already have to provide 8 .lib and 4 .dll files and still tell the user: "to use this class in a project, add the .h files to your project". And I didn't even take into account the pieces of the code which can be conditionally compiled using preprocessor defines. The "users" of the code are developers, so they should be able to build the dll themselves if so they wish. [update] Maybe i didn't counted up right all the basic combinations, but I forgot to add one important thing - both release and debug versions would be nice, so the numbers must be doubled. The sigs are useful and important.
-
With all the recent conversations about .Net, VC++, VB and the future of different languages, a thought struck me this morning as I was browsing through some of the code postings here at CodeProject. A lot of the articles present excellent, well written classes that will save other developer's a lot of effort and that is very worthy. However a lot of these articles start off with lines similar to this. To use this class in a project, add the .CPP and the .H files to your project and away you go. While there is absolutely nothing wrong with this, it highlights that we as developers here are sharing code at a *SOURCE* code level. Doesn't anyone build a DLL to export these classes? Or doesn't anyone wrap up these classes in a DLL and expose a set of interfaces to them? And if some of us do, why not post this source as well? I apologize if that sounds critical, because I don't mean it to be. But it strikes me that if we as developers are still sharing our code all at a source level, all of these other technologies such as COM, COM+ and perhaps by inference .Net still have a long way to go, before ever being accepted and put into general use. I also realize that this site is dedicated to sharing code and so I'm not surprised that a lot of source is available. It is just the manner of it's suggested implementation that strikes me as why all these other technologies have a long way to go. Comments welcomed and no I'm not always this serious ;) Chris
I'm more of a fan of the souce rather than a just the DLL, as for one, I can see whats been done with the source and learn from it. As well as that for the size of the sample code supplied on CP, I prefer to use the code as a static library. I really hate the use of DLL's that don't contain a huge amout, when all I want is the class. Finnally, with the source, I can trust it. Its got no dodgy code that doinf thing it should not e.g. virus code. I see VB web sites with example code and - "Hey you have to use my half assed DLL/OCX" etc, and "I won't give you the code for it". What they don't tell you is that its incompatible with NT4 SP5, because they don't know themselves because they are f@!$wits. The nice thing about CP and the code submital is that, its like a peer review of your coding. Nothing bitchy just good advice, on where you can make stuff more robust. There are a lot of smart people willing to help you out giving good advice. Giles
-
I agree with you that its just a tool, I just have nightmares about some of the situations that I think .Net can create. Most of those are releated to the overcomponitization of normal applications. One of the good things about COM is that it can be challenging for the uninitiated. Once the challenge is gone, the bar gets lowered and as a result the quality of components that are going to invade the world are going to drop (I don't believe that .Net will have that much of an effect outside the corporate inter/extranet). Think about some of the object oriented programs you've probably seen. Do I really need 15 objects with several methods each, simply for the sake of fitting some sort of design philosiphy? Do I really need 15 badly written business assemblies or one monothlithic and disposable application. Currently I vote for the latter. On the positive side, I'm all for dumping the windows API and starting anew (mostly). Dump, dump, dump. Send that thing down the crapper. Ritch PS- Have you ever had to reverse engineer a java program? I was a consulant for Transamerica Occidental Life when they were aquired in a merger. As a result of the merger the employees I was working with were "phased out". In a fit of last day hijinks, the java guy decided we didn't his source code and walked away with it. Needless to say, that piece was rewritten. Blah!
> One of the good things about COM is that it can be challenging > for the uninitiated. I have mixed feelings about this, but it's interesting point of view :) > I don't believe that .Net will have that much of an effect > outside the corporate inter/extranet Agreed. .Net doesn't help you much when you create rich-GUI desktop apps for wide distribution. Tomasz Sowinski -- http://www.shooltz.com.pl
-
While having a pre-built component/DLL is nice to have, I will always appreciate having the source code available. I like to take things apart and put them back together and I think having access to the source satisfies that part of my nature. :) Secondly, looking at how someone else has coded a particular problem is always instructive as it presents you with a method that you may not have thought of. I can't count how many times I've looked at some code and thought, "Wow, that's a good way of doing it. I think I'll incorporate that into my bag of tricks." I've come across two types of programmer's lately, which I'll call The Architect and The Carpenter (no offense against these professions). The Architects are able to think about the big picture, talk about why a certain algorithm is better than another, why something should be done a certain way and write a good spec (and code well, -- ok sometimes they code well). This type loves to delve into the source. The Carpenter (and there are far too many of them lately) likes to use the stick modules together with some kind of glue method and doesn't really understand why Quicksort may not always be the best sort algorithm to use. ( OK we all know that VB has its fair share of Carpenters :-D ) The point I'm trying to make is that I'm all for making life easier IF you understand the basic concepts of program design as well as the pros and cons of various programming methods in various situations. Unfortunately what seems to happen when you make something easier to use is that the people who use it, with a few exceptions, understand less about what's really happening. -Sean (Lizard King) ;P
The difference between your Architect and Carpenter is one of professional maturity. The whole point of component based and object oriented design is to not waste your valuable effort on reinventing the wheel. If you compose your solution of well architected components you can quickly develop a complex, robust solution. The source code on CP is for wheel development. And that is not a bad thing, gadget junkies and watchmakers are necessary and valuable. But, if you can quickly build a distributed application with a custom front end in weeks with components and scripting versus months with custom toolbars and custom network code and custom server code, which one are you going to choose? One of the failings (or marketing decisions) of MS is that they did not make VC++ visual enough. A VC6 with the simplicity of the VB6 interface and build tools would have been an extremely powerful tool. -John
-
The difference between your Architect and Carpenter is one of professional maturity. The whole point of component based and object oriented design is to not waste your valuable effort on reinventing the wheel. If you compose your solution of well architected components you can quickly develop a complex, robust solution. The source code on CP is for wheel development. And that is not a bad thing, gadget junkies and watchmakers are necessary and valuable. But, if you can quickly build a distributed application with a custom front end in weeks with components and scripting versus months with custom toolbars and custom network code and custom server code, which one are you going to choose? One of the failings (or marketing decisions) of MS is that they did not make VC++ visual enough. A VC6 with the simplicity of the VB6 interface and build tools would have been an extremely powerful tool. -John
Nice perspective. I'll agree with you here 100%. As I said, I'm all for making things easier, as long as we maintain a grasp on the fundamentals. -- One of the failings (or marketing decisions) of MS is that they did not make VC++ visual enough. A VC6 with the simplicity of the VB6 interface and build tools would have been an extremely powerful tool. I'll certainly agree with you here, I've often wondered why some things in VC6 couldn't have been done as easily as using the dialog editor. Maybe that's one of the design goals of C#. -Sean (Lizard King) ;P
-
The difference between your Architect and Carpenter is one of professional maturity. The whole point of component based and object oriented design is to not waste your valuable effort on reinventing the wheel. If you compose your solution of well architected components you can quickly develop a complex, robust solution. The source code on CP is for wheel development. And that is not a bad thing, gadget junkies and watchmakers are necessary and valuable. But, if you can quickly build a distributed application with a custom front end in weeks with components and scripting versus months with custom toolbars and custom network code and custom server code, which one are you going to choose? One of the failings (or marketing decisions) of MS is that they did not make VC++ visual enough. A VC6 with the simplicity of the VB6 interface and build tools would have been an extremely powerful tool. -John
A VC6 with the simplicity of the VB6 interface and build tools would have been an extremely powerful tool. ...for people to write VB-style apps with! (use your Triumph the insult puppet dog voice here) "Reinventing the wheel" assumes we all need the same kind of wheel - we don't. Every project has different performance, UI and size constraints and a set of canned components are rarely going to be able to meet all of these. Proponents of component-based development ignore the fact that you don't build cars from off-the-shelf parts; most of the parts in a car are designed specifically for that car. They are built using techniques that apply to all (or most) cars, but are tailored to to the specific needs of the product. On the other hand, if you are trying to save development cost (at the expense of final performance) you might be tempted to use black-box, off the-shelf components. You'll get something up and running, quickly, maybe. But, your final product is going to be more of a go-cart: welded together from stuff you found lying around in the backyard; many of the connections between the parts are going to be ugly, the paint won't match and you'll be lucky if it steers straight. :) -c ------------------------------ Smaller Animals Software, Inc. http://www.smalleranimals.com
-
A VC6 with the simplicity of the VB6 interface and build tools would have been an extremely powerful tool. ...for people to write VB-style apps with! (use your Triumph the insult puppet dog voice here) "Reinventing the wheel" assumes we all need the same kind of wheel - we don't. Every project has different performance, UI and size constraints and a set of canned components are rarely going to be able to meet all of these. Proponents of component-based development ignore the fact that you don't build cars from off-the-shelf parts; most of the parts in a car are designed specifically for that car. They are built using techniques that apply to all (or most) cars, but are tailored to to the specific needs of the product. On the other hand, if you are trying to save development cost (at the expense of final performance) you might be tempted to use black-box, off the-shelf components. You'll get something up and running, quickly, maybe. But, your final product is going to be more of a go-cart: welded together from stuff you found lying around in the backyard; many of the connections between the parts are going to be ugly, the paint won't match and you'll be lucky if it steers straight. :) -c ------------------------------ Smaller Animals Software, Inc. http://www.smalleranimals.com
I agree with you, Chris (and totally dig Triumph: "You know you want it, you whore!"). But, that is what .net directly addresses; with the extremely robust class libraries and multi-language OO and component base programming principles AND with a negligible performance hit, the difference is no longer between a porsche and a go-cart, but more between a high-end porsche and a low-end porsche. Keep in mind that the first goal of .net is internet, distributed programming. RAD development, robust, go-cart development can now produce applications that can almost stand up to the hand-crafted masterworks produced by the coders here on the CP. ;P This thread has pointed out the focus of it's participants. I am a corporate programmer: my job's main goal is not to produce the most elegant solution, but to produce the most politically viable, useful applications where the major constraint on the product is programming time. Many of the CP ladies and gents (I believe) are hobbyist, self employed or small shop coders where the emphasis is more on the elegance and craftsmanship of the finished product. Note that I am not saying that corporate programming is low quality programming, or that there is no elegance or craftsmanship in the corporate world. The priorities are different. I don't agree with the statement (stated elsewhere on this thread) that .net will be only relegated to the corporate world. I am sure that the environment will have out-of-the-box support in the dominant operating system on planet earth at some point. And the barrier to entry of distributed internet programming will be radically lowered. SOAP and Web-Services are not just for web pages. Games, communication applications. (Chat, voice, IM, multimedia), collaboration and messaging apps are just the tip of the iceberg.) (I could rant on about this for awhile, but you see where I am going... The tech excites me, I am looking forward to working with it. Peace...) :cool: -John
-
With all the recent conversations about .Net, VC++, VB and the future of different languages, a thought struck me this morning as I was browsing through some of the code postings here at CodeProject. A lot of the articles present excellent, well written classes that will save other developer's a lot of effort and that is very worthy. However a lot of these articles start off with lines similar to this. To use this class in a project, add the .CPP and the .H files to your project and away you go. While there is absolutely nothing wrong with this, it highlights that we as developers here are sharing code at a *SOURCE* code level. Doesn't anyone build a DLL to export these classes? Or doesn't anyone wrap up these classes in a DLL and expose a set of interfaces to them? And if some of us do, why not post this source as well? I apologize if that sounds critical, because I don't mean it to be. But it strikes me that if we as developers are still sharing our code all at a source level, all of these other technologies such as COM, COM+ and perhaps by inference .Net still have a long way to go, before ever being accepted and put into general use. I also realize that this site is dedicated to sharing code and so I'm not surprised that a lot of source is available. It is just the manner of it's suggested implementation that strikes me as why all these other technologies have a long way to go. Comments welcomed and no I'm not always this serious ;) Chris
The main reason I like source code instead of binaries (for forums such as CodeProject) is because many of the components are not fully developed. Tons of them have been written for a specific purpose and then sent in as a "I hope this helps someone". This is really, really cool. I also like to look at the code to see how things are done, and I think this goes for many people who use this site. If submissions were purely DLL's or ActiveX controls then usage is limited. Not everyone wants to write their apps as COM clients, or deal with DLL libraries. I think the points you brought up about components are part of the reason MS (and many developers) see .NET as such a Good Thing. With .NET we can send in our C++ or C# code and use these as we currently are. Or, someone can send in a C++ or C# assembly and we can slap a '#using' statement and use it immediately, or we can derive our own classes from the classes in the assembly and customise the component to our liking without resorting to wrappers and workarounds. OR A VB developer can post a component and we can again derive our C++ or C# classes from it and use it in our apps as simply as using any other class. It's all good :) cheers, Chris Maunder
-
With all the recent conversations about .Net, VC++, VB and the future of different languages, a thought struck me this morning as I was browsing through some of the code postings here at CodeProject. A lot of the articles present excellent, well written classes that will save other developer's a lot of effort and that is very worthy. However a lot of these articles start off with lines similar to this. To use this class in a project, add the .CPP and the .H files to your project and away you go. While there is absolutely nothing wrong with this, it highlights that we as developers here are sharing code at a *SOURCE* code level. Doesn't anyone build a DLL to export these classes? Or doesn't anyone wrap up these classes in a DLL and expose a set of interfaces to them? And if some of us do, why not post this source as well? I apologize if that sounds critical, because I don't mean it to be. But it strikes me that if we as developers are still sharing our code all at a source level, all of these other technologies such as COM, COM+ and perhaps by inference .Net still have a long way to go, before ever being accepted and put into general use. I also realize that this site is dedicated to sharing code and so I'm not surprised that a lot of source is available. It is just the manner of it's suggested implementation that strikes me as why all these other technologies have a long way to go. Comments welcomed and no I'm not always this serious ;) Chris
You're absolutely right. I don't like putting other peoples code into my project verbatim, but I have used several things from Code Project. I like to look through them, learn how they do something and then impliment it. I don't think there are any things I got from here that did *exactly* what I wanted, but several times this site has given me a push in the right direction, and has been invaluable to me. Another example: I found a library yesterday that does some of the image processing stuff that I want to get into my program ( swirl type filters mainly ), but I won't use it because even though it is free, I need to interface with ( and ship ) a dll. I want to know how to do this stuff, not use someone elses code verbatim, with no chance to modify or just learn from what they did !!! Christian I've learned that you cannot make someone love you. All you can do is stalk them and hope they panic and give in. The early bird may get the worm, but it's the second mouse that gets the cheese.
-
I agree with you, Chris (and totally dig Triumph: "You know you want it, you whore!"). But, that is what .net directly addresses; with the extremely robust class libraries and multi-language OO and component base programming principles AND with a negligible performance hit, the difference is no longer between a porsche and a go-cart, but more between a high-end porsche and a low-end porsche. Keep in mind that the first goal of .net is internet, distributed programming. RAD development, robust, go-cart development can now produce applications that can almost stand up to the hand-crafted masterworks produced by the coders here on the CP. ;P This thread has pointed out the focus of it's participants. I am a corporate programmer: my job's main goal is not to produce the most elegant solution, but to produce the most politically viable, useful applications where the major constraint on the product is programming time. Many of the CP ladies and gents (I believe) are hobbyist, self employed or small shop coders where the emphasis is more on the elegance and craftsmanship of the finished product. Note that I am not saying that corporate programming is low quality programming, or that there is no elegance or craftsmanship in the corporate world. The priorities are different. I don't agree with the statement (stated elsewhere on this thread) that .net will be only relegated to the corporate world. I am sure that the environment will have out-of-the-box support in the dominant operating system on planet earth at some point. And the barrier to entry of distributed internet programming will be radically lowered. SOAP and Web-Services are not just for web pages. Games, communication applications. (Chat, voice, IM, multimedia), collaboration and messaging apps are just the tip of the iceberg.) (I could rant on about this for awhile, but you see where I am going... The tech excites me, I am looking forward to working with it. Peace...) :cool: -John
This thread has pointed out the focus of it's participants. I am a corporate programmer: my job's main goal is not to produce the most elegant solution, but to produce the most politically viable, useful applications where the major constraint on the product is programming time. Many of the CP ladies and gents (I believe) are hobbyist, self employed or small shop coders where the emphasis is more on the elegance and craftsmanship of the finished product. sorry but when you say small shop you are referring to the size of the development company ... which is correct for us and others i suspect but the clients we service (hsbc, merril lynch, deutche bank, etc) are certainly not and they expect the same rules to be followed by us as by the didata's and ibm's of this world if that is the centre-piece of your argument i have to repsectfully disagree with you :suss: --- "every year we invent better idiot proof systems and every year they invent better idiots"
-
MS wants us to believe that future programmers will just stick modules together with some kind of MS-provided glue (COM, OCX, DLL, .NET). But no matter how much MS wants us to fall into their latest linked-components paradigm, programmers really seem to prefer having the whole source right in front of them. or... what you said :) -c ------------------------------ Smaller Animals Software, Inc. http://www.smalleranimals.com
Components are great when they are defect free. The first time you have a problem that requires you to go back to the vendor, they become a time sink. There's a lot to be said for having the source code. Even with system DLL's, the documentation is often so inadequate that having the source code would be preferable.
-
This thread has pointed out the focus of it's participants. I am a corporate programmer: my job's main goal is not to produce the most elegant solution, but to produce the most politically viable, useful applications where the major constraint on the product is programming time. Many of the CP ladies and gents (I believe) are hobbyist, self employed or small shop coders where the emphasis is more on the elegance and craftsmanship of the finished product. sorry but when you say small shop you are referring to the size of the development company ... which is correct for us and others i suspect but the clients we service (hsbc, merril lynch, deutche bank, etc) are certainly not and they expect the same rules to be followed by us as by the didata's and ibm's of this world if that is the centre-piece of your argument i have to repsectfully disagree with you :suss: --- "every year we invent better idiot proof systems and every year they invent better idiots"
I guess it really depends on how you define 'elegant'. My personal definition of elegance is that the product has ascertained, and implemented a solution to the problems of a particular customer need. The customer should be able to interact with the solution in a way that is (or becomes) completely natural, with a minimum of development effort expended. The solution should be easy to refactor and extend in the future, as a result of clarity of design, no matter how crufty or complex some parts of that implementation may be. What about others? Matthew Adams Development Manager Digital Healthcare Ltd