

Flavors of programming ... - RiderOfGiraffes
http://pozorvlak.livejournal.com/135255.html

======
gruseom
I find it interesting that you (implicitly) like Data Munging better than
Clever Algorithms. I agree that the former is orders of magnitude more common.
I haven't encountered a Clever Algorithms problem very often at all on
commercial projects. My current project is an outlier insofar as we've been
doing algorithmic work for months. It's fun, in the way any good hacker would
expect such a challenge to be, but it's also stressful to work on something
for a long time and not know for sure whether you'll end up with a solution.
(Especially when the context is a startup and not a research project.) It's
much easier when you know for sure you can get there, you just have to figure
out how. Thankfully, the Algorithms category gets more and more fun as you
knock off significant chunks of the problem. Once you see the light at the end
of the tunnel, you're home free. Unless, of course, you got it wrong. :)

Edit: by the way, do you actually use APL/J/K in the way you mentioned? I
really like that paradigm. I think it deserves a place alongside OO and the
others as a fundamentally different approach to programming. However, I
haven't used it nearly enough.

Edit 2: I would distinguish two different kinds of Data Munging. One is Data
Transformation, where you have data in some original context and it needs to
go through a series of transformations or passes until you've extracted or
computed what's suitable for your problem. That is way fun. The other type,
though, sucks rocks. I call it Meat Grinding. That's when you have the _exact
data you need_ in a form that you can't use because of some purely technical
limitation. A common example is you have data in a database or a DTO when what
your code need is a domain object, so you have to copy the properties over
like this:

    
    
      myStupidObject.CustomerName = stupidDataObject.CustomerName
    

This isn't so much a programming problem as an integration one. (You sort of
touch on it at the end.) It's also one of the worst things about programming
in less powerful languages where you can't easily write a program to do the
gruntwork for you.

Edit 3: I'd also argue that your "API spelunking" nightmare is at its nastiest
in OO systems. In poorly designed pre-OO APIs (like Win32), it might take a
long time to figure out how to call a function or what to do next; there might
have been some ugly one-off struct you had to populate, etc.; but at least you
didn't have to figure out how the hell to make a Bar out of a Foo so you can
pass it as the third argument to Baz, when neither Foo nor Bar has anything to
do with your problem. But with poorly designed OO APIs, these absurd hurdles
seem endless. I used to compensate for this by studying such code
archaeologically (if I couldn't avoid it altogether), in order to learn how
the absurdities had arisen over time. This was a way to escape Dostoevsky's
definition of the easiest way to drive a man insane: make him move a pile of
dirt from one end of a prison yard to another _and then move it back_.

~~~
RiderOfGiraffes
I understand your use of the pronoun "you", but it's not me. I work almost
exclusively on algorithmic stuff, and when I do work on data munging it's the
direct application of algorithms just developed. So I'm lucky.

~~~
gruseom
Oops, I assumed from your other comments that the OP was yours. Sounds like
you've got a good situation though.

------
david
I don't think one of my favorite (OOPish) flavors was included. I think of it
as something like designing an organism out of various independent parts,
figuring out how they will work together and respond to input.

For me a lot of more complicated UI design is like this, I have objects
representing each part of the interface and spend a lot of time sending
messages between objects and figuring out how to handle user events. I guess
the focus isn't so much on algorithms or if-statements so much as high-level
architecture.

------
diN0bot
at first i thought this would be good. data munging is definitely a time of
programming that occurs.

but then the list just gets ridiculous, almost poking fun at the different
jobs one might do. more importantly, real tasks are left off.

i flagged this submission for being boring.

~~~
jacquesm
The list is meant with a wink, the references to the maze are really a funny
way to get the point across. Grow a sense of humour and flag stuff that really
needs flagging, such as this: <http://news.ycombinator.com/item?id=943367>

In case you missed, it, let me spell it out for you:

Programming is idiomatic at a higher level than you'd think by casual
inspection of the code, when you zoom out to the level of individual programs,
maybe even projects there is a very limited set of classes that you can group
most if not all programs in to.

I'm missing one for web programming, so let me supply that one here:

WebApps: data gets moved from some datastore, through some processing
machinery to produce html, then gets sent to the user, the interactions get
captured in forms or ajax and pass a bunch of processing machinery on the way
to some datastore. Repeat until machine failure.

~~~
RiderOfGiraffes
Have you put that in the comments on the site? It fits ...

