**Note**: this thread is pure speculation. Feel free to ignore. Otoh, I would be interested in comments.
**Important**: The shorter and more pithy the comments, the more likely I am to read them :-) True, I often write long, rambling posts, but they are usually notes to myself. I don't expect anyone (including myself) to read long posts... Recent work raises some very interesting questions that seem to me to be related to my ongoing fascination (obsession?) with types. Before going further, let me say that I have no plans ever to abandon Python. It's just way too convenient and way too safe for that ever to happen. Please keep this firmly in mind as you read on... Dynamism comes from flexible data =========================== Imo, dynamism arises primarily from extensible data structures. Really, the characteristics of Python are almost irrelevant in this regard. It would be completely feasible to create such structures in C, or even assembly language. Having said that, **in practice** very few people create complex data structures in C: it's just way too difficult to do so. Does safety come from language? ========================== Absent extreme testing, C must be considered extremely unsafe. There are too many trap doors that subvert intentions and compiler checks. Ditto for C++. Recent works shows that Python is hardly immune from type-related surprises. However, Python does not allow C-like casts, so the possibility for hard crashes in Python is limited. Furthermore, Python's constant interpreter checks, augmented by robust exception handling, means that Leo can recover from most errors gracefully. Otoh, sqlite shows that a C program might, in some circumstances, be *more* robust than the typical Python program. See http://www.sqlite.org/testing.html Translating from Python to C ====================== In the back of my mind is the notion that under *some* (very specific) circumstances it might be possible to translate from Python to C. But to do that, we would have to **design** a Python program in such a way as to make the translation possible. This is by no means easy, as the recent confusion about what g.Bunches mean in leoConfig.py shows. Without well designed classes it is just way too easy to rely on expedient hacks that ruin all intuitions and deductions about types. My mentor, Bob Fitzwater, would say that the only way to even conceive of such a translation would be to create a **design language** in which the necessary constraints exist. However, he might agree that Python might be turned into its own design language if one were clever enough... Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
