Hacker News Reader

Comment by stcredzero | Hacker News Reader

A big problem with OO is that most GUI interfaces are not a good match. It's quite natural for people with a GUI builder to start writing a program from the GUI down. Of course, since people tend to like attaching ideas to things that are more concrete, like the window they've just made appear. This tends to produce bad designs from the OO standpoint, however.

On the other hand, if people start writing up and passing around CRC cards, they tend to produce better designs. My conclusion is that GUIs have too much baggage from documents. In some important way, they are much worse than 3x5 cards that you can pass around. Once we figure this out, some aspects of programming will improve.

It will probably always be hard.

View on HN

Even for GUI I have a hard time seeing why it would not be useful. In the typical event based environment (windows, frames, list boxes, whatever), how would you implement it without objects?

I am probably spoiled because I did it for too long, but I find it really hard these days to get by without objects.

I took up Scheme programming again, and I like it. I tried to keep it simple and avoid objects, but I find myself missing them all the time. Writing complex getters and setters with car and cad into deeply nested lists does NOT seem simpler.

I wish some of the functional programming gurus would write tutorials on non-object-oriented programming, instead of ranting against OO programming.

I think it's generally a mistake to use list structures with position-based accessors when what you really want is a struct or a dictionary of some sort. Aside from sane getters and setters, what object features are you missing? SRFI-1 gives you alists. It's pretty trivial to write a macro that lets you make constructors with generated accessors. It's not much harder to add inheritance to that. Generic functions and multiple dispatch can be implemented using a globle table of closures. Hey... this is starting to sound a bit like CLOS, isn't it?

Inheritance is not important, but the organisation of data. What if you have a GUI with say a tree view element, a list view element, and a text element. How would you create that in an non-OO way? I suppose you could write

var tableData = ... var listData = ... var textData = ...

and then add callback methods (all in the same source file?). But that runs out of hand real quick. It seems much nicer and cleaner to have a treeView object that knows it's own data and callback methods.

What if you have nested elements, like a window with those three elements, or something else. How would you hand that data around?

I have seen the make-struct macro of MzScheme, but once you start using inheritance with that, it starts getting really ugly, imo.

"Inheritance is not important, but the organisation of data"

Good point. I missed this when I first left Java, because in Java you get these nice classes. Over time I've found I use class structures a lot less, or in some situations I'll hack them. The other day I was writing a tree builder where in java I would have had a different class for "node", "attribute", etc, all extending from element. In my python impl I just had a class "element" with a string field "e_type" which was "attribute", "node", etc and then I stuck other stuff into a dictionary in that object as I needed it. Over time I've found that the extreme brevity improvements combined with blocks of documentation to describe the purpose of a grouping of code more than make up for the loss of code-based structure.

Again on the topic of organisation of data - in databases you get a lot of automatic documentation because the schema abstraction we're used to is so widespread and accepted. This is one of the reasons I love to stick with relational databases even though I know that there are good arguments, particularly in FP communities, advocating more practical forms of datastore.

It's true that when people learn object-oriented programming, and they learn about inheritance, they tend to think that inheritance is something you should be using heavily all over the place. It takes some experience to learn where inheritance is proper and where there are better ways of doing things, such as delegation.

I don't think OOP is that hard to learn, but I do agree that learning to use it very effectively in the best and most tasteful way takes time and experience. But that's true of so many aspects of software design; I don't think OOP is all that different in this regard.

Reply on news.ycombinator.com