Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Kylotan

Feelings on programming dogmata

This topic is 5161 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Recently I''ve become a little disillusioned with the programming world because I see a little too much rigidity in the minds of people. Instead of being open to improving the way we write software, it seems too often like people find a way that they like and attempt to make the world agree. I''ll illustrate this point with 2 examples. The first, is a ''mistake'' I made with my own code recently. I was writing a CGI application in Python, and as I went along, I spotted common elements... generating the HTTP headers, the HTML head, the common parts of each page, and so on. To begin with, I abstracted these out into functions so that they were written just once and called on each page. Then I realised that I was copy-and-pasting this code for each web page, with only a few minor changes in some cases. We''ve all seen people say how copy-and-paste code is bad. When one bit changes, you have to then go and change it all. It''s awkward to maintain. It''s redundant, in terms of needing to be checked/tested/compiled in multiple places, in terms of taking up more disk space, of the repeated times you have to type or paste it, etc. So, I endeavoured to remove this by abstracting the commonality into a standard algorithm, using what is commonly known as the template method. You provide a base class that dictates a standard algorithm and sub-classes override parts of that algorithm as necessary to customise behaviour. No more copy-and-paste, no more redundant code as you only ever override what needs changing, etc. I refactored all my pages and things worked fine. Each page contained a class with 1 to 3 methods for the things it needed to override. Then real life took over, and I had to abandon the project for a couple of months. When I came back and looked at my code, all I saw was a tiny bit of logic buried beneath a mountain of abstraction. No longer could I look at the code for an individual page and see exactly what happens, because half of the the functionality was hidden away in a base class. I had several functions in each file and couldn''t see instantly what order they would be called in without cross-referencing it with the base-class. I couldn''t follow the program flow steadily down the page but instead had to flick between 2 files at a time, adjusting my mental understanding of the program flow in the base class based on the contents of the sub-class''s file. In traditional terms, maintenance of this software had just become harder, not easier. I felt like I was reading a book where I had to memorise the footnotes to make sense of the story. The moral of this story is that I took it too far. A layer of abstraction buys you flexibility but loses you clarity, and in this case the amount of clarity I lost far exceeded the flexibility I received. The second example is one I saw when talking to people about server technologies for the above project. Some people preferred systems that closely resembled ASP or PHP, while others wanted all the logic to go through one ''main()''-style function and be processed from there. Both ways have their merits and the discussion was of little help to me because of this. However the most interesting viewpoint came from those who disliked the ASP/PHP model because they were adamant that they should separate the presentation from the logic. In other words, they considered this sort of code to be bad:
<p>This is a dynamic page.
<?php print "You are visitor number " . $count; ?>
</p> 
Yet their alternatives - typically involving running a function that uses a request or response object with a ''write'' method to send data to the user - produced code like this:
req.write("<p>This is a dynamic page. You are visitor number")
req.write(str(count))
req.write("</p>") 
Apart from the placement of delimiters and the function calls, these 2 snippets are virtually identical. But somehow they had convinced themselves that embedding HTML in programming code was ok but embedding programming code in HTML was totally wrong. Yet the two examples are equivalent. All the real presentation details would be handled by CSS anyway. The problem here was just in their thinking. Isn''t it sad that we make these kinds of mistakes in the search for some ''true'' way to program? Have any of you ever seen or done something like this and then realised the futility of it? [ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

Share this post


Link to post
Share on other sites
Advertisement
quote:
Original post by Kylotan
Recently I''ve become a little disillusioned with the programming world because I see a little too much rigidity in the minds of people. Instead of being open to improving the way we write software, it seems too often like people find a way that they like and attempt to make the world agree.

Weren''t you the one who said you won''t even attempt to *look into* .NET?

Share this post


Link to post
Share on other sites
I have had only one summer''s worth of experience in the "real world", so my opinion is probably worthless. Nevertheless, I completely agree with you Kylotan. Object oriented programming courses avoid the real situations one might encounter in the business. Therefore, students coming out of theses classes have the mindset that most programming problems can be solved using classes + inheritance and the works when in actuality while they may have their uses, traditional programming methodology is often more practical.

It seems to me that my code has finally reached a style that is practical but flexible, a point that is difficult to reach. Then again, five years from now I might be saying the same thing about now.

The Code on the Cob series here at GameDev.Net has strengthened my programming style. Have you ever read the articles?

Share this post


Link to post
Share on other sites
quote:
Original post by CoffeeMug
quote:
Original post by Kylotan
Recently I've become a little disillusioned with the programming world because I see a little too much rigidity in the minds of people. Instead of being open to improving the way we write software, it seems too often like people find a way that they like and attempt to make the world agree.

Weren't you the one who said you won't even attempt to *look into* .NET?


Yep, but I hope you remember that my choice wasn't based on programming reasons. This is a thread about programming. Thanks.

PS. Also, I did not try to dissuade anybody else from looking into or using .NET, and I did in fact ask a question regarding a much-hyped aspect of .NET on an abstract level.


[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]


[edited by - Kylotan on May 31, 2004 8:54:42 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Kylotan
Isn''t it sad that we make these kinds of mistakes in the search for some ''true'' way to program? Have any of you ever seen or done something like this and then realised the futility of it?



Dear god, yes. You should see some the obfuscated crud I churn out just to satisfy exception safety in C++. (RAII up the wazoo and so on.) Then I think to myself, why didn''t I just use a try/catch block?

I honestly think sometimes I was a more effective programmer when I knew less. It''s not actually true, since I can actually finish large projects now that I couldn''t do say, five years ago, but all the same there''s this feelings of falling backwards.

One thing that''s helped me, at least in the feeling of frustration department, is that I''ve started getting serious about my personal code library in the last year or so. That way, even though I still occassionally get the feeling of over-abstracting my projects, at least the component pieces are familiar.

Share this post


Link to post
Share on other sites
It seems to me that the solution to most modern programming problems is in the IDE (or equivalent). For example, to help with viewing code in a complex class tree, the IDE could show the concrete class code with code from all parent classes shown as well, so you see the whole class when looking over the code.

It could even be taken one step further and the code for the highlighted function/method could be shown. This would really help viewing code where the class has one or two 'main'-type functions that invoke many private member functions. Perhaps it could have a per-method setting that controls how the code is displayed ({inline, 'tooltip' popup on mouseover, seperate window} , {always, only for children with attribute X, only for this class, etc})

In other words, the IDE could allow you to conceptually abstract things without requiring the details to be spewed all over the place, allowing you to easily analize the details when it helps and then forget about them when they aren't.

Both abstraction and the details are helpfull, and such a change to the IDE could help maximize the benefitis of both.

[edited by - Extrarius on May 31, 2004 9:05:38 PM]

Share this post


Link to post
Share on other sites
One of the common arguments against object-oriented programming in general is that abstraction inevitably means that there is no single place of reference. That is, if a class is part of an inheritance hierarchy,in order to fully understand whats going on in the class, you''d have to understand the behavior of each class it inherits from and each class it encapsulates.

This argument is often perfectly valid, take a look at the Unreal SDK that comes with UT2004/2004. Finding out what''s going on can be likened to walking through a forest blindfolded. Of course, the fact that the UnrealEngine is so strongly object-oriented means that it is ridiculously easy to modify behavior _once_ you understand whats going on.

OOP in general sacrifices readability (in that it is often harder for beginners to understand whats going on in an OO-system) for flexibility, and I guess the real decision that needs to be made is whether it is suitable for a project depending on the scope and the importance of flexibility (on a per-project basis).

For large projects where maintainability is critical, OOP is the silver bullet. For simpler programs, functional programming could well be more suitable. Yet sometimes I find myself building hackneyed OO systems simply because Im more comfortable with it (and because its been thumped into my head for a few years now)... luckily at my current job Ive been forced to understand languages and paradigms that I wasn''t comfortable with before, and for that, Im thankful

Share this post


Link to post
Share on other sites
quote:
Original post by Kylotan
Isn't it sad that we make these kinds of mistakes in the search for some 'true' way to program? Have any of you ever seen or done something like this and then realized the futility of it?

Funny, I actually did something like this only yesterday I had written a BSP loader for Quake 3 maps when I realized that since all BSP maps are structured in pretty much the same way (lumps), I could abstract the loader class, and then derive from it for each specific BSP version I want loaded (in case I want to be able to load any BSP map version automatically). Turns out that while there were only minor differences between each format, the obfuscation caused by writing everything in an abstracted manner outweighed the flexibility of knowing exactly what the format was. For example, instead of having a concrete Vertex property in my map object, I had to start writing functions like GetLumpByName in my abstract loader class that returned abstract lump classes that could then be casted by the client, because since I was trying to be as abstract as possible I couldn't assume there was a vertex lump, even though logically all the current BSP file formats would have to store vertex data. It was a mess, and most of the actual map loading code was making sure the derived class worked with the abstract interface I had developed!

Once I had gotten over the harsh reality that I'd just spent hours writing confusing, ultimately useless code, I realized a simple loader class interface was all I needed in the abstraction department. That might be too much even, since I don't have any code right now that requires that level of abstraction, as little as it may be.

Sometimes trying to be as object-oriented as possible gets the best of you. I need to spend more time in the design stage.

Kylotan: I also wanted to add that you always post the most interesting thread topics

[edited by - Zipster on May 31, 2004 9:36:37 PM]

Share this post


Link to post
Share on other sites
I think OOP is overused a bit. It definitely has a place at the architectural level, but when you start getting down to nitty-gritty details, flipping between files becomes not so fun.

I''m writing an IM program, and I naively used OOP when writing the contact list GUI. It was such a mistake because if I want to, say, add an item to a context menu, invariably I load up ContactListWindow.cpp, see that a Node class is being used, then load up the derived Node class, then look for the handler function, then...etc.

Now, I write the code as simply as possible and just add in abstraction when I feel like its becoming unmanageable.

Share this post


Link to post
Share on other sites
quote:
Original post by Kylotan
Recently I've become a little disillusioned with the programming world because I see a little too much rigidity in the minds of people.
People are rigid because they are limited by their tools and/or resources and/or egos.
quote:
Original post by Kylotan
I was writing a CGI application in Python... The moral of this story is that I took it too far.
So, were you too rigid, or not rigid enough? You made a design decision. You choose the best way rather than the easy way. That sounds you were being flexible, not rigid.
quote:
Original post by Kylotan
The second example... Apart from the placement of delimiters and the function calls, these 2 snippets are virtually identical.
No. They are not identical because their designs differ. Are you saying you are being rigid because you can't accept the benefits of their design?
quote:
Original post by Kylotan
Isn't it sad that we make these kinds of mistakes in the search for some 'true' way to program?
No. It certainly is not sad. It is called learning. If you look at code you wrote a few years ago and you aren't amazed at how little you knew back then, then you have learned nothing in those few years. Besides, there is no "true way to program".
quote:
Original post by Kylotan
Have any of you ever seen or done something like this and then realised the futility of it?
It happens a lot. If everything you try is a success, then you aren't trying very hard. If you want to learn snowboarding with the goal of never falling, you will never get very good at it.

John Bolton
Page 44 Studios
Current project: NHL Faceoff 2005 PS2


[edited by - JohnBolton on May 31, 2004 10:16:21 PM]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!