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.
This assumes the code is good. If it isn't, it's akin to eating your own vomit.
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.
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 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."
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 am currently a database manager where I work, but that title belies the complexity of what I have to deal with on a daily basis. We are producing our "next gen" web application whilst keeping the old, but money generator up and running under the pressures of increasing user load.
Even though I am the database guy, my vast experience with software engineering has given me a "unique" role in knowing the developer's side and having a lot of input on their design decisions, as well as having huge impacts on systems.
One poster mentioned not having access to various skills and expertise in a variety of areas, and yes, there's a lot of that at my shop, so I tend to try to "bridge the gap" as it were, to help my DBA team interactt smoothly with Dev and Systems, etc.
Code reusability is a big issue in our development of the NextGen system, because the old code (that's currently pulling in the $$$$$) is not supportable, being written badly in PHP4 has resisted all attempts to upgrade. The NextGen approach uses OOP ery heavily, and also relies on stored procedures to keep the SQL out of the code and allow my DBA team to tweak and enhance performance without impacting the code base. It makes for a sweet division.
But I do find myself doing lots of talking and less actual "hands-on" development these days. Kinda crazy running around talking to various department heads, managers, project leaders, QA, and the like.
I guess I am speaking to a greater issue than code usability -- human communication to keep us all on the same page and to allow us to leverage each other's expertise. All of our efforts together represent the future success of our endeavors.
Ruby Neural Evolution of Augmenting Topologies
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.