|
And then God created .NET and the Common Language Runtime and saw that they were good. He said "Be fruitful and Multiply" And he sayeth further, "Thou shalt be open with thy source code, for it is useful."
It's good to see kids turning their minds to wholesum activities such as programming, instead of wasting their lives in the hedonistic disciplines of Sex, Drugs, & Rock & Roll... or Sex with Drugs, or Sex with Rocks while Rolling in Drugs, or whatever new-fangled perversions you little monsters have thought up now...
[Shog9 on Kid Programmers]
|
|
|
|
|
Or just because you want to change it... not to say to fix the bugs they made 
|
|
|
|
|
I agree - being dependent on any kind of 3rd party component without having the source is just plain dangerous. Especially if the company goes out of business... or changes its component dramatically... or you simply want to be able to debug and/or change your stuff...
Even a broken clock is right twice a day.
|
|
|
|
|
George wrote:
With the amount of the spy-ware we have nowadays I only trust and use the components that come with the source code
What about things like the .NET Framework and how did you react to MFC and ATL (or is it WTL? not sure...  ) when they came out?
Isn't it more about trust than the "only use if source code available" rule?
I know I happily dove into the .NET Framework (which is one big set of components right?) but balked a bit when asked to use a simple Dundas* control.
* Only because coming from a web dev and VB background my exposure to Dundas has been minimal
|
|
|
|
|
Paul Watson wrote:
What about things like the .NET Framework and how did you react to MFC and ATL (or is it WTL? not sure... ) when they came out?
You are mistaking the frameworks and the components here. .NET is not a third party component by any means. It is a first party product and out of the scope of this poll.
Anyhow, MFC when it first come out was a great piece of engineering and it managed easily to put Borland out of business. It is still a great library, and it actually does come with full source code.
<center> </center>
|
|
|
|
|
George wrote:
You are mistaking the frameworks and the components here. .NET is not a third party component by any means.
The .NET Framework is essentially a set of components made my Microsoft, a 3rd party
Obviously I am not talking about IL, GC etc. etc. But System.Xml, System.Data, System.FUBAR etc. are all collections of code which can be re-used as needed, just like a 3rd party component.
Also currently the .NET Framwork is treated much as a 3rd party component with many of our clients. A: They do not want it on their hosting server until all the bugs are out and B: They are afraid that if we go bang and have developed a .NET app then they will not be able to easily find a developer who knows .NET to maintain and extend the solution. Same story with 3rd party components.
Also if you consider that any properly made piece of code I do in .NET is as "valid" and "real" as a Microsoft class/struct/whatever then what is the diff.?
Anyway so that is what I was getting at. That the issue is not source code but trust. We treat collections of code from Microsoft differently to how we treat it from other 3rd parties, like Dundas. The .NET Framework classes are just a bigger collection of components than we normally handle and we treat it more as a system.
That is why I asked about MFC and ATL etc.
George wrote:
It is still a great library, and it actually does come with full source code.
What if source code was not available for MFC? Would it's adoption have been as thorough?
|
|
|
|
|
Paul Watson wrote:
What if source code was not available for MFC? Would it's adoption have been as thorough?
Probably not. I know I (and I'm sure many other developers did, too) thought the best thing about MFC was that it came with full source code. That is invaluable when trying to debug - even if it is your piece of code that's breaking, sometimes you just have to see what's going on inside to get a good grasp of the situation.
Then there is also "code cloning"... maybe you see an MFC class that does almost what you want, but not quite, so you have to copy-and-paste to do what you need. Though if component developers design their components better, the need for doing this kind of thing is minimized.
One of the biggest disadvantages of .NET is that you don't get the source to all the common stuff. It is no better than the Win32 API in that regard... you do something, it is pretty much a black hole. If something happens that you don't expect, good luck figuring out what's going on.
Given a choice between component X and component Y that both can do what I need, I'll take the one with full source, thank you.
Even a broken clock is right twice a day.
|
|
|
|
|
Paul Watson wrote:
The .NET Framework is essentially a set of components made my Microsoft, a 3rd party
A third-party component, as I understand it, is a single piece of code that can exist on its own in a particular environment and which comes as such component. .NET Framework is an environment in which you can plant a third party components. Framework might be build from the set of components, but since it exists and makes sense only as a set or its large part it can't be called a third-party one. You don't buy these separately, they all come together as a package, a framework.
Paul Watson wrote:
Anyway so that is what I was getting at. That the issue is not source code but trust. We treat collections of code from Microsoft differently to how we treat it from other 3rd parties, like Dundas.
If I have the source code I don't have to trust any more - because I, and many others, can verify what's going on in the component. That makes the whole difference!
Also, while we are at it - my trust to Microsoft is close to zero recently and going down each day. When MFC first came out it was the whole different company making a great products. Now it's just a greedy bastard trying to take over the world 
Paul Watson wrote:
What if source code was not available for MFC? Would it's adoption have been as thorough?
We will never know for sure, there was many factors that helped MFC to become popular. One of which was the clumsiness of the competitors like Borland. When they were starting with OWL it was not so sure which framework would prevail. But Borland made a few strategic mistakes and so MFC has won in the long run. At the same time MS provided a great development environment and it all "clicked" together. I am not sure about the .NET thought because it seems like MS is pushing it too hard. From the Visual C++ perspective it's a huge step back and many people upgraded from VC70 back to VC60 already. I am seriously considering to move to another compiler, like Intel's for example. It's a very good product and quite cheap in comparison with VS.NET. Call it a third-party compiler
<center> </center>
|
|
|
|
|
The problem is that software editors generally hesitate to divulge the source code, especially if it is the result of several years of development.
|
|
|
|
|
You need several years to earn $500?
If this is a question of money, then the less expensive choice is to purchase the component, because if you develop it yourself, the price will be 100 times more expensive. Ok, in such a case, you would have the source code... which is perfectly useless in 99% of the cases!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
