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. "
If you think about how much energy is needed to produce (good) code, recycling it will also help to save the environment!
Seriously!
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
To quote from the fine article itself:
My psychic abilities tell me you're wondering why this wall of text was worth your time. It probably wasn't.
What he talks about in terms of PHP is precisely what Lisp macros are about: you identify common patterns in your code, and then you generally break the patterns into a couple of short, generic functions and a macro, or sometimes, just a macro will do.
In any other language you build a library of functions, classes, etc. to do the common things that you want to reuse.
The above applies to PHP as well. It has the include filename construct for a reason.
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
Ubisoft shows us how its done!
Ontological typologies? Am I reading a philosopohy essay here?
Part of the hardcore faithful who believed in Apple long before it was cool again to do so
A programmer who says so little in so many words is a rare sight. Promote promote promote!
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.
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.
I prefer whiskey.
Assume I was drunk when I posted this.
That's quite a rant on programming for a Javascript form field validator.
The right answer to this problem was probably WebForms, which added support to HTML for basic form validation. WebForms provided for simple regular expressions in HTML forms like this one for a credit card number: />
<input type="text" pattern="[0-9]{16}" name="cc"
If the field didn't match the pattern, the browser would tell the user, in a standardized way, probably at keystroke time. The browser would also do things like prevent alpha entries in a numeric field, something that IBM green screen terminals were doing in the 1970s. (You could even program a keypunch machine to do that.) It's kind of lame that HTML forms never had any built in input validation.
For some reason, the WebForms proposal made very slow progress and never caught on.
ShadowBane strode into the room, his pale Night-Elf features enveloped in the shadows of his Technomancer robes. Before him stood the artefact, an eerie light emanating from its crystal face.
He sat on the throne, in one hand brandishing a strange rune-encrusted clattering device, whilst in the other he wielded a smooth object with wheels and levers emitting a demonic red glow. His hands moved swiftly and glowing runes etched themselves on the crystal device, spelling out:
"#include <stdio.h>"
He clicked again, and the runes mystically floated upwards. The next runes were even more cryptic:
"void main(int argc, char *argv[]) { printf("Hello world"); }"
He paused, taking a sip from his recycled aluminium goblet, then taking a sheet of recycled parchment and dipping his pen into a pot of genuine organic squid ink. Out of the corner of his eye he glanced a peasant rummaging through his garbage pile. He mused about all of this, then inscribed:
"I have unlocked a mystery of great potential. By invoking the sacred word of inclusion I have unlocked a compendium, nay a veritable library of invocations and chants. Like the peasant sifting through my rubbish, so can I reuse my incantations. These shall empower me further into my research for the solution to the factorial function, a problem of seemingly infinite complexity."