i'm back to needing a work icon

[meganursula]

Question for object oriented gurus:

I am currently reviewing some code implementing a current standard of an algorithm i frequently use. (I want to examine some modifications to the algorithm, but, i need a good baseline to compare to.) In it we see something like:

struct velocity
{
int size;
double v[D_max]
};

There are a lot of these structs - position, quantum, etc.

Thing is, in my code, i generally declare
num_dim = n; // this is what they are using size for up above
double position[num_dim];
double velocity[num_dim];

(quantum, for the record, appears to be taking the place of what i usually declare as a constant Eps, and is used to get around numerical issues when looking for zero.)

etc. I do not have additional structs. Thing is, i find all this structifying to be sort of pointless and irritating. Pointless because i do not know what the structs are adding to the code. Irritating because i think they add a level of obfuscation, rendering the code not only longer, but also much less readable.

My question - what, if anything, am i missing in this situation? I get, generally, what object oriented-ness does for you. But i haven't used it very much in the past 6 or so years. (Matlab's excuse for object oriented isn't worth bothering with.) Right now i find myself faced with a few examples of modern code that are object oriented up the ass, and it just seems like it all has been taken too far. If i give myself three months will i become a believer? Will i stop feeling like there should be some sort of natural progression through code and adapt to having objects interacting at will?

Comments

[bhudson.livejournal.com]

In the PL community, functional definitely means no side-effects. You can indeed write purely-functional C, though from recent experience I can safely say it's a gigantic pain. SML and o'caml and common lisp and haskell and so on are "mostly" functional languages since you have to go out of your way to be able to rewrite something. Refusing all side effects isn't really practical.

I've seen code that was just a lambda soup. It helped make me despise Ruby, although it wasn't the language's fault (plenty enough other things were). Most code I run into sees a function that takes a closure as basically a loop, which is perfectly readable.

[angelbob.livejournal.com]

In the PL community, functional definitely means no side-effects

Assuming PL == "programming language", you overgeneralize. That is one thing functional means. Much like "OO" can mean "using objects for polymorphism", and usually does, but may not. It can also mean "all types descended from a single parent type," but often does not.

Most code I run into sees a function that takes a closure as basically a loop, which is perfectly readable

Yup, that's actually how Ruby does most iteration.

And yeah, lambda soup is a pain in the ass. Ruby is interesting because it has little enough in common with most of its predecessor languages that its fans are really still figuring out how to write it, stylistically. So "Ruby style" is all over the map, and still evolving fairly rapidly for a language of its age.

[bhudson.livejournal.com]

"Interesting" is one way to put it :)

My main beef with Ruby was that it didn't seem to offer much over python, except for tricky design issues that perl and python faced and overcame 5-10 years earlier. What it has come up with since I last got burned is a mature Ruby on Rails, which is the shiznit when it comes to writing web sites, or so I'm told. My main beef with both python and ruby was that it does almost no static checking, which means if you misspell a function name on a line of code that is only invoked after 30 minutes of computation, you want to kill something when those 30 minutes are up and you just lost the data.

As for PL, I meant the theoretical programming languages research community. Functional means no side-effects; first-order functions means lambdas; polymorphism usually means parametric polymorphism, not the god-awful OO inheritance stuff; first- and higher-order types are in vogue; any language in common industrial usage is hardly worth dignifying with the term "language." None of that is really in dispute in these halls (among the PL types -- others are very happy about how Ruby "doesn't get in the way" [of writing buggy code]). Once you drink the kool-aid, it's pretty hard to go back. Languages in industrial usage lag the research community by 20-30 years of course, though Simon Peyton-Jones at MSR Cambridge is pushing some pretty modern features into C#.

We're by now pretty far afield of the original topic aren't we...

[angelbob.livejournal.com]

Yup, pretty far afield.

Most of what I like about Ruby specifically is metaprogramming, which can be thought of as either poor-man's LISP macros or structured-eval-plus-runtime-type-definition. Rails happened in Ruby because Ruby has metaprogramming, which Rails uses quite extensively.

I like Python just fine, but its indents-are-syntactic quirk makes it very hard to embed as a templating language. That's not a huge drawback overall, but again, Rails needs a very robust templating language since a lot of what it does involves generating HTML from templates. And honestly, I just like Ruby syntax better for most stuff.

[mh75.livejournal.com]

Pretty far afield is great in my book!