pouët.net

i don't code my stuff with pauses of a year.
also, comments.

OOP might be not the most speed efficient thing around. But when you are working on big projects with other people it most certainly is the easiest to manage. Also hardware has become so fast that 99,99% of the code can be slow as fuck and still perform well anyway. It's quite obvious that you don't want to create/use slow classes in inner loops.

Also Louigi, what kind of big projects have you worked on? To me it seems you don't know much about programming but I might be wrong.

the name OOP was chosen instead of POO.
with OOP all code longer than 10 lines must be splitted into separate classes, with only half line length.
with OOP one extra level of indentation is needed.
with OOP having both classes and namespaces.. then two levels of indentation is needed.
with OOP in some languages you can max have 1 class per file and their names must match.
with OOP in some languages the classname must be CamelCase.
with OOP whenever you write "public".. a kitten is killed.

Louigi: I read much of that site a while ago. In short, what he's saying doesn't really mean much despite the fact that he's mostly right. OOP isn't ideal for every task, but it is a very good paradigm for what it's good at.

What he leaves out is that most people who do "plain" structured programming on any moderate-to-large scale project tend to end up implementing their own object-oriented framework anyway (grouping data structures and code, using lots of function pointers, and so on). Native language support for a standardised way of object-orienting code is just a logical extension of that.

The GameDeveloper article has some more useful criticisms because game systems are something OOP is traditionally considered a "good" paradigm for, to an extent. I don't think any serious game developer would find a lot of new information in that article, though. Also his description of a game as something that simply transforms data is a little contrived. His "data orientation" becomes a lot less straight-forward as soon as all the entities in the system start interacting with each other, as in a physics engine, say, where you're constantly building and rebuilding graphs and working on unpredictable object pairs, each object having a fairly large state where every variable plays a role in collision resoution etc.

Also it doesn't take a change of paradigm to be aware of the fact that memory is slow and the cache isn't.

Also also, skrebbel is absolutely right about embedded systems, and I'd extend it to systems in general. Describing any computer system as a hierarchy of objects is extremely useful.

I do web developing in C# (not my choice, my company's), and find OOP to be very useful. Sometimes I'm in a hurry and I just add public static functions to a class called Misc, but I usually regret it later. I find everything to be much better after I refactor into classes.

As an example, the site I did for work is able to send a single e-mail to multiple clients. However, depending on what the message is, it might be sent to different groups—for example, only clients in a particular business field, or only clients that have made a certain purchase. Now, I want to have only ONE page that is able to send e-mails to each of these different types of groups of clients. The solution? Create a class called EmailTargetGroup, which serves as the base class for any kind of group of users that should be e-mailed. The page itself is passed an EmailTargetGroup object. The actual different sorts of groups are all different classes that are derived from EmailTargetGroup. It has methods such as "get a list of addresses to which to send", "get the text to display on that page when sending to this target", "get the 'type' value to store in the database to record the fact that the e-mails were sent", etc... The benefit is that the code for the page you use to send the e-mails is dead simple, and the code for each possible target group is, again, dead simple.

This is just a typical example, of course there are hundreds of classes, and of course in ASP.NET every single item on the page is an object. The only thing I regret is that in C# I can't have multiple inheritance, as it would be very nice to say "here are page objects that have attached error messages", and/or "here are page objects that belong to a form".

Still, in ASP.NET I find that there are certain functions that are "straddlers" that don't really belong anywhere, which is why I have Misc. Most of these would go away if I were to use all of my own classes that override the ASP.NET ones, so that I can add to them as I want to.

One thing I'd like to do, if I could start over, or if I had the time to refactor, is to make multiple, non-interchangeable string classes. Their only difference would be the type of string they contain: plain text, xml, or escaped strings suitable for use in attributes or query strings. The idea is that it wouldn't let you use one string in place of another unless you did an explicit conversion, so you wouldn't always have to remember to hand-code protections against injection attacks every time you bring a string in from the user.

clearly, you never worked on decent non-one-man jobs. mind, i'm not talking about democoding. comments are entirely useless if people can't even start to get an overview of what is where in your 1m lines of code application.

What Skrebbel is referring to is applying the principle of object orientation. That isn't quite the same as literally using the OO-subset of a language..

(I get this feeling that you're looking at the latter too much..)



Real projects do have code that is left untouched for extended periods of time. Any sizable project would be hard to follow on comments alone, you need proper code structuring wherever possible.

plek, indeedo. i think doom summed it up real good:

Yeah, you're wrong. I do web programming for a living. By web programming I do not mean making web sites.

As for big projects - difficult to say. I did work for serious projects, I guess from the desktop coder point of view they can be called "middle" size projects.

For instance, I had several jobs with online payment systems. Those were written in OOP, lots and lots of code and I had a hard time changing something without screwing something up. To make a small-small change you would have to dig up like 5 or 6 separate classes and study what they do and how, then finally implement the change and then check if that change broke something. My first doubt that in this exact case OOP was the way to go (or that it was implemented well) was when I spent half a day figuring out how to change a line of text. All those buzzwords like "classes", "inheritance" and "templates" in this exact project turned managing the code into a nightmare. And should I mention that I was not the original author o the code - there were many before me.

Payment systems are tough systems - they are not simple and there is a lot of functionality. Yet, I believe that they are not in most cases the job which require OOP. They are too dynamic for OOP, you cannot predict what type of change you'll need to introduce. In one case the amount of change to implement a fairly trivial functionality was so complex that it was simpler to just comment out the whole script and just right a couple of functions.

i was at a seminar at ASML the other day (they make machines that make chips, of the semiconductor kind) and they discovered that their C code often had a lot of similar stuff happening in it; calling logging/tracing functions, profiler macros with the right parameters, error handling and passing features, etcetera.

a while ago, scientist type people saw these patterns and came up with a term called "aspect oriented programming" as a method of separating all the logging, checking, tracing, error handling, etcetera, from the actual functionality of a function. they published papers and that's that.

So some ASML guys set out to design an aspect language on top of C, and called it WeaveC (as the WeaveC compiler "weaves" the aspect code back into the functions before passing it all to a standard c compiler), and they're currently in the process of adapting their 33m lines of code to it, vastly reducing the complexity of the code, the errors caused by copy&paste mistakes and the maintainability of it all.

Moral of the story: they were doing something already, but wanted to do it better and more structurally, so they added language support (instead of, in their case, writing a "how to make a new function" guide with copy&paste examples).

OOP support in languages is no different: people were doing it, they wanted to do it better, so they added it to programming languages. this does not mean you must use it or else you suck, but it does mean that if you're doing it in a difficult way even though there's perfect language support, then maybe you should rethink your approach.

Hm. Is grouping data and function (object) pointing the main idea of OOP? I can group things in functions (which I do). I would have functions for a database in one file, functions for working with user input in the other, etc. It is very convenient and I do not tie those things up in hierarchy. My workspace does look like my personal framework, but I do not see how it is similar to the paradigm of OOP. Correct me if I am wrong.

And actually the guy on the site did mention this effect, only to the other end - that a lot of OOP code tends to be procedural in nature. His site is pretty large and has loads of articles. You just need to read them carefully.

Apart from him delivering the main idea of OOP not being universal I enjoy his analysis. It is clear, clever and very well thought out. I enjoy when people deliver good arguments, not just emotional things.

Nice words. But lots of employers out there would not agree though. They want "OOP and templates!!!" They can't explain why )

louigi, i feel that your major complaint from that anecdote is that it's difficult to adapt complex 3rd party code.

hint: it is.

if in your case it's faster to redo some of the functionality and work around the problem, then there's no problem with that. unless of course you want to be able to benefit from updates in the 3rd party code, or feed your changes back into the project, etcetera. if none of that matters and you don't expect anybody to touch your code all to much after you delivered the web application and gotten paid, then there's indeed absolutely no reason to do it the "elegant" way.

i don't see what that has to do with OOP though. complex 3rd party code is complex. remember that they did not do OOP so that it's so easy for you to patch a feature in a second. they did it so that it's easier for *them* to patch a feature.

additionally, especially in web-programming-o-world, i feel that very many people completely abuse classes and all. plenty PHP morons put classes around everything without documenting what they mean, completely refuting the concept. using classes does not automatically mean that there's good design - often it's quite the opposite. but that's like saying cars are bad because some people use them dangerously.

Haha yes. Like comparing it to communism. That would be idiotic.

louigi, do you work for those employers?

additionally, don't underestimate the importance of a common standard. if i work with 50 people on a product, and i do everything in plain c and everybody else follows the software architect's pretty UML design, then who's right? even if i'm right about how ridiculous it is to use classes here, the only way to be productive is to stick to the standard. it's like the web - HTML sucks rotten cocks and yet we keep using it.

not completely. 3rd party code is difficult but if it's written well eventually you'll get the hang of it. I would say that the anecdote shows that OOP used in the wrong place can cause more complexities.



In case of cars only some people use them dangerously. In case of OOP my experience shows that most people use OOP where it is not needed. Especially in PHP, yeah.

Used to. Now I have changed my job a bit to a more managing side ;) But I still remember when someone would stop the interview simply because they believe you are not a good developer if you do not use OOP.

Imagine you work at a company where everybody is very well able to work with UML diagrams, many of which are inherently object-oriented (and in a Java/C++ way). Then switching to haskell, or even just javascript, c or python (which, in different ways, aren't too far off of the Java/C++ OOP model), may prove to be more difficult than just teaching everyone the language - even technical communication becomes a problem as people have to reinvent a way to write down their designs and dataformats.

Just that is a great reason for many employers to stick to C++, Java or C# and nothing else. If you think that that is a bad argument, found your own company instead.

there's idiots everywhere :-)

These are words I do agree with, but this is not the topic of this discussion ;) The topic is whether the OOP paradigm in itself is the most optimal one.

In real life, of course, it all comes down to being pretty much "locked in" into OOP.

As long as you think "classes", "inheritance" and "templates" are just buzzwords there is not much point to this discussion.

It's not about not being a good developer. If they're hiring you to code OOP you should probably know it :)

Totally pure code (where everything is immutable) is easier to manage. Just saying. Though that's not the most speed efficient thing either, it's not so bad if you know what you are doing.

true. but I have had cases when people made conclusion of what I can do based on whether I use OOP or not which is ridiculous, but skrebbel said it )))



I do not have too much of an opinion at the moment. I see many people use these concepts like buzz words, without having any real reason to explain why they use them. I myself am ready to change my opinion.

I have no idea how a auto-complete would work with a zillion of seperate functions... ;)