Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Framework comparison
Message
General information
Forum:
Visual FoxPro
Category:
Third party products
Miscellaneous
Thread ID:
00140875
Message ID:
00141123
Views:
33
Where to begin...

1) I use OOP because it helps me create better apps quicker. That's the bottom line, isn't it? OOP accomplishes this pimarily via encapsulation (reducing bugs) and reuse (reducing development time). In both cases, it makes sense for me to use as much of OPC (Other People's Code) as possible. The more I let other people write and debug my app's code, the more time I have to spend on the client's individual needs, that no one but me can adequately address. So the argument that "my client is different from all the others" is an argument in favor of using a framework, not against it.

2) Since I am a superb programmer <s>, the best framework is one that I write myself, no question. Now let's see; how long would it take me to write an excellent framework? I'll guess a year, all told. I'm sure that any other framework represents at least that much work-time. Do I have a year to spare (actually, I do, and I'll get to that)? Most of us, if asked, would have to answer no. Am I in the business of writing apps or writing frameworks? I don't think most of us have time to do both well.

3) But even if I take that year off to write my framework, how much of the wheel will I have spent reinventing? How much wasted productivity is involved in _every_ programmer solving the exact same problems? How many of the same (or different!) bugs will I have to fix just to provide the basic functionality of a database app, that all database apps share? There's a software crisis, folks. Apps take too long to write, and they have too many bugs. The best solution I've heard is OPC.

4) Working with OPC is hard. Reading someone else's code is irritating: they format it differently, use different variable naming conventions than I like, they're not as OOP as me, yadda, yadda, yadda. In fact, I think most programmers would rather write code than read code. It's just more fun! But this is an attitude we've just got to get away from. If we're going to solve the software crisis and become as reliable an industry as, say, the auto manufacturers, we've got to recognize that code reading is as essential a skill as code writing. This is a new concept. There are still shops that measure productivity by lines of code written per day. I think that should be reversed. The best programmer is the one who writes the _fewest_ LOC.

5) No framework is going to work just the way I want it to. And I'm going to have to deal with their bugs as well as my own. Well, welcome to Visual FoxPro! :) Every time I get exasperated with VFP and investigate turning to a solution that gives me more control (like VC++ or VB), I always come back to VFP, because it has a higher return on investment than if I were to try to implement everything it does for me in C++. Anyone who uses a 4GL has already bought into the framework concept.

6) One should probably not start a new language with a framework, if possible. There's nothing like gaining the understanding of an environment by working with it at a lower level. Personally, I've had the luxury of being able to take the last few years off and learning VFP (among other things). I'll be in a much better position to evaluate the framework I choose accordingly.

7) I haven't chosen a VFP framework yet (though it may end up getting chosen for me, eh Christof?:), but I've done a lot of C++ work. In the C++ world, I wouldn't think of writing most apps without a framework: MFC. It doesn't do everything I want, it's maddening at times, but I have no question that it's helped me produce better apps quicker. I know, because I've written Windows apps from scratch.

8) Finally, clients may differ, but they don't really want their apps to be different (you made this point yourself when you mentioned that your client wants the Office look and feel). One of the biggest advantages to Windows is that there is a standard UI. There are simply fewer decisions to be made with a Windows app than a DOS app. This lends itself well to a framework-based approach.

I probably could come up with eight other points, but if anyone's gotten this far, I think they'd feel I'd said enough. :)
Previous
Reply
Map
View

Click here to load this message in the networking platform