On Wed, Oct 30, 2002 at 02:07:12PM +0000, David Cantrell wrote: Since noone else has really argued this, I'm going to rise to it, as to me, Cantrell obviously needs a good kick up the backside.
> Remember, all software sucks*. But to say that "embedding application code > in markup leads to a poor (or non-existant) seperation of concerned, > typified by spaghetti code" is to talk bollocks. > * - and absolutism in software sucks absolutely? Erm. I'm afraid I don't agree, please explain how embedding application code in page rendering information can *not* lead to a lack of separation between the two. In my (possibly limited) experience, the lack of any rigorous controls of this separation, leads to the two getting tweaked to be closer and closer together until they merge. I'm afraid that I think your sentence above is more like talking bollocks (in the general case) than the opposite. > Yes, there are *some* > languages which might be said to encourage spaghetti. Assemblers do, as do > many dialects of BASIC. Right. We're agreed on *something* then. > But I see nothing inherent in embedding code in > markup that would encourage it**. > ** - depending on the lnaguage, of course. Embedded perl is fine, embedded > Sparc assembler would suck. OK, what do you see as the qualitative difference between these two. By your own argument, the code and data are still separate, so you just start your "code" tags, put some assembler in, and then close them. Why is this in any way different to embedding say perl/python/VB? The point is that you're mixing things which oughtn't be mixed, thereby asking for multiple people with different skillsets to be dealing with (different bits of) the same data. If you've got webmonkeys who won't be touching code, why is putting sparc assembler in the "bits they won't touch" any different to putting perl (assume for the sake of this that all the code maintainers speak sparc assembler as fluently as we do perl). Basically you're asking for spaghetti code, because the code is separated. (common functionality will have to be included from *somewhere* after all). I'm not quite sure what your definition of "spaghetti code" is. But I include in mine: chasing all over for the file containing the relevant module/method/ function definition. I feel this is a simple product of embedding code in templates. If this isn't, then the alternative is that there are multiple copies of the code all over the place, (which probably all work in subtly different ways). Any sensible software engineer will tell you that this is a bad thing, and quite honestly, I think you of all people ought to know better. > Therefore, when you *do* come across such > 'orribleness, and especially if it's in a language where spaghetti can be > easily avoided then the programmer is most definitely to blame. As I've argued above, I think your starting point, that "it's possible to write non-spaghetti embedded templates" is actually flawed, due to what I consider to be spaghetti code. In your examples, such things as "where does this hash get initialised" are important, and are then "spaghetti" in terms of following them. My point of view on this is that the programmer is to blame for not trying to properly separate out code and data in the first place. Embedding data in code is always going to be evil and bad and wrong. You want non-coders to be able to maintain the data. Any programmer who does mix the two unnecessarily is not worthy of the title. I dislike the term "hacker" in most software I write, because I think that the engineering and the future maintenance is extremely important. If you want to be a hacker, go for it, but don't claim that your code is designed for anything other than solving this problem now. If you want maintainable code, it is good practice to separate out your problem into multiple pieces. You simply cannot do that without proper templating, and any programmer worthy of the name would be trying to untangle said problem precisely so it doesn't turn into spaghetti. > > > And I maintain that *any* templating > > > language is code embedded in presentation. > > We can chop carrots finely with a food processor. Or we can duck out of > > the way and throw 15,000 knives across the room at high speed. > I fail to see the point of this analogy. If you disagree with me, say > so, and tell us why you think I'm talking arse. What Tim is saying, and FWIW, I think I agree with him on this, is "use the right tool for the job". It's very easy to say "well, my way solves the problem of chopping up the carrots", and it does, however, it's not in the long term the best way of doing things. In the same way, using a templating system which properly separates code and data will help you in the long run, though it be more effort in the short, but you will get yourself into trouble if you don't. He is disagreeing with you, I'm disagreeing with you, and I thinl you're talking arse. I've explained why above. I'm slightly surprised and shocked, as I thought you had more experience as a real programmer than as a hacker with limited clue about the problems he was going to leave for other people. Of course, I'd say take this a step further. I'd rather not see different languages mixing. I like to see clear interfaces. This includes, particularly Perl / SQL interfaces, which seem to be blurred in many ways, leading to many queries in many places that all do almost the same thing, but with their own subtleties. These are the bases for the balls of mud that our the spaghetti projects we all end up dealing with (among other things). You are right to suggest that if the programmer is good, he won't write spaghetti code in that language. You are wrong to suggest that this will be by embedding code in data or data in code. A good programmer will write with clear interfaces. Period. -- Lusercop.net - LARTing Lusers everywhere since 2002
