|
Hi,
I just read from the article "What Is A Framework?" that a wrapper for Visio COM Object is developed.
Can I know If I can get that somewhere, if it is available as a free-source?
Thanks,
Ravi.
|
|
|
|
|
The real problem tends to be "time". If programmers were given more time to complete tasks: secure, stable, faster code would be produced.
Introducing "safer programming environments" also creates a problem. Anyone who has used the .net framework (especially Managed VC++), will know that your applications run slower than native code.
Microsoft will admit this aswell. So you must decide as a developer: Do I want faster code, which maybe less stable? or Do I want stable code which is slower?
The result should be based on your current project's target. This poll is too broad. I feel the real problem is time and the target. 
|
|
|
|
|
I do not beleive this is possible these days.
When I first started programming, the programmer was 100% responsable. Today however, we are dependent on DLLs, manufactured supplied hardward drives, etc...
These are good things, but they take full control out of our hands.
INTP
|
|
|
|
|
My stand is that a programmer should be responsible, as long as the programming environment allows for a secure and bug-free application to be developed. In most programming environment, this is the case. However, a friendly environment always help, so I voted the 2nd.
On the other hand though, an extremely 'open' programming envioronment will make it hard for a programmer to write secure code. Only a total understanding of it can allow for a secure application, which is, rather hard to come by these days as more and more people takes up programming because 'it is cool' [take for example VB].
Recently I read the Scarlet File for PHP @ http://www.fsix.net/files/studyinscarlet.txt[^]. I like to quote the last paragraph which is related to the survey:
A lot of people blame programmer's for the code they write, I personally feel that if a language makes it hard for a programmer to write good code (particularly by being counterintuitive) the language must itself take some of the blame for the situation. It's not good enough to just say the programmer should know better. In almost every PHP application I've audited the programmer's have _tried_ to get it right and only been let down by their understanding of the intricacies of PHP. In its search for the ultimate functionality PHP has undermined the programmer's ability to understand the workings of their code in all situations.
Whats your take?
|
|
|
|
|
I would like to point the direction a bit more to the language level, because this is the typical place for such discussions. Java, for instance, dismissed everything from the language that might be misused or might be dangerous: Operator overloading, multiple inheritance, const correctness, goto, templates, ...
I know that a lot of people think this is the way to go. Too many bad experiences with C++. However, there are also a lot of professionals who really miss some expressive power in Java. I really wonder why the software development community tends to favor "idiot-proof" tools and dooms everything that is not idiot-proof 
I mean, the goal should be to do not let idiots write programs, shouldn't it? People need to be trained to write programs! Nobody forbids a carpenter to use chainsaw just because a recruit may hurt itself by using it. Instead of, the recuit is carefully trained when and how to use it. So why the hell do we believe in substituting education with tools in software development?
I vote pro the expressive power of C++ and well educated software developers 
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there  )
|
|
|
|
|
Amen.
"If you create it, delete it."
|
|
|
|
|
Daniel Lohmann wrote:
Nobody forbids a carpenter to use chainsaw just because a recruit may hurt itself by using it. Instead of, the recuit is carefully trained when and how to use it. So why the hell do we believe in substituting education with tools in software development?
Never a true word!![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Daniel Lohmann wrote:
vote pro the expressive power of C++ and well educated software developers
And you also have my vote
|
|
|
|
|
Daniel Lohmann wrote:
I mean, the goal should be to do not let idiots write programs, shouldn't it? People need to be trained to write programs! Nobody forbids a carpenter to use chainsaw just because a recruit may hurt itself by using it. Instead of, the recuit is carefully trained when and how to use it. So why the hell do we believe in substituting education with tools in software development?
Teaching someone how to use a tool is one thing. Teaching a person how to solve problems, analyze possible solutions, reason deductively and inductively, use intuition appropriately, strive for improvement, put some of their soul into their work...
those things can't be taught. Those things come from within, not from some textbook or training course. And those of us that do know how to apply tools appropriately, put our soul into our work, know how to think and solve problems, and strive for improvement, well, speaking for myself, I don't want my work screwed up by those who don't.
And that's why I enforce a rigid framework on myself and the people on my team. If you don't like, well, let me show you the door. For those that stick around, the response I get from all of them without exception is: "this has totally changed my ideas on how programming should be done". I think this goes a long way to validating my rather harsh words. Thank goodness I'm not a running for political office!
(On the other hand, while people I've worked with "see the light", the second response is, now how the hell can I possibly apply any of this in my next job, where they're so regimented in their thinking". Just goes to show that there's a downside also.)
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
 Define idiot. You will find multiple definitions. A "PROJECT" consists of the stuff required to accomplish some "GOAL". Most projects fail because everyone has a different view of the "GOAL". Additionally the goal can slip because the it always changes in some fashion some way and so on
Enforceing a rigid framework only works in the short term (which is also open to debate) such as 2 years or less. Anything over that and the project progress slows down implementation is delayed. Any project 2 years and over is already no longer of use since goals change (which they should) over time.
Many projects also fail because they cannot adapt to change. Projects should be setup to handle change in a viable way NOT attempt to repress it.
However you are correct in that if you cannot handle change don't. In your case apply a rigid framework.
You say everyone agrees with you "without exception" tells me that long term projects are not your forte:. No problem, I will not hire you for them.
However I do agree for the short term "NO CHANGES ALLOWED". With that in place projects can be delivered on time and under budget.
Managing projects requires one to know when to be flexible and when not to.
Seems to me you have the first part of that down pat.
Anson Chapman
|
|
|
|
|
"Is it better to have the developer or the underlying framework the developer targets be responsible for catching bugs and security issues?"
Obviously, the end customer rarely cares what framework a developer uses, so the developer is responsible for the final product including whatever 3rd party code he/she used.
That is not the end of the story for us developers, though. Software is becoming exceedingly more complex as the years go by, and much of the complexity is being hidden by frameworks like .NET (or AAL for Marc Clifton). The frameworks sure-as-hell better work right if the final application is going to work right. MS (or Marc Clifton) must be responsible for their code at some level, but typically not the level we developers have any influence over. Often framework decisions are made by non-developers or people without enough experience or time to fully evaluate them first.
I answered 3 to the poll. 5 is a noble idea, but a flawed one, because many bugs are not technical and the bugs customers care about most are often business-logic related, not really code related. What is a bug after all?
Software will always require someone with a brain to make intelligent decisions as to how to make things work, when and where and what frameworks to use or avoid. Frameworks exist to make our applications more feature rich, ideally with less code, but not with less intelligence.
|
|
|
|
|
Matt Gullett wrote:
5 is a noble idea, but a flawed one, because many bugs are not technical and the bugs customers care about most are often business-logic related, not really code related.
An absolutely excellent point.
From my own myopic experiences, my customers care about one more thing--the application needs to be flexible to handle their continually changing requirements, and they don't want to spend an arm and a leg (again) on rewriting it because it can't be grown and extended (as in, it's cheaper to rewrite it than to force it).
I was in that situation once, and once was enough, about 15 years ago. It caused me to completely re-evaluate the software development process, the available tools, and the direction of the industry. It taught me several very important lessons which evolved into the AAL over time. Sure, we're now looking at Longhorn and .NET instead of DOS and TurboC, but the lessons learned 15 years ago seem to be even more relevant today. Certainly, changes in technology haven't done much to address the root causes.
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
The only conclusion I can make is that relying on programmers not to make misstakes obviously doesn't work perfectly because people aren't perfect. Because we can't write perfect code we will never achive No5. The best thing we can do is to make it as easy as possible for most of the programmers to get as far from No1 as possible.
|
|
|
|
|
Aren't the frameworks written by humans? So putting your trust in the framework is just a lazy act or is just an oppertunity to blame stupid mistakes on other people/framework!
Trust no 1;)
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
to vote for the last option: "The underlying framework should handle all bugs and holes gracefully", or at least, one of the few.
Not only should the framework handle bugs and holes gracefully, it should enforce good design and implementation practices. There's lots of room for creativity in a project, but there are some things that should NOT be designed or coded except by the most experienced people.
Sadly, I don't think most people really understand how powerful and useful a good framework can really be, both in terms of helping projects be flexible to change, and in managing the code quality that programmers of varying levels of expertise produce. Yes, a good framework can do that. And I'm not talking about API wrappers like MFC and .NET. Those are not frameworks, even if we call them frameworks in everyday parlance.
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
I'm with you. Good design should encourage good design, enforcing it if at all possible. That's the basis of great language stuff like type safety... I'll never forget being told by a VB programmer that variant types make for great code, because they let you be so flexible. I was coding in LotusScript at the time, a language that was basically VB with proprietary extensions. A newbie at the time, I thought this guy's advice made a lot of sense, and started removing all type safety from my programs! I spent some hair-raising nights debugging my code in those days, all the while content that when I was done debugging everything, I'd really have finished a masterwork. A little learning is a dangerous thing.
I don't understand what the question means by "handle bugs and holes gracefully". I think that a framework should lead to the airing those sorts of problems as soon as possible, not hiding them. If that's what graceful handling is, I'm all for it. If it's hiding bugs as long as possible, it doesn't make much sense.
Thank you.
Jeff Varszegi
|
|
|
|
|
So sad... I was assigned to maintain seom VB projects a while ago.
The VB programmer only use variant for all diffeent type of variables. You may already see what happened... it's a disaster.
If I can find a job, I will quit immediately. I have learned a lesson that most of great-vb-programmers are vbasicER.
A good framework should enforce good design.
|
|
|
|
|
In a perfect world, I would have voted 5 as well. But there is no framework that I know of that checks errors this good. Even the best developers make mistakes once in a while, or fail to check for a bad parameter here and there. The biggest problem is the unexpected... the framework could be used in ways its designers never anticipate, and so bugs can slip through the most rigorous test process.
So for that reason, I voted 3 - both have the responsibility.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
Marc Clifton wrote:
Not only should the framework handle bugs and holes gracefully
I would like to see this thing - but we'd probably wait ages until this thing is actually bug-free.
Marc Clifton wrote:
it should enforce good design and implementation practices
Support, IMO, not enforce.
"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."
mlog || Agile Programming | doxygen
|
|
|
|
|
What is a framework then?
regards,
Paul Watson
Bluegrass
South Africa
Marc Clifton wrote:
"organically fed captivity free regurgitated bee nectar" (honey) on dieting.
Crikey! ain't life grand?
|
|
|
|
|
|
I also voted for the final option, although I believe it is a very elusive goal. Obviously, programming should be made as efficient and productive as possible by the tools we use, with the ultimate goal to make the programmer obsolete. The ideal world would be one where the end user could easily and reliable generate programs of any complexity on demand as they need them. Such an ideal state, however, will be very long in coming, if at all.
People have been talking of such a situation since at least the early '80's ( when I first became aware of it), and we are as far from it now as we were then, if not further.
|
|
|
|
|
Stan Shannon wrote:
[...] the ultimate goal to make the programmer obsolete
I don't think we'll be able to replace the programmers until we'll have a real thinking machine...
Until then, you might want to check out Fred Brook's No Silver Bullet[^]. (It was also published, along with a review, in the 20th anniversary edition of The Mythical Man-Month[^].)
Florin Crisan
|
|
|
|
|
The programmer can be obsolete as long as it's about 15-20years time, but then i'd of retired. ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
Saying that future program development maybe become obsolete, but lets face it there's 1,000,000's of lines of code in C,C++ using Win32,MFC that need maintaining to keep me job for a loooooong while. :cash:
Stroll on .net v4.0 - The user becomes the programmer and by that time software will become rather uninteresting to write/use. 
|
|
|
|
|
The framework is a piece of software too. If all developers are responsible for their code (which I think they should be) then the framework developers should make their framework as bug-free and secure as possible and I should make my app as bug-free and secure as possible. Both of us will probably make mistakes.
However, my app is going to used by my client and their framework will (probably) be used by large portions of the developer community. Unless my app is mission critical (e.g. lives or serious money will be lost if it's buggy) I'd say that the framework developers have a greater responsibility since more people will depend on their code.
|
|
|
|
|
the programmer is 100% responsible for his code , the final application among with all of the code involved is the application the client will get.
though i beleive software should be fully free, if we take the example of commercial software , the client dont pay for the application and framework used seperately , he pays for the whole thing. any bugs that will arise , the complains will be to the programmers. THE FRAMEWORK IS JUST A SHORTCUT THE PROGRAMMER USE TO MAKE HIS LIFE EASIER...BUT ANY ADVANTAGE HAS ITS DISADVANTAGE , SO HE SHOULD BE RESPONSIBLE FOR HIS ACTIONS...NO MATTER WHAT FRAMEWORK YOU WILL CHOOSE , ITS THE UNDERLINING EXE (WITH THE FRAMEWORK) THAT COUNTS...AND ITS YOUR RESPONSIBLE.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
