in reply to Re^5: (why to use logic programming)
in thread Easy Text Adventures in Perl

#define IS_FOREIGNER(x) (!(x->citizen)) #define IS_SPOUSE(x) (x->married) #define INCOME(x) (x->income) ... int is_average( struct Person *person ) { if ( !IS_FOREIGNER( person ) && !IS_SPOUSE( person ) && INCOME( pe +rson ) > 3000 ) { return 1; } else { return 0; } }

You wrote your code in an OO style. I wrote mine in an imperative style. Why is yours any better than mine? What benefits do I get by writing in an OO style over an imperative style? When would using OO be better than using imperative?

While you're answering those questions, think about the fact that you're having to explain a completely new way of thinking about problem-solving to me. Think about the fact that you're having to explain concepts that may take months for me to fully comprehend. (And, that's assuming you have grokked those concepts, which you may not have.) Then, you have to answer the question "Why on earth would I ever want to do things that way?!?" And, you'll probably go "Uhh ... uhhh ..." and fumble for an answer.

Now, think about the fact that Ovid is trying to do the same thing with you, but for a logic-based style of programming.

For further reading, look over Beating the Averages, specifically the section entitled The Blub Paradox.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Replies are listed 'Best First'.
Re^7: (why to use logic programming)
by BUU (Prior) on Feb 14, 2005 at 19:56 UTC
    I think I agree with the main thrust of your post, but just to nitpick a little, I don't think you actually wrote "imperative code", at least as far as I understand the term, and perhaps if I'm wrong somebod will correct me. You are actually writing Object Oriented code because you define a set of data then you write methods that operate on this set of data. The fact that the language doesn't have, or you aren't using, any specific syntactical features related to OO code doesn't matter, as far as I know.
      It is a common practice in C to use macros for anything and everything. Take a look at the Perl source and you'll see macros all over the place. Many will be used for data structure access and many will not. The data structures will be accessed through the macros and they'll be accessed directly. The data structure isn't being thought of as a unit. You're working on the data in *person and you are using convenience methods to deal with it. Kinda like why we use constants instead of magic numbers.

      More importantly, there's no way to ask the data structure to perform an action. There's no way to inherit actions or subclass a data structure. There's no way to construct this data structure. It's looks like it's OO only because you saw one small snippet that was written to look very similar to what you wrote.

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.