Re: [VERY OT] Inspired by closing comments from the UBB thread.
On Wed, 1 Aug 2001, Kyle Dawkins wrote: Mixing HTML with Perl with SQL is bad and evil on every single possible level. This bugged me... TMTOWTDI applies on so many levels. The right way to do something is not always the technically best way to do something. If you work in a large corporate enviroment with many hands in the development pot, then hey, I agree, and there should probably be a corporate document stating the guidelines and restrictions of developement. If however you work in a two person company where you have barely enough time to go to the bathroom let alone think about creating your own database abstraction layer for a custom application and maintaining code means changing a link once a month. Then by all means embed away, and take the quick development path over performance or maintainability. On the other hand, if you are completely broke and work on a non-profit project and the only system you have is a P200 with 64M of Memory, then you may want to think about avoiding templating systems, and doing nothing but a single module with embedded SQL with Perl and HTML. There is always more then one way to do it, and there's usually more then one right way to do it. Let's keep that in mind. Jay
Re: [VERY OT] Inspired by closing comments from the UBB thread.
On Wednesday, August 1, 2001, at 10:01 AM, Jay Jacobs wrote: On Wed, 1 Aug 2001, Kyle Dawkins wrote: Mixing HTML with Perl with SQL is bad and evil on every single possible level. If however you work in a two person company where you have barely enough time to go to the bathroom let alone think about creating your own database abstraction layer for a custom application and maintaining code means changing a link once a month. Then by all means embed away, and take the quick development path over performance or maintainability. This is, in my opinion, circular logic. Perhaps the reason that you barely have enough time to go to the bathroom is that you're writing the code the wrong way. :-) On the other hand, if you are completely broke and work on a non-profit project and the only system you have is a P200 with 64M of Memory, then you may want to think about avoiding templating systems, and doing nothing but a single module with embedded SQL with Perl and HTML. Assuming they're paying you anywhere near a living wage, their money would be better spent on modestly upgraded hardware than having you fumbling around with inefficient to maintain code. There is always more then one way to do it, and there's usually more then one right way to do it. Let's keep that in mind. Agreed. However, Perl + HTML + SQL isn't one of the right ways! :-) -- -- Tom Mornini -- ICQ 113526784
Re: [VERY OT] Inspired by closing comments from the UBB thread.
Tom et al. Mixing HTML with Perl with SQL is bad and evil on every single possible level. If however you work in a two person company where you have barely enough time to go to the bathroom let alone think about creating your own database abstraction layer for a custom application and maintaining code means changing a link once a month. Then by all means embed away, and take the quick development path over performance or maintainability. This is, in my opinion, circular logic. Perhaps the reason that you barely have enough time to go to the bathroom is that you're writing the code the wrong way. :-) H AH AH AH AH HA HAHAHAHAH brilliant On the other hand, if you are completely broke and work on a non-profit project and the only system you have is a P200 with 64M of Memory, then you may want to think about avoiding templating systems, and doing nothing but a single module with embedded SQL with Perl and HTML. Assuming they're paying you anywhere near a living wage, their money would be better spent on modestly upgraded hardware than having you fumbling around with inefficient to maintain code. Tom, I couldn't have said it better myself. BTW. The project I am working on right now *is* for a small non-profit. We don't have a P200 but we have a single P3 machine doing all the work. We don't have huge fault-tolerant systems or UML models or Java Class Hierarchy posters on our walls, or a coding team in Bangalore working on our project. All this notwithstanding, I have time to go to the bathroom. I can even take reading material with me. I have been in the two-person startup before... and let me tell you, if you think that you should cut corners now, it's just going to bite you in the arse later. Just because we use free and/or open source tools to build our code, doesn't mean we can write crap. We have an obligation to do our duty to whomever we work for, and LEARN and apply that learning to our work. There is always more then one way to do it, and there's usually more then one right way to do it. Let's keep that in mind. Agreed. However, Perl + HTML + SQL isn't one of the right ways! :-) Couldn't agree more. Just because TMTOWDI doesn't mean that all of those ways are equal. Most ways suck, in fact. Cheers Kyle Software Engineer Central Park Software http://www.centralparksoftware.com
Re: [VERY OT] Inspired by closing comments from the UBB thread.
My apologies for beating this dead horse... I am just unable to get my point across at all today. On Wed, 1 Aug 2001, Kyle Dawkins wrote: Tom et al. This is, in my opinion, circular logic. Perhaps the reason that you barely have enough time to go to the bathroom is that you're writing the code the wrong way. :-) ...my point with that scenario was that there is just too much work to spend the time writing highly maintainable code that has only the simplest of maintance tasks. Just because we use free and/or open source tools to build our code, doesn't mean we can write crap. We have an obligation to do our duty to whomever we work for, and LEARN and apply that learning to our work. There is always more then one way to do it, and there's usually more then one right way to do it. Let's keep that in mind. Agreed. However, Perl + HTML + SQL isn't one of the right ways! :-) Couldn't agree more. Just because TMTOWDI doesn't mean that all of those ways are equal. Most ways suck, in fact. Granted, the world is full of incompetance, but if you spent your time coding for a perfect world in every situation, you could still be working on the write-up while the next guy is collecting the check for a finished project and bidding on the next project, might not be bad code, might be really good code, might really suck, who cares, it works, the customer is happy and both businesses do well, the down side is some geek may have to maintain it but they'll get to complain about crappy code and show their rightousness on a public mailing list. Don't get me wrong here, I agree with the perfect code... I'd absolutely love to see a clean solution to embedded html/perl/sql that has fast performance, fast development and easy maintainability. I wish that the technically best way always matched the right way. And us righteous developers decided how the world was run. But my misintrepreted point is that there are situations in which this version of perfect code has no place, even if I can't write them up in an email.
