...the perl program uses dangerous, deprecated features...
Hm, isn't deprecation the decision of Larry and the pumpkings? You are which of those people again?
... impossible to write even the most basic of tools...
Did you read my first reply to this thread? I wrote a module that shows how you can prevent Perl from running this code and it uses the very features you decry.
If perl can't do that, perl should be fixed until it can.
Patches welcome. Wrongheaded patches not. Anonyperl fork permissible.
... when are all these dynamic mis-features going to be removed from the language, so that all the necessary productivity tools to prove correctness and language safety can be developed?
Perhaps when proof-carrying code and compile-time provability proves itself workable for real-world problems that do dangerous things such as reading data with contents unknown at compile and analysis time.
In the meantime, there's Haskell and ML (not that either of them do it fully either -- why even the amazing Haskell type inferencer praised by fanboys the world over can't catch a simple mathematical impossibility in a seven-line function with no operations more complex than multiplication, division, and recursion).
No one is writing those sorts of tools...
Completely untrue and misinformed. I have written such tools. jjore has written such tools. Alias has written such tools.
Besides that, you're no one. Why not you?
I don't know why anyone thought added "symbol table magic" to code was a good idea when the cost is uncheckable code.
If software development had waited until practical provability were possible, I'd be sending this message by turning cranks on a gear-driven machine. Think about the features you have to remove from a general-purpose near-Turing device to perform static flow analysis -- then think about how unsuitable such a device is for general purpose computing.
That is why.
|