|Problems? Is your data what you think it is?|
i in no way meant to insult anyone.
If you want no explanation for what i said, stop reading.
When i was talking about use strict not working well under the situations, i was designing a natural language processor that took user input strings and, well, processed them. The system was a learning system, which meant it had to be able to rewrite its own code as well. NO other language but perl can do anything like this that i've seen. (i don't count lisp because it has other problems)
The setup i was going for used nouns, verbs, and modifiers. A noun and verb are easy to set up and use. The modifiers were a royal pain. They could modify things in every which way and they had to stay organized and play nice. When i was taking a generic user string, and putting it through all these inane processes to find out what that string 'meant', i looked and looked for better ways to do things. Given the complexity of the modifiers, there seemed that other solutions had other problems with them. The set of problems inherent in the design i chose were the problems. The problem had nothing to do with perl being able to or not being able to do something. So to stop this long story, i got out of some of the problems i had by not using strict and using loopholes that strict would have caught, then patched up the loopholes as best as i could.
It's not a good solution, i know this. i'm sorry i ever said what i did,
but i can't take it back (time is only one way unfortunately).
So, yet again, i'm sorry. Maybe i should explain more, but most likely
i should just talk less (and anyone who read through all this garbage can agree
with that =)
In reply to RE: RE: RE: My crime of choice (i'm sorry, apparently that didn't come out right)