Reusing and Recycling Code 114
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. "
Saving the environment (Score:5, Interesting)
Seriously!
Re: (Score:2)
Interesting point, although I really think they would view this more as a time/cost/boredom saver.
Re: (Score:3, Funny)
It's "reduce, reuse, recycle", so we should first try and reduce the amount of unnecessary code that's written, especially when it just duplicates functionality we already have.
Development of vi will now cease. And Gnome.
Re: (Score:3, Insightful)
I reluctantly have to say that if we want to avoid writting unnecessary code, we should abolish emacs, not vi.
I'll miss it :(
!saving environment (Score:2, Insightful)
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 dir
Re: (Score:1)
Sometimes, rarely, I read something on slashdot that's remotely encouraging. This is one of those rare times. I know the parent you replied to was kind of tongue in cheek, but in the context of mass corporate greenwashing this response is golden, and I thank you. Anyone with mod points please mod parent up.
Re: (Score:3, Insightful)
Uh i tire of people who think that we humans are somehow not a part of the environment... and that everything we do somehow is "destroying it".
We are a part of the environment and what we do certainly changes it but that doesn't mean we are destroying anything.... in fact the law of conservation of energy states very explicitly that we are quite incapable of destroying anything at all. We can only change things.
Now given that we can and do change things, some changes we make impact ecosystems which otherwis
Re: (Score:2)
At one end, people sitting in their caves, scared of any change, afraid of abandoning the place that gives them a false illusion of being safe. It's okay to be there, as long as you're fully aware of why are you there.
At the other end, people who are afraid of nothing, who consciously jump right into "the danger", laughing at everything the people of the first group are scared of. They want to live their lifes, embrace whatever the future brings, be happy no matter what it takes to
Re: (Score:2)
you do know that is how we managed to climb our way out of the muck right? Just swap out "iron dust" for "oxygen". Then later oxygen became less plentiful which is why we no longer have giant insects roaming the earth... and for millions of years the oceans were more acidic than they are now... still life managed to thrive there.
Humans are an environmental effect like any other... volcanoes, earthquakes, massive land fires, meteor impacts... they all wipe out life and ecosystems. They also leave new ones be
Nothing to see here.... (Score:5, Interesting)
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.
Re:Nothing to see here.... (Score:5, Insightful)
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.
Shooting libraries and ontologies (Score:1)
Will you come up with a one-off method of assassination, or will you create a nice set of assassination instructions that can be reused?
Or will you clime the scale and come up with some philosophical framework to best keep idiots from doing jobs they aren't qualified to do?
Recycling isn't always good (Score:2, Insightful)
Re: (Score:3, Interesting)
This assumes the code is good. If it isn't, it's akin to eating your own vomit.
In my current project we are using a third party library that is very powerful and comprehensive, but the API is overly complex and poorly documented. It takes a year or two before it stops being mysterious and becomes merely frustrating. Writing code that is easy to re-use is an uncommon art.
Re: (Score:2)
Then why are you using it? Find a better library, or create a facade in front of it that provides a better API.
Re: (Score:2)
Then why are you using it? Find a better library, or create a facade in front of it that provides a better API.
We have to use it because this stuff dominates the market niche we are in. I tried the facade approach in my last project but, unfortunately, my approach didn't fit in very well with the way the chief architect wanted to do things. I am starting a one person project, now. I am planning on giving it another shot. Of course, if I don't do an exceptional job, it won't do anyone any good.
A great example of code re-use (Score:5, Funny)
Re: (Score:2, Flamebait)
1977 called. They want their name resolution system back.
Re: (Score:2)
Oh he's just enjoying his walled garden... I'd say 1996 called, it's AOL and they want their business model back.... ;-p
A great example of Slashdot re-use (Score:1)
Who cares about Ubisoft? (Score:2)
Ontological Typologies? (Score:5, Funny)
Re: (Score:1)
I wonder what is the difference between ontological typology and typological ontology.
Re: (Score:3, Funny)
I recently read through some policy documents at my work. The introduction had a paragraph about how "...notoriously expensive documentation is..." to write and maintain.
The next sentence was all about making said documentation leaner and thus less expensive. How is that done? By aligning with the principles of [some phrase written in latin] (!), and through "...the principles of ontological parsimony (!)". No Shit!
I had to use a dictionary to work out what the hell it was saying.
Talk about the very definit
That guy is management material! (Score:5, Funny)
A programmer who says so little in so many words is a rare sight. Promote promote promote!
Re:That guy is management material! (Score:5, Funny)
EXTERMINATE! EXTERMINATE!
Re: (Score:2)
EXTERMINATE! EXTERMINATE!
See, even Daleks hate the management.
Re: (Score:2)
Steve? Is that you? Can I have my chairs back..?
Knows his stuff (Score:1, Insightful)
A solid recommendation from an insightful article. Should be in every corporate coding guide.
Re:Knows his stuff (Score:4, Funny)
Titration, titration, titration (Score:1)
Precision is important.
what the hell is the question? (Score:4, Insightful)
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...
Simple (Score:3, Insightful)
Hell is other people (Score:5, Insightful)
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.
Re:Hell is other people (Score:5, Insightful)
And it's a real shame, too. Some of those guys actually are as talented as they believe themselves to be, and if they weren't such assholes, could have made the team better by showing the others better ways to do things. And no, I don't mean hand-holding or playing teacher, but just the influence of having the others see what really good work looks like. Leading by example, in other words.
These guys aren't useless, however. There are problems that are well-suited to single-handed solutions. Just keep them far away from anything that requires close collaboration, and both they and their employer's will be happy.
Re: (Score:1)
Typed like a true emacs user. Heretic!
Re:Hell is other people (Score:5, Insightful)
Ah well, sometimes I think I am like that. Often, really. Yes: Actually, I do think that in comparison with everybody in our IT department, I am a better coder, and a better architect, and a better ontologist. Arrogant nuisance? You bet.
So, from a certified jerk's perspective, let me tell what we need to be effective members of a team: An effective sparring partner. Seriously. What makes me a frustrated, tired and emotional team member, is that so many supposed team meetings are only unidirectional exchanges. Sometimes I sit there and watch the other members of the team grinding their way through all the little problems of system integration. Sometimes they sit there and watch me sketch a new ontology, architecture and object model.
Such a grouping of people is not a team. It is a group of people sitting in the same room, but at cross-purposes, because we are not talking at the same level. At best we succeed in confusing each other, at worst only in boring each other. I think they are parasites. They think I am an arrogant jerk. Rate of progress, in that constellation? Nil.
Yet I can work in a team. I've worked for years in highly effective teams, and with success. I can tell you what made all the difference: The presence of equals to debate issues with, so that we could talk each other through the problems and emerge from the session with the feeling that we had defined better solutions. Perhaps we are all arrogant nuisances, but as long as we understand and respect each other we keep each other in check, and can function as effective team members.
The moral of the story, as far as I am concerned: Effective teams need a core group of several people with the same high level of skill. You can put in a few people with less skill, so that they can learn from the others. But you should never try to assemble a team of one wolf and five sheep, because that becomes either a classroom or a dinner opportunity, never a team.
Re: (Score:1, Redundant)
Oops. Wasn't logged in. Let me say it again:
Well said.
Humble experts can "sparr" with themselves (Score:2)
If you'd like to be able to be an effective leader even in situations where you're clearly the best, but you feel the need to have some push-back in order to do that - why not try second-guessing yourself? Surely you've programmed something single-handedly at some point - were you able to be an effective one-man "team" even though you had no equals? Of course, because you come up with a plan and then think it over, look for holes, better approaches, etc - and can usually give your first attempts a run for t
Re: (Score:2)
Hi RexDevious,
I do agree with you, that someone striving to be an effective leader has to treat all their team well, and somehow handle the difficulties including wanting peers at their own level.
And that we all have to program something by ourselves occasionally.
And that "sparring with ourselves" is useful.
But I think the GP is right too, it is really useful to have at least one peer who is about equally skilled and has complementary knowledge.
I think that becomes more important with complex projects that
Re: (Score:2)
Actually, I am or was not the leader of those teams I was referring to. In my experience it matters relatively little who is the 'top banana', as you put it. I have been in team meetings of all kind of composition, and I find that the key to successful teamwork is to have people with the self-confidence and skills to have an effective debate, regardless of whether they are junior or senior.
The necessary condition for reaching the kind of inspirational educational context you describe is that there should be
Re: (Score:2)
Glad to hear back from you. While I fully agree that having equally great minds on a task is ideal (for the same reason that you don't let programmers QA their own work: you need different yet equally valuable perspectives); it sounds like the immediate problem your facing in the less-than-ideal situation of not having that stems from the attitude of those who must eventually give ground.
My personal attitude when someone else must call the shots, set the agenda or whatever - regardless of how I feel about t
Re: (Score:2)
Well put. I have to agree with you: I've been in a similar situation for the last few years, as the only really experienced programmer, contracted to a company that needs a lot of IT development but doesn't have programmers to do it.
It's been very enjoyable to be free to explore the design space as I like - I appreciate that. Some really interesting stuff has come out of it, that will do me well for years in other situations I'm sure. Lately I've come to realise that what I'm doing is at the forefront of
Re: (Score:2, Insightful)
Success isn't about a paycheck. Past a certain pay grade the money ceases to be a factor.
Actually, after a couple of decades in IT and enough financial inertia along the way to avoid becoming rich, success is **only** a paycheck. I see the march of cybernetic progress as a superstructure upon which the march of coral-like growth of business and science proceeds. It proceeds, by and large, by the energy system known as money economics with a few motivational impurities thrown in for colloidal structure.
Very, very few of us code monkeys have reached that pay grade where money ceases to be a fa
Re: (Score:2)
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.
A bit harsh perhaps but I agree with the gist of the post. A small, tightly knit group can work bigger than a room full of dysfunctional developers. And working alone is more productive and less stressful than working with idiots. It's really difficult being trapped in a team of people you didn't have any say in picking and whose skill level and motivation
-1 brain fart (Score:2, Insightful)
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
Simple metaphors... (Score:5, Insightful)
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.
Older OSes (Score:2)
Here is a full book about Unix written by people who have used older operating systems - Click here [wikipedia.org].
Re: (Score:2)
Dennis Ritchie's response [slashdot.org] to the above-linked "Unix-Haters Handbook"...
The complexity-lovers handbook. (Score:2)
Yeh, I've talked to some of the people who wrote that book. You know that bit I wrote about having to understand how a database engine works to open a text file? That's exactly the kind of thing they're unhappy about losing. Oh yeh, lots of misplaced nostalgia about the DECsystem, which I used and found at best lesser evil than IBM... it was still full of the same kinds of needless complexity and internal incompatibility.
Re: (Score:2)
Still, a noteworthy goal.
Re: (Score:2)
Old School Old Fart (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
Donald Knuth recently said [informit.com]: "I also must confess to a strong bias against the fashion for reusable code."
Personally, I think a lot depends on the sorts of things you do, and (probably more importantly) the way you tend to think. A few decades ago (or so) when I started college, Pascal was the cool new thing, and top-down development was going to save the world. At least IMO, top-down development has some very g
Re: (Score:1)
Re: (Score:1)
I find that the best reuse comes from not over-engineering stuff for genericness. If you keep it simple, then its easier to adapt for another project. If you try to stick every conceivable feature into it, its too hard to change for those features you missed anyhow.
Thus, keep your reuse-able libraries simple and full of small independent or semi-independent parts that can be used, changed, or ignored as needed. Date frameworks, don't marry them.
Re: (Score:2)
A reminder: reuse != building libraries. Copying a piece of code is also reuse, even if you have to hack it to make it do what you want.
I find the more code I write, the more I cut & past
Re: (Score:2)
Don't Repeat Yourself is a good principle.
Re: (Score:2, Interesting)
You also have a hidden point in there. A lot code is just not useful for more then the app it was originally designed for, and breaking it down into smaller modules and functions usually just creates simple loops or recursive functions, and thus no point in saving them for later use as they can be replicated in the same amount of code space.
I don't really understand what the OP is trying to convey, anyone who has learned programming in the last 5-10 years (probably longer) from a half way decent school shou
Re: (Score:2)
If you want reusable code, buy a package, or a library from somewhere but know that when y
Re: (Score:2)
I think that code should be reused at the point when someone is writing something that has been written before. At that point it is IMHO better to rewrite the old code into a shape that both programs can use it, so that they both can share that code.
Simple reasons:
- Now you KNOW that this code can be shared aka reused. So it won't be used by just one application.
- If you needed that code in 2 applications, there is a high chance that you need it in others also.
But this is often not done, because short term
The exact thing.. (Score:1)
Re: (Score:2)
There, fixed that for you.
Seriously, looking at the website, it looks more like what I'd expect from a project still looking for funding, not something that's supposed to be close to completion. In particular, it talks about objectives and such, but doesn't seem to have any code available for download/testing. By my count you've used up about 18 of the 30 months for which you were funded, but if there's anything to show for that
Pontification (Score:5, Interesting)
That's quite a rant on programming for a Javascript form field validator.
The right answer to this problem was probably WebForms [whatwg.org], 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.
Re: (Score:1, Informative)
First off your example is flawed. Not only can credit card numbers be 13-16 characters - CC type validation is useless without applying the mod10 check algorithm to the field.
My point is while there is utility in pattern matching via regular expressions webForms themselves won't solve everything and you can largly solve the problem already with a dizzying array of javascript validation functions freely avaliable online which essentially do the same thing on all browsers today.
For example instead of extendi
Re: (Score:2)
I realize this is almost certinaly preaching tothe choir, but:
> Not only can credit card numbers be 13-16 characters - CC type validation is useless without applying the mod10 check algorithm to the field
The trouble with this is that one must always validate input server-side, as the user client can never be trusted. The web application must always assume that bad data will come in, by intent or accident.
So, the point of client-side validation is to help avoid the most likely accidental mistakes: make s
Re: (Score:2)
I'll show you metaphor... (Score:5, Funny)
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."
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
I think you mean int main.
Please refrain from insulting people (Score:2, Offtopic)
``project mana-jerk''
It took me a while to understand that, until I realized he probably meant "manager". While I see the joke, I think it is insulting to managers in general. While some managers probably are jerks, I don't think insulting all of them is a good idea, and I would ask that you not do that.
Re: (Score:1)
Completely agree...
I've been through all roles in an IT dept; from Helpdesk in my younger years, to Developer, Sysadmin, Infrastructure responsible and now Demand manager (that is, I lead the IT projects for our business clients) and I have always thought that within IT our main problem is that we really don't know each other, we don't understand how important is what "that other jerk" is doing for the whole process and we think that what we do is "the most vital part"... So, we insult, since we don't under
Re: (Score:1)
Haha, when I read "mana-jerk" my first interpretation was to define it as a jerk who was stealing everyone's mana...been playing too many video games as of late I guess.
A Master of Masters... (Score:3, Interesting)
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.
Re: (Score:2)
(Tongue planted firmly in cheek...)
Kidding aside, I do take great pride in creating reusable code. The downside is that the lifetime of software is so short it all gets tossed aside eventually, anyway.
Databases, on the other hand, do tend to hang about a bit longer, and so the pride factor increases by several orders of magnitude...
Sorry, couldn
Wii, for example? (Score:1)
synergy (Score:1)
100 comments and no one mentioned my PHB's favorite buzzword :p
Master of the Obvious Award (Score:1)
"The magicianâ(TM)s spell is our codebase, and as they toil in their laboratories collecting newts and dragon finger-nails, so we assemble libraries or components and frameworks."
Yeah, that's what I do at work all day.
Re: (Score:2)
I'm neopagan, you insensitive clod!
This guy is behind the times! (Score:3, Insightful)
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.
Quoting Robert Love. (Score:2)
On code reuse.. a flexible driver.
From the Book Linux Kernel Dev.
more or less..
"provide mechanism, not policy"
The policy is WHAT (data) they want and WHEN (time/event).
The mechanism is the HOW (language, libraries, ADT's, Architecture(eg. I'm going to use a generic container class, or No1 I'll use an array..or no1 I'll use pointers to my managed memory, and a huge private library of home-brewed accessor methods).
Of course the WHAT will change before you can say "blue berry pie". Will that derail your HOW..?