/me takes a pop at meditating...
In my years (3 whole years) of perling I have discovered the fantastic cpan. Naturally.
I have made extensive use of it's resources, and even thought of contributing several times (I eventually backed out because I thought I didn't write mature enough code).
Perl being my only practical (or real) language learnt and actually used, I know that whenever I need something done there's always cpan, and that's all I know. Fabulous modules like the various DBM modules, Storable, Time::Local, and URI to list a few, are what gives Perl the margine between great and fabulous - resourcefulness. These modules have something in common.
Recently I've been working on a project which does a lot of OOP. Everything within is an object, is created by another object, or is responsible for dealing with objects. Some of these objects require persistency, within a database. These objects are actually a unity of an object describing how to find the resource the object represents within the database, and another representing the database itself. Such objects can also be created right into the database, and in the end it all gets translated into SQL. I've finished planning their representational core - what are these objects actually, and how you work with them. Now comes the implementation.
Hopping on to cpan I delved into the many DBIx::, SQL::, and whatnot namespaces and modules. I've read pod after pod after pod. Everything is different, so powerful, so clean. These abstract DBI access so gracefully, and yet there's always something wrong. Each of these modules has something so alienating about it - it's not me. I'll never remember the non minimalistic API, because it's not minimalistic and it wasn't thought up like I would think it up. I end up wrapping the wrapper in more wrappers. I hack a method, I use base;. In the end the mishmash that comes out is so ooky I'm scared of it. I get to the end of the doc and back up the trail of hypothesis that my mind walked about. I decide not to use the module. After pod.
I contemplate reinventing the wheel.
I'd like to object about the metaphor 'wheel'. A wheel is good to analog a module like Time::Local, or Storable. A wheel is simple. There's one way to use it - an axel. It rolls on the axel, and reaches a point. Perhaps I'm going too far with this, but here's where my problem is. The modules mentioned above, those I decided not to use, are not really wheels. They have so much whiz bang about them, so many different things that they (can|are supposed to) do, that they look, in the metaphorical sense of course, more like a spaceship.
I contemplate reinventing the spaceship. Why is this wrong? Reinventing the wheel is wrong, unless you're looking to learn something from it. But you don't learn much from reinventing a wheel. Reinventing the spaceship, however, is not as wrong. I like programming in straight diagrammatical lines. Everything either contains other things, or is wheel. A program is a simple set of complex elements. Each complex element is a simple set of tools. Each tool is a simple set of wheels. That's how I see it, and that's how I program. Those complex elements are not seamlessly integrated into my program because they force complexity on their bounding set. My solution is to rewrap them, as I mentioned, by something that works better with my way of thinking. In my spaceship I hide the electrical circuits under a nice, big, round button. This helps me create stable code, because everything is delegated downwards, broken down to it's simple parts. The button has one way of working on the outside, and on the inside it connects to the right things.
I have another problem. I like the button to be a button, and to be round. I don't like having to pretend a lever is a button. And usually there isn't a button just the way I like, because the button is not just for me. It's for hundreds others like me, some of which like levers, and some of which like a star trek female voice thing, or whatever.
Perlwise, what i mean is that these modules are either too bloated, or minimalistic in the wrong way for me. And I don't blame them. You can't make something of this sort simple, because it's not a simple thing. There has to be a choice of what to give access to, and where to stop. What the objects, if any, are responsible for handling and what they are. You cannot live up to everyone's expectations in such a complex model, because simplicity here is not minimalism, but simple mindedness.
A hypothetical solution for this is to distribute wheels, and let the people back at home roll their own spaceships. That's a nice solution, but usually seems a bit unfair to the people back at home. Why are they getting half of something when they could be getting something whole?
At the bottom line, big things scare me. Simple things project a laziness, unless they're supposed to be simple. I end up doing the big things on my own, so that I can use them properly, and feel comfortable about it. I save time in the long run, and learn more on the way. To me this concept is like building a toolbox of my own, for use on a project. The tools are mine, and rely only on bits from other people. This is (what I haven't|not what i have) learned from perl and cpan.
Perhaps it's because I'm quite harshly dyslexic, and can't easily understand the documentation completely. But if not, I post this up for discussion, so that others who may have felt the same may comment, and help me in making a wiser decision.
Update: I'd like to apologize for my replies to everything. It seems childish from my point of view, and my reaction is - I am uncomfortable feeling that i've caused confusion regarding what I think. For some reason it seems to me as though I pushed the debate far away from what I intended it to discuss, and thus have a last-word reaction to everything. I'm sorry. -nuffin zz zZ Z Z #!perl |
Re: Reinventing the spaceship
by perrin (Chancellor) on Apr 08, 2003 at 17:44 UTC
|
I see this problem all the time. Because I wrote an article about templating systems, I often get mail from people who say "hey, I have this great new system that I built." I look at it, and it's very close to one that already exists, but with a fraction of the functionality and polish. I point this out and I hear "well, mine is smaller and faster." Then I point out that it's smaller and faster because it doesn't do a whole bunch of things that any non-trivial system requires. Then I hear "well, I looked at that one but I didn't really get it."
It's a common problem. One thing I tell people about this is that it's okay to grab a CPAN module and hack it to pieces so that it works just the way you want it to. I've done that before, and it saved me time. Yes, you have forked the module at that point, but you also got a solution that works with minimal effort, and there's a good chance you will be able to either release your version or merge future changes from CPAN into it.
Not everything on CPAN is great, but some of it is. If people are telling you "hey, check out DBIx::Padiddle because it rocks for what you are trying to do" then you should really put some effort into understanding it. Big modules can be scary, but usually they are big for a reason, and writing your own version will not be as simple or as fast as you imagine. | [reply] |
Re: Reinventing the spaceship
by BrowserUk (Patriarch) on Apr 08, 2003 at 20:52 UTC
|
I don't think you should feel the need to apologise. I've just read the thread 3 times and see nothing much for you to apologise for:)
From my perspective, CPAN is a great idea, and much of what is on CPAN is great too, but some of it is not-so-great, and some is not good at all.
If there is one single critisism that I would level at CPAN--and I know I will take a hit for saying this out loud--it is a lack of coordinated design.
This manifests itself in several ways:
- Modules that provide one extremely useful and needed facility, that carry a burden of "flesh it out" code in order to justify the modules existance.
I won't cite examples as I have stepped on toes before, but there are several modules that I have installed, and many more I have rejected, that provide something I need, but carry so many extras that I don't want or need.
Would it not be possible to provide the core functionality as one module that is as light and efficient as possible, and where there are nice-to-have or logical-extensions to that functionality, then provide these as add-ons that sit below the main namespace and that can be installed as an option.
This segregation would have several benefits:
- It would become clear from download statistics which parts are most used and which are not.
- It becomes easier to download and install.
- It becomes easier to document.
- It becomes easier to read the documentation.
- It becomes easier to maintain.
- Another problem is the lack of a coordinated style of interface.
A couple of times I have tried to use two or more seperate modules from CPAN together, and found myself having to write glue-code in order to get them to work together. A typical examples is where source data is read from some source other than a file and then needs to be processed in some fashion by another modules that will only accept a filename or a filehandle as the source of its data.
You might say that why complain about writing glue code if 90% of your application has been done for you, but the problem is often that the glue code required spends time undoing stuff that one module did, in order to supply the intermediate data to the second module which promptly redoes it.
Okay, so I can modify the source to avoid this.
The downside is that then that everyone ends up modifying the sources of the modules--each in a different way--to fit their particular needs, but it is impossible to feed these changes back into the original module as doing so would either:
- Break existing applications.
- Or add weight to the original module by providing multiple interfaces.
- There are often inconsistancies within the interface of a single module.
Again avoiding directly naming them, but one of my favorite modules in terms of the functionality it provides, also gives me the screaming heebee-jeebeies every time I use it because the interface is so inconsistant. Some of the function names are CamelCased(), some of them are underscore_seperated(), some of them are A_Combination_Of_The_Two(). This forces me to have to look the details up each and every time I use the module--which in this case is itself not an easy task as the documentation is so volumnous, but I get to that next.
- Documentation.
Many modules suffer from bad documentation. The ways in which it is bad span the whole spectrum. In some cases, it is too little, in others too much. In some, you have reference material mixed up with tutorial material with FAQ material, and in some cases volumous background and research materials.
This isn't intended as critisism, it is simply meant as a statement of fact.
Documentation is a thankless task. Not only is it hard to do, but no matter how you do it, it will always be subject to critisism.
- There is considerable duplication on CPAN.
Not only duplication one whole module by another whole module, but also, and more difficult to address, duplicated functionality as small parts of several modules. Anyone care to count the number of different modules that could be used to do URL encoding? It should be possible to isolate those parts into a single, seperate module. It might make sense to then combine these seperated small functions into one or more 'utility' modules in much the same manner as the POSIX module, which despite its size and diverse function, imposes a relatively light overhead on programs that use it because of its design of only loading those functions requested. This is a model that could be used more.
- The is some proportion of the modules on CPAN that are badly implemented. Depending on what you read and where you read it, so the characterisation of the percentage involved varies, and no doubt that characterisation will vary upon individual experiences of using (or attempting to use) the modules in question.
- There are modules, including well used and well supported modules, that lump a great deal of functionality and in some cases multiple interfaces into a single monolithic lump. Wouldn't it be better to seperate this functionality into several modules? Perhaps the procedural interfaces in one module and a seperate module that wraps the procedural interface in an oo-style one?
- Last, but not least, there are quite a few modules on CPAN that have fallen out of support. It is not easy to determine which modules these are. How do you tell the difference between a module that hasn't be upgraded for a couple of years because the author lost interest, or the time to maintain it, or because the module is stable and efficient, or because it has been superceded and noone uses it anymore, so there are no bugs raised against it and so no incentive for upgrades?
Having nailed my colors to the mast on things CPAN related, it is tempting to try and propose solutions to the critisisms I have outlined. I will refrain from doing so as I am aware that my relative newness to the Perl community, and my total lack of contributions to CPAN will make any proposals I do have--which are many--come from a foundless base.
What I would like to do is see if there is anyway that I can contribute to a resolution to the issues I have identified and the first step is to enquire if there is sufficient support for starting a movement to address those issues.
Do enough people within the community consider some or all of the above to be problems?
Is there any support for moves to 'fix' those problems?
Is this a suitable forum for raising the issues and coordinating efforts to do so?
Often the biggest issues in attempting to resolve issues of this type are
- Finding enough people with enough time to contribute to persuing the tasks.
- Coordinating the efforts in a way that allows wide participation.
- Embuing the efforts with sufficient authority to make the exercise worthwhile.
Personally, I can find time to contribute to the process, and I have had some experience that might contribute to the coordination and development of some solutions. The area where I can not contribute is that of authority. My lack of standing withing the community means that I could never lead such moves, but if there is any will to address the issues, I would be only to willing to contribute in any and every way I can.
Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.
| [reply] |
|
|
and I know I will take a hit for saying this out loud
Why do you feel the need to mention that? Being a rebel doesn't gain you anything, being coherent and cogent will. I briefly considered refusing my upvote you otherwise earned, due to this remark.
This segregation would have several benefits:
I don't see these anywhere near as clear-cut. It would certainly not be easier to install a module tree than a single-file module. Maintenance could be easier or it could become harder. Documentation can certainly suffer; I've seen a lot of badly written modularized documentation where you constantly have to crossreference two or three other PODs (and look for the bits in question in those as well, of course) just to find out simple facts. I've also seen huge, very well-written monolithic PODs, though rarely.
.. the glue code required spends time undoing stuff that one module did, in order to supply the intermediate data to the second module which promptly redoes it.
...
There are often inconsistancies within the interface of a single module.
...
.. duplicated functionality as small parts of several modules.
Interface design is what you're complaining about here. Few people are good at interface design. Most interfaces out there, the overwhelming majority of them in fact, suck. Badly.
I say this not as a master of interface design, but as someone who is aware of his own inadequacy. I usually go through at least three iterations of responsibility distribution and interface redesign before I am even close to satisfied with my own code. And I rarely think my results are more than just about usable.
I think most people don't even go into that much effort.
It's like the difference between a top novel writer's books and a pupil's homework essay.
Many modules suffer from bad documentation.
Definitely. Most of them draw a rough and often incomplete sketch of the interface and leave it at that. Rarely do you see any discussion of how the parts fit together, and the joyous occasions there's actually useful, working and helpful example code to look are very few and far between. Ovid's HTML::TokeParser::Simple is one example of well done POD - although I do think the sheer volume of the examples makes the documentation harder to navigate, I've never had any problem looking anything up and finding it quickly. Of course, the self-explanatory interface plays a large part in this too.
All of these boil down to interface design on different levels (documentation is just another kind of abstraction), and aren't really CPAN specific at all. By and large, these problems tend to be just as bad outside the Perl world. We're just in the lucky position to have a well run centralized resource with lots of decent code in it whose concentration makes these issue that much more striking.
Yes, I agree. CPAN is full of half thought out (to put it mildly) stuff. However, I don't think there's any single and certainly no technical solution to these problems. They are not trivial to solve at all. I'm still glad the CPAN exists. The best we can do about it, I believe, is to be aware of the problems, and make an effort to address them in our own work. And of course, to provide feedback - if you have some gripe with a module, go over the source, meditate about it, and produce a suggestion or even a patch (but don't forget to explain your reasoning). Free software thrives on its users' contributions.
Makeshifts last the longest.
| [reply] |
|
|
Wow. This is an extremely long Note, but I'd like to make a probably-too-general reply, if I may. I agree with many of the problems of CPAN you pointed out, though I'm not entirely sure your major premise (that CPAN needs coordinated, overarching design) is necessarily inferred by those problems. Perhaps some gentle nudging by well-respected members of the Perl community would suffice. Or perhaps all it needs is a small amount of hacking on the Perl community itself. I'm not convinced that the anarchy-like Open Source method of development (which, to me, CPAN is a perfect example of, and ESR likes to call a Bazaar) doesn't have an answer to the problems you cited. In any case, I doubt there's going to be any strong policy put in place on CPAN -- that could be considered overarching design -- anyway. :)
| [reply] |
|
|
One effort to deal with this was the P5EE project. Some people wanted to do it by defining a set of APIs that are "P5EE" and then implement those, by writing new modules and retrofitting existing ones. This is sort of how J2EE works, with a central authority defining the APIs.
I prefer an alternative approach, which is to identify a set of high-quality modules which provide a complete toolkit for building most applications. It's very hard to do this in an "official" capacity, because people do have ego tied up in their CPAN modules and choosing one over another can get tricky. It would be easier as a sort of "branded" Perl distribution, although I don't know if P5EE is really the best name for it.
| [reply] |
|
|
I had never heard of P5EE, but after a quick google I see that it started out with similar ideas and intentions to those that have been building in my mind for a while. I also see from a few of the snippets I read that the original intent of "one really great way" fairly rapidly bacame a "collection of posssibly great ways" with the hope that one would become a clear leader.
I also saw that several groups that had considerable investment in one particular module or set of modules that were invited to participate by bringing their modules in line with the philosophies of P5EE pretty much rejected the notion outright.
Basically, I'd summarise what I have been reading as several groups decided to form teams which diluted the talents and efforts, and others simply didn't want to play, which is a shame. The biggest problem--other than the aweful name:)--would seem to be the blue-sky starting point of the project. A large number of well-thought-through and desirable subprojects and goals, but probably too much and too wide-spread to be successfully tackled as a voluntary, cooperative effort.
I wouldn't mind betting that some considerable efforts have already been done to define and integrate a rationalised subset of the total that is CPAN by various large-scale users of perl already. If only it were possible to obtain the high-level criteria from a few of the more successful of these, it probably wouldn't be too hard to find common threads and strategies within them that could be used as the basis of a rationalised, integrated subset of CPAN that was based upon proven, real requirements, rather than idealised, blue-sky desires.
Thanks for the pointer to P5EE. I will spend a bit more time reading the google-droppings and see if the project is still active and if there is somewhere there I could expend some of my excess time and energies.
It seems fairly clear from the relative dearth of response here that I am barking up the wrong tree (again). Or maybe I am simply the wrong person to be raising the matter?
Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.
| [reply] |
|
|
|
|
The 'suitable forum' might be the Reviews section on PM.
| [reply] |
Re: Reinventing the spaceship
by chromatic (Archbishop) on Apr 08, 2003 at 18:17 UTC
|
I save time in the long run, and learn more on the way.
I find this hard to believe.
If I were to summarize your post, it would reduce to "I don't like these other things because I don't understand them."
Granted, there are modules with lousy interfaces -- some of them are in the core. Granted, there are modules that don't do their jobs very well -- some of them are in the core.
For all but the smallest jobs, though, I personally don't have time to research the laws of physics, come up with my own propulsion formula, and devise ceramic heat shields for my own spaceship. I've had far, far better success from learning to read code and documentation than by trying to write everything on my own.
I've finished planning... Now comes the implementation.
This is telling.
Perhaps the reason some of the modules seem too complicated is because you don't understand the problem space well enough. How can I say that? Because you don't have any code yet. I've never seen detailed plans for any significant project survive the first couple of weeks of code. Things change too much.
Of course, I'm not the world's best programmer. You could be a lot smarter than me and it could work out very well for you. In that case, just treat my post as a yellow caution flag waved from my experience. People prove me wrong all the time.
| [reply] |
|
|
You're taking my debate to the extreme. I don't mean researching the laws of physics for a ceramic heat shield. I mean reading the code for this and that ceramic heat shield which is in the wrong shape for me (set shape aside from physics a second), and understanding how it works. Then plagiarising the heat shield, to roll my own collage, more suitable for me.
I don't like these other things because I don't understand them - "I don't like these other things because I've tried to understand how to use them best, but it seems like more of a challange to write code which thinks differently than me"
I've finished planning... Now comes the implementation - Planning is very dynamic while coding. Planning is drawing itty bitty circles with names. It's deciding where the borders of what repsonsibilities the different parts of your code have. It's not how the code will work - that kind of planning does tend to break, i agree. I need this planning because otherwise i go a bit astray, and then I realize this will actually work very badly with the rest of the stuff, and i'm all frustrated because i have to do everythign all over again.
Surprising as it may seem I do share the ideas you propose here. It's just the proportion we differ upon...
-nuffin
zz zZ Z Z #!perl
| [reply] |
|
|
Good points. Though sometimes the issue is the author's problem space is just a little down and to the left of the users and there's no way to get there from here.
-Lee
"To be civilized is to deny one's nature."
| [reply] |
Re: Reinventing the spaceship
by LAI (Hermit) on Apr 08, 2003 at 18:02 UTC
|
++nothingmuch for accepting TIMTOWTDI into your heart.
Most, if not all, agree that CPAN modules are very useful. I can tell that you agree with that as well. But there is no good reason why, if they don't quite do what you need or want, you should force yourself to make do. Great, so you're willing to put in the time to build yourself nothingmuch::DBI. There is nothing wrong with that.
<advice>
If I were in your shoes I wouldn't start from scratch; I would probably use other perl modules as springboards. I'd look at the source of whatever module I was dissatisfied with and see how I could change the interface or workings of it to suit my own needs and preferences.
</advice>
I think that the important part of the 'Don't reinvent the wheel' thing is to not start from scratch if you don't need to. It doesn't say 'Use what someone else has written unless you're absolutely sure there's nothing.' If what you need is something that looks and behaves exactly like DBI.pm, use DBI.pm. If what you need is close, but not quite, use DBI.pm as a departure point and modify it. If you need something completely different grab your Rizlas and roll your own. Doesn't mean you need to reinvent the Rizla.
LAI
__END__
| [reply]
[d/l] |
|
|
The reason for doing this is, as i forgot to mention, that I sometimes find it harder to use a model whose workings I don't like than to rewrite something. Had I not first seen how it works on the inside, aswell as taken ideas from it I would probably not be able to make a new version of it as easily as I could bend my way of thought/code to accomodate it. it being a hypothetical module. I totally agree wth you.
On a hi mom type of note, i'd like to thank the insightful replies i've gotten to this node in a more general forum. Thanks!
-nuffin
zz zZ Z Z #!perl
| [reply] |
Re: Reinventing the spaceship
by jasonk (Parson) on Apr 08, 2003 at 16:52 UTC
|
The argument you are making seems to be that all you can find are small parts of a solution, rather than the whole solution itself, you want a spaceship and all you can find are wheels. If that's the case you are probably looking in the wrong place, there are plenty of complete solutions out there for many different problems, just most of them aren't on CPAN because CPAN is more about modules than applications. To use your spaceship analogy, CPAN isn't the shipyard, CPAN is the tool shed at the shipyard.
| We're not surrounded, we're in a target-rich environment! |
|---|
| [reply] |
|
|
I see your point, but it doesn't apply here, i'm afraid. This is not a one time thing. I'm not expecting CPAN to be a shipyard. I'm confessing the hard time i've had looking for a tool which I can work with well, but most of the larger (more complete solutions, not applications) modules have grown in a direction which i am not comfortable following. I end up using the same principal and core peices as they do, but expanding it to a place i feel natural working with the end result. I'm not totally reinventing the modules, i'm rewriting them to a dfferent form.
I hope this clears things up a bit.... sorry, i'm a poor writer.
-nuffin
zz zZ Z Z #!perl
| [reply] |
Re: Reinventing the spaceship
by shotgunefx (Parson) on Apr 08, 2003 at 20:39 UTC
|
There are good and bad things about reinventing complex applications just as there are good and bad reasons to do so.
Some Bad things
- *Sometimes* Wasted effort as far as the community is concerned. Though often this is not a programmers main concern
- Confusion and interoperatability. When there are many semi popular ways to do something then it becomes MUCH harder to get things to play together nicely. Everything outside of bits and gates is an abstraction and if everyone uses a different abstraction well...
- Potentially many differently defective spacecraft
Some possibly good things
- Innovation.
- Learning. Always good.
Sometimes, depending on the wheel, it is easier to just code your own then decipher someone elses. I would simply suggest if you are going to rebuild the ship, then take the time to examine what is wrong with the other solutions. If you can't fix the popular means, make a version that solves these problems and is flexible enough so that the next person can bend your vision to their needs and avoid having to do the same. Bonus points if you can make transition from popular existing solutions easy.
I've run into this with templates. I have yet to find any that work the way I think a templating system should work. Many do 99% of what I want but it's that 1% that can't be retrofitted that is the deal breaker. I also find many have syntax and implementation that just runs against my grain of thought. These issues are easier to deal with as translation is a possible solution.
I've been working on one that is radically different on and off (and over and over) for quite a long time. I keep refactoring it over and over and over, trying to get the right balance. (It's not just a templating system actually but rather a whole system of components for easing and securing network programming UIs) Hopefully when it's completed it will be done right (In my book) and once and only once and extensible (A lofty goal..) so no one else has to do the same (An impossible goal I admit but, aim high right?).
-Lee
"To be civilized is to deny one's nature." | [reply] |
|
|
| [reply] |
|
|
Syntax is a major issue. Though it's pretty easy to fix. I've used Template toolkit a few times in the past but decided after your post to give it a fresh look. (I haven't looked at it in some time) and it does seem to be a lot closer to what I'm thinking. Still dislike the syntax, but again easily fixed.
What I've been working on is a bit different from this. Without getting too specific, It's part of a more unifed way of looking at internet apps. More of a layer around it at it's basest level. Meaning that if you run a regular pre-canned script under it, it still gains some of the advantages. If you're app is aware of it, it can use it to great advantage wether it uses CGI.pm, HTML::Template, Template Toolkit or HEREDOCS. There is also a Perl-esque language to sit on top of it. It has many perl functions (var types too) but is not Perl. The interperater is written in Perl but does no direct evaluation of expressions or var access in Perl. Hopefully it will be fast but my main reason for doing this is for writing large applications. Not nearly as concerned with 1 ~ 2 page scripts. Of course it's a big undertaking and with something so intermingled, it's hard to draw the design lines clearly. (I'd like it to be extensible too, run under mod_perl, etc). When all is said and done, I might just scrap most of it and rewrite it to use existing tools but who knows. Who knows :)
-Lee
"To be civilized is to deny one's nature."
| [reply] |
Re: Reinventing the spaceship
by Juerd (Abbot) on Apr 08, 2003 at 18:36 UTC
|
| [reply]
[d/l]
[select] |
|
|
| [reply] |
Re: Reinventing the spaceship
by ehdonhon (Curate) on Apr 11, 2003 at 19:10 UTC
|
There's a reason not everybody is building spaceships. They cost lots of money, take a long time to build, and people often get hurt in the process.
If you have the resources to build your own ship, have a blast (no pun intended). I believe that you will find that as you build your own ship, you will inevitably come across the same tough problems as has the people that came before you. You'll have the choice of learning from them, or learning the hard way.
Food for thought.. if all of the resources that went into the space race were actually combined into one project instead of several different projects, we might be walking on Mars by now.
My point.. take advantage of open source programming by improving somebody else's space ship, not building your own. Replace a wheel or two if you have to, thats far better than having to come up with a few thousand wheels on your own.
| [reply] |
Re: Reinventing the spaceship
by Anonymous Monk on Apr 12, 2003 at 20:55 UTC
|
I think I'll start a new thread about using CPAN modules because this one is too long and complicated.
| [reply] |
|
|
