User loginNavigation |
archivesFundamental Flaws in Current Programming Language Type SystemsI'll start with the following statement (which from different perspectives may or may not be considered valid by various parties):
In the past I have raised a number of questions in this forum regarding types and programming languages that have in the main only been answered by those who have a strongly held viewpoint. I have been spending much time over the last few years considering the viewpoints thus exhibited. The viewpoints expressed have been one of the following: Static Type are the best - various reasoning What has been unsatisfactory about the answers and the discussions that have ensued is that the subject of real world systems and the real world situations they are deployed in have not been closely examined. By this I mean that hardware related errors, system software related errors and user caused errors (including deliberate attacks) have not been brought into the discussion in relation to how the various kinds of type system can help in these conditions. Putting aside anyone's particular bent in belief as to which is the best kind of type system for programming languages, my question is: In what areas do each of the above type systems fail to provide the programmer with the tools (language constructs, abstraction facilities, etc.) to actually deal with real world troubles, problems and conditions? PLT should be about improving what we can actually do with the computing machinery that we use. With the wide range of people in this forum, what areas of research are being looked or not looked in this regard? An example problem is an application that works correctly on a single processor system but exhibits somewhat random behaviour on a dual (or more) processor system due to the seemingly random interactions/responses of a third party library or component. Please, not interested in ideological wars over this. Practicality of Exclusively Compiler-Driven UnboxingIt is sometimes claimed in the FP community that explicit representation controls (unboxing) are unnecessary, because a good optimizer can re-arrange the data structures into unboxed forms where appropriate (I disregard hardware interaction for this discussion). Litmus questions here:
Thoughts and references? |
Browse archivesActive forum topics |
Recent comments
22 weeks 2 days ago
22 weeks 2 days ago
22 weeks 2 days ago
44 weeks 3 days ago
48 weeks 5 days ago
50 weeks 3 days ago
50 weeks 3 days ago
1 year 6 days ago
1 year 5 weeks ago
1 year 5 weeks ago