We need a good flamewar in here.

Thus! Object-oriented programming: Does it suck or what?

Ruby lol

just imagine what ruby would be without OO concepts! instead of

if patterns.any? {|pattern| elementAtHand =~ pattern}
    # do stuff
end

you'd be writing, taking some pseudocode as an example,

my $atLeastOnePatternMatches;
foreach(@patterns) {if ($elementAtHand =~ $_) {$atLeastOnePatternMatches = true; last}}
if ($atLeastOnePatternMatches) { 
    #do stuff
}

or something. this would be just like writing in perl! think about it for a minute and the answer to the initial question should become clear.

faps to NeXTSTEP

I personally don't like it, but I try to avoid letting personal preference get in the way. My main problem with it isn't the concept itself, but rather people who attempt to turn a simple abstraction into a religion.

Use the right tool for the job. For some things OO is great, for others it's a poor choice.

if grep { $elementAtHand =~ /$_/ } @patterns
{
    # do stuff
}

That has nothing to do with object-orientation and everything to do with syntax.

And what I was meaning to say was pretty much what >>5 said. OO programming lends it self elegantly to certain tasks - game programming and GUI programming come to mind. However, many other kinds of programming suffer from being forced into OO form - you end up writing object wrappers for the smallest little pieces of code, bringing no clarity or structure to the code. Java especially suffers horribly from this, because it only allows OO style. C++ is much more flexible, letting you mix and match.

i wasn't being serious since you mentioned "flamewar", looks like you guys are agreeing instead :o.
to get back on topic, i personally think that whether OOP sucks or not also depends on the language you use. some let you implement and especially use classes as well as other OOP concepts easily, while others are rather chunky and require some extra keyboard and brain combo-action. of course, the using part does not hold true if you don't put much brainpower into a piece of code.

What. Ever.
So functions can be treated as data members (statically or as closures...). And what, you don't want dynamic type resolution?

Give me a break. There is nothing wrong with languages that have OOP features, and you can easily ignore them.

And just because java is severely crippled to try to prevent you from doing so doesn't mean you can't.

>>8

But why does a programming language need to make key things that are needed so goddamn difficult, or if not difficult, so much of a work-around? A given code solution in any problem should be as simple as possible for efficiency to both the programmer, but to the poor bastards debugging it, and to the community using it.

The oop people are fapping to it and thinking it the greatest thing when it is just horribly restrictive.

It restricts your thinking process.

Hierarchies and everything is an object sucks much.

Well, unless you're about to bless us with a programming language that can implement the full expressiveness of an entity-relationship model... do you have any better idea?

I think a big problem I see with a lot of OOL's is efficiency. Lets look at "top end" languages. Machine code, ASM, C. From what I know of these languages they are all instructions, keeping the OO down. Its only until you get into the interpretted languages, Python, Ruby etc does the amount of OO in the language become greater. What's my point? Well, interpretted languages, and especially OO interpretted languages take more process time, more CPU cycles and less efficiency to get a task done. A compiled language that is low on OO tends to be a more efficient.

Proove me wrong.

The overhead of OO semantics in languages like C++ is minimal. Virtual functions require an extra memory lookup for each function call, and that's about it.

What might be argued is that the OO metaphor encourages people to write less efficient code. The program flow is obscured, and people do not realize how much code they are invoking.

Doesn't the same go for functional programming too, though? I could make a function that consist of 700 lines of code, in which it's calling other functions which also consist of 700 lines of code (it'd be an extremely stupid way of programming, both in functional as in OO programming, but for the sake of argument...).
Unless the people using that function in their code goes through the sourcecode where that function is defined, they will have no idea how much code they're invoking.

That would be procedural, not functional - you're going to make the LISP people cry.

Anyway, yes, the same is true for procedural coding but it doesn't reinforce this kind of design to the same extent that OO programming does. OO favours making generalized objects when more specialized code would have sufficed, and also makes program flow more opaque by hiding code inside object constructors, and nested superclass calls. Under some circumstances, this creates more readable and structured code, but it seldom makes for more efficient code.

However, if you're using an interpreted language, you've thrown effiency out the window already, so this isn't as much of a problem there.

>That would be procedural, not functional - you're going to make the LISP people cry.

I always confuse those two for some reason... probably because in LOGO subroutines are called procedures while in C they are called functions =/

>OO favours making generalized objects when more specialized code would have sufficed

Depends on the way the program is designed, really... for example, say in a program, there's an object that's an 'Image' object which has a method PaintMe(), that renders the image on the screen. In this case, then indeed, the image would always use the exact same code to render itself, and you wouldn't be able to use any specialised code.
However, if the 'Image' class is purely a entity class and only contains things like the image data, size, and location and let the rendering be done by Render objects, you could have multiple Render classes and use the right class for the right situation.

I think you may have inadvertantly supported the assertion that OO favours making more general objects. For example, why have multiple Render objects? Why not just embed them into the Image class itself? Or make one Render class that handles all cases?

I think OO has been given a bad rap by the overzealous and by Java though. If you shut the silver-bullet types up, and ignore Java in general, there are some rather elegant solutions to problems using objects (and prettier languages to boot).

The one thing OO is good (and bad) at is abstraction. It's good for formalizing interfaces between code. It's bad because it can have hidden effects. It's good because it protects data. It's bad because you'll have individuals using objects to keep integers in a linked list. It all comes down to the discipline of the coder.

oo is like trying to use smooth wheels instead of toothed wheels as gears

I always say:
Java (as a language AND a runtime) = good idea, horrible implementation.

Making it worse are the so-called 'guides' and 'best practices' which serve to do nothing but make it worse ("hay guys, let's take something sinple and make them jump through a millions hoops before they can use it"). You can't imagine how glad I was when I tried C# and .NET and found how much more practical they were. Your classes, interfaces and objects should be the right size for the right job. Unfortunately Java advocates tend to advocate you to take a jackhammer to everything.

To be fair, bringing Java into a discussion about the merits of OO programming is just being plain unfair, like using FORTRAN 77 to argue against procedural programming.

true, OO is useful, Java is not ;)

I'd have to agree. As far as OO comes, both Java and C++ are crippled.

This isn't a very exciting flame war. Are there any LISP weenies around to troll?

What is the difference between functional programming and procedural programming?

http://en.wikipedia.org/wiki/Functional_programming
http://en.wikipedia.org/wiki/Procedural_programming
...though these articles can be a bit tough to follow if you're not a huge programming dweeb. It would be nice if perhaps someone who knows about this stuff could write a simple app in both functional and procedural pseudocode, so that we may see where they compare and contrast? (It could be contributed to those Wikipedia articles as well.)

Procedural is program state and statements that change that state. Ie, you make step-by-step instructions to do what you want.

Functional is the evaluation of (math) functions. Ie:

force(mass,acceleration) :- mass * acceleration;

Everything is written in terms of functions.

Procedural:

int factorial(int n)
{
  int i, k = 1;
  for (i = 1; i <= n; i++) k *= i;
  return k;
}

Functional:

factorial (n) :-
if n = 1 return 1;
return factorial (n - 1) * n;

Note how the functional version doesn't have any assignment (ie: i = 5). This (and other) lack of side-effects makes the function easily provable.

Most languages aren't strictly procedural, of course.

int factorial(int n)
{
return (n == 1)?n:factorial(n-1)*n;
}

As >>27 points out, many functional concepts can be quite easily used in procedural languages, but the opposite is not true. This, in my mind, is a good argument against functional programming.

If you wanted to make C behave like a functional language you could do it without too much difficulty. The worst you'd ever face is using function pointers to emulate higher-order functions (you might need a garbage collector too). Obviously, not all imperative languages can do this.

The odd thing with that though is that it hints something else: functional and imperative are provably the same. It's just that they have different strengths, which is why some functional languages include some elements of imperative (the ML family), and imperative languages are incorporating ideas out of functional (tail-recursion elimination), as pointed out by >>27.

IMHO, imperative is good for I/O and functional for algorithms. Functional does have the nice attribute that it's easier to write bug-free code in (and prove, but who does that?). It's just that it's unpleasant for anything involving external state.

I find the whole idea of eliminating state to be kind of ridiculous. A computer is nothing but state, and trying to abstract that away seems awfully counterproductive at best, and like theoretical wankery at worst. Sure, you may gain some mathematical advantages, but you lose so much more and get lost in pure theory with no real application.

As purely theoretical research, there is a little bit of value to functional programming - some functional concepts have found their way into imperative langauges that can actually be used - but to suggest that one actually use functional programming for real programming doesn't sit right with me.

Is it just state? Maybe. Or maybe it's a glorified calculator. Or maybe it's both.

You don't actually lose anything. Lambda calculus and Turing machines are provably equivalent, so it may be more accurate to regard them as two aspects of the same thing. As such, pick that which is best suited to what you're attempting to do, otherwise there will be more pain than necessary.

I learned this the hard way when working on some projects with prolog. While prolog is not functional (and I really don't like the language either), it's proof enough to me that there are some problems I'd rather not do in imperative.

However, you may point out the things I was working on were fairly esoteric, and you'd be right...

>and imperative languages are incorporating ideas out of functional (tail-recursion elimination), as pointed out by >>27.

I wouldn't call this a language feature; it's a general optimization you can apply to anything. The only thing a language can do is make it impossible, by forcing stack frames to always work in a certain way or something.

Someone once tried to tell me that one of the failures of C was that it "wasn't tail-recursive" (he was a Scheme/Haskell nut).

>>31

What are registers and memory but one big state? You can freeze a computer at any point, write down the contents of its memory and registers, take an identical computer, write the same data into it, and it will continue working as if nothing happened. What you wrote down is state, and that is all there is.