Flavors of programming ...(pozorvlak.livejournal.com)
pozorvlak.livejournal.com
Flavors of programming ...
http://pozorvlak.livejournal.com/135255.html
4 comments
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.
Oops, I assumed from your other comments that the OP was yours. Sounds like you've got a good situation though.
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.
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.
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.
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.
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.
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.
Have you put that in the comments on the site? It fits ...
I appreciate your point of view, but would find it more interesting and useful if you could give an example of the sort of programming you feel has been left off, rather than just dissing the item without being constructive.
I look forward to your contribution.
I look forward to your contribution.
Flagging isn't downmodding. Please don't flag for being boring. Actually, I don't think you should downvote for being boring, either!
ha this amused me because I've been at most of these stages. The last one, API spelunking is what every trip to Java land feels like.
It's actually quite painful to realize when you look at your last 10 projects or so and you find that indeed almost all you've done can be reduced to these few categories.
My pet peeve about java is that I have to use an IDE to work with it because of all the APIs there are so many of them that I can't seem to remember all the function names and parameter sequences. An IDE is like a crutch, you use if for a bit and then you find out you're now so atrophied you are dependent on it.
My pet peeve about java is that I have to use an IDE to work with it because of all the APIs there are so many of them that I can't seem to remember all the function names and parameter sequences. An IDE is like a crutch, you use if for a bit and then you find out you're now so atrophied you are dependent on it.
also it doesn't help that java is staggeringly inconsistent. Even something as simple as getting the size/length of something in the core Java API is inconsistent:
array.length
string.length()
arrayList.size()
awesome. How could I not remember that. And how about number type conversions?
Interger.parseInt
Interget.toString
BigInteger.valueOf
oh yeah, common sense.
verses something like ruby
7.toString
"7".toInt
A sane and consistent API goes along way to not requiring you to memorizing a epic amounts of useless API and essentially going API spelunking.
Also with java it does seem that alot more of the coding is just calling more API to do things, plugging things together, rather than actual coding and problem solving.
array.length
string.length()
arrayList.size()
awesome. How could I not remember that. And how about number type conversions?
Interger.parseInt
Interget.toString
BigInteger.valueOf
oh yeah, common sense.
verses something like ruby
7.toString
"7".toInt
A sane and consistent API goes along way to not requiring you to memorizing a epic amounts of useless API and essentially going API spelunking.
Also with java it does seem that alot more of the coding is just calling more API to do things, plugging things together, rather than actual coding and problem solving.
> ...verses something like ruby
7.toString
"7".toInt
7.to_s # Convert to string
'7'.to_i # Convert to numberha yes, even better, my bad
On the bright side, at least you don't have to deal with a language that includes functions such as mysql_escape_string(), mysql_real_escape_string(), and mysql_no_really_i_mean_it_this_time_escape_string().
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:
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.