Slashdot Mirror
Reusing and Recycling Code
An anonymous reader sends us to a writeup about when and how to recycle code, excerpting:
"As developers, once we start separating our code into abstract ontological typologies, we make use of the human mind's phenomenal ability to work with types. Our code becomes less about jump tables and registers and more about users, email messages and images. What once was a problem of allocating resources and operations within the computer becomes an abstract, logical problem within a collection of objects....Over time, by constantly working to reuse our own code, we choose practices that work well for ourselves and discard practices that don't work as well or slow down our workflow. For developers flying solo or those working on small projects, this evolutionary process is a sufficient way of going about things. But there's trouble when we add other players into the mix--other developers, a user interface person, a database person, a sysadmin, a project mana-jerk: as a developer, they don't have access to our 'experience' of the code and we don't have access to theirs. "
This assumes the code is good. If it isn't, it's akin to eating your own vomit.
A solid recommendation from an insightful article. Should be in every corporate coding guide.
What is the question in this 'story'? Is this about coding for money or free source or what?
If the question is about coding for money then it is the responsibility of the team lead/designer/architect to make sure that the business problem is divided into pieces in a way that allows different people to work in parallel (if there are multiple people on the project.)
If the question is just about some abstract idea of 'code reuse', then the answer is simple: libraries. Create libraries and document them (otherwise they are useless really, without anyone knowing what the hell is inside.)
In any case, please document the purpose of the code, and then break the higher level requirements into more granular ones with clear specifications.
In all cases divide, concur and document well seems to work best...
You can't handle the truth.
Hell is other people.
Having to work with people for whom the Peter principle has reached its end state is exasperating at best.
Then you have the emotionally unstable, the delusional, the political operators, the empire builders, the saboteurs, the goldbrickers, and of course the fearful.
Is there some reason why I would WANT to work with this motley crew of idiots, assholes, nutjobs, and losers?
Success isn't about a paycheck. Past a certain pay grade the money ceases to be a factor. I'd much rather get an adequate paycheck to work in an environment that is conducive to success than be paid generously to work someplace that sucks.
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
I fear TFA is not a joke! Unobtrusive script starts with valid markup, not garbage like this...
That (type=star) is fine if you're going to pre-process it on the server, only a moron would boast about sending markup like this to the client. If the author of this rambling bullshit article knew what he was doing, he would have used an input image type and class name of "star".
The rest of his article is similar 'junior developer above their station' type stuff. I do like the way the author of this article on code reuse makes a swipe at the concept of an "API" before going on to detail his own API (making a decorator with an Event_Manager $events property).
Being charitable, I could say TFA is incoherent nonsense. I've almost made all my charity contributions for this fiscal year, hopefully the author will keep that in mind before writing any further ludicrous articles.
That should be called "the lesson of UNIX". UNIX provided an amazing simplification that provided almost everything users and developers needed with fewer than 40 system calls (maybe half a dozen frequently used) and a single way of talking to all the objects in the computer system. People who haven't used older operating systems can't really appreciate this, but just opening and reading files used to require understanding something the size of the X11 documentation, you typically had umpteen kinds of files with half a dozen access methods each, with different calls to read blocks, fixed-size records, variable-sized records, padded and unpadded records, three varieties of carriage control, and if you wanted to read or write to a terminal or printer or card reader you had completely separate sets of calls for each. And to simplify this you had record management systems which had their own walls of documentation. And you had to understand this if all you wanted to do was to read a report from a program, because of course every programmer had learned their own bits of this and used them... so even if you didn't care about block-padded variant numbered record files with Fortran carriage control, you had to be able to deal with it. When I ported a Forth interpreter to one system, I had the whole interpreter called from a Fortran main because that let me push the whole problem off on the Fortran runtime instead of figuring it out myself.
This was worse than the line ending differences between UNIX and Windows, which are bad enough.
It's like *every* file, even plain text files, was in its own OOXML format.
Even if you only dealt with one computer and one OS.
UNIX didn't do any of that. It just made everything into a stream of bytes. For the cases where that wasn't enough, you got the whole records-oriented stuff back... in libraries. And when you used those libraries you had to deal with all the old complexity, but you only had to deal with it when you actually needed to. And lots of old timers insisted that this was backwards, that the OS was the best place to do that, so all the programs worked the same way... but the fact was that all the programs didn't work the same way, because (just as for text files) they all handled their own files and didn't handle anyone else's, and you still had to have utilities to convert data from one format to another. And you had to do it for everything.
When you're designing an API, look for simple metaphors. Look for a model where most of the time you don't need to specify any complex parameters or callbacks or helper routines. Leave a way to hook extensions in, sure, but for most software you should be able to do 80% of the things you want without having to turn to the second page of the documentation.
I'm probably going to be shouted down but in my 30 years of coding, I *rarely* reused code. Platforms change, toolchains and libraries change (glibc vs libc6), languages change, system architectures change (heavy client, client/server, n-tier, distributed) and system requirements change.
Example, a lot of what I have done over the past 10 years uses some standard navigation libraries that probably could have been 100% portable. Lat/lon to range bearing, rb2ll, etc. We've never even discussed IF it would help to make a single standard project library, even though I can absolutely tell you we will rewrite these again on the next platform.
I can't even look back on 10 years of coding and say "Oh things would have been so much better if we had shared code". I don't think that is the case. And fwiw, this is teams of 5-20 programmers on significant projects.
Without RFTAing, I would estimate that it's 95% certain that the question behind this story is "How can I get a few thousand people to hit my ad-laden page?" And the answer is "Anonymous posting of a link to Slashdot."
I reluctantly have to say that if we want to avoid writting unnecessary code, we should abolish emacs, not vi.
I'll miss it :(
Rethinking email
I tire of people who claim that _anything_ we do helps to "save the environment". Everything we do helps to _destroy_ the environment! So long as the "saving" factor is less than 100% of the damage we produce, we have done nothing to "save the environment".
I'm sick of the "we want to have our cake and eat it too" attitude people have over these issues. The way corporations and the majority of consumers live today, almost NOBODY can claim to care about the environment. If you own anything manmade, you've directly contributed to the planet's destruction. Yes, really.
I think the article actually hints at a deeper problem. If we broadly divide programmers into categories:
1. Code monkeys. Write code, happy when it kind of does what is required.
2. Architects. Design and implement libraries and their APIs to make stuff easily usable.
3. Ontologists. Design and implement philosophical frameworks that make big systems work.
then we can put LISP macros somewhere between levels 2 and 3.
In terms of reuse, level 1 code should just be ignored, level 2 code is a good candidate, and level 3 ideas will be automatically reused.
Unfortunately, it is natural for programmers to want to crawl up the scale: code monkeys create bad APIs; architects create bad ontological systems; ontologists wander off into category theory. Sometimes, the developer gets it right, but 90% of the time she just leaves an attractive nuisance lying around.
Given a big system (say 1m+ LOC,) I want something like 3 ontologies, 100 subsystem APIs, and 3000 enduser things (reports, feeds, GUIs, etc.) If I see another 5m LOC system with hundreds of AbstractFactories and XXXFacades and YYYAdaptors, I am going to start shooting people.
I strongly suggest he read a few (5 or 6 year-old) books on Agile programming techniques, and maybe start working in a modern language like Ruby.
Do not misunderstand! I do not dispute much of what he writes. The problem is: what he writes about are old problems that have already been addressed by others. Maybe he should spend a bit of time studying what others in the industry are doing/have done, before wasting his time writing what others have already written, and better. Far better.
If you want to be a cutting-edge programmer (which is what you had better be if you are writing about how others should write their programs), I think it behooves the writer to be more-or-less up-to-date on the subject himself.