Why Logo is Not Useful for Real Work and What Can Be Done About It
As I've been playing around with Logo lately I've asked myself the question, "Could we use this for REAL programs?" IE outside the educational toy-language context? Can Logo be used for grown-up stuff?
The answer, sadly, is a resounding NO, not in it's current state. But with a bit of work it would not actually be that hard to make Logo a useful scripting language, or even a systems language, like it's Lisp fore-bearer.
The major issue is that reading untrusted data directly into Logo words is grossly insecure. No sane sysadmin would deploy such a monstrosity in production.
Parts of the solution exist in various Logos, but none of them have brought it all together.
Many older Logos were capable of reading binary data into arrays but lacked higher level APIs for processing strings and may remain vulnerable to malformed or malicious data.
None of the CLI Logos support command line arguments or environment variables. FFI's are rare, especially in newer Logos. They were common in early microcomputer Logos but I guess such features were considered too advanced to be of use to school kids.
Unicode is generally not supported.
No #! & argv[0] setting support.
So how do we solve this problem?
I think we can look to Ruby for an example.
Ruby has "normal" strings. Ruby also has "symbols" which are semantically very similar to Logo words in that they are usable as strings but also as identifiers so their contents must be syntactically legal. They are also accumulated in a global lookup table.
So to make Logo secure we would need to
1. Read binary bytes from file into array type that can not be eval'ed
2. Decode to Unicode string type; UTF-32 would probably be most convenient for Logo; again cannot be eval'ed
3. Optionally create words from safe and sanitized string data; these words can be eval'ed
4. Provide string manipulation library to complement existing word manipulation libraries to the degree practical. Or punt and copy everybody else and use, like, split, join, etc.
5. Some sort of declarative mapping layer to safely convert raw string data to/from logo words, lists or objects.
These facilities are standard in all modern "real" programming languages because they are absolutely necessary. These are non-optional features for doing real work.
Comments
Post a Comment