Integrating LabVIEW into a Distributed Computing Environment

Being easy to learn and well suited for a self-contained desktop laboratory setup, many casual programmers prefer to use the National Instruments LabVIEW environment to develop their logic. An ActiveX interface is presented that allows integration into a plant-wide distributed environment based on the Experimental Physics and Industrial Control System (EPICS). This paper discusses the design decisions and provides performance information, especially considering requirements for the Spallation Neutron Source (SNS) diagnostics system.Comment: 3 pages, 2 figures, 8th International Conference on Accelerator and Large Experimental Physics Control Systems (PSN THAP032), San Jose, CA, USA, November 27-3

Region-based memory management for Mercury programs

Region-based memory management (RBMM) is a form of compile time memory management, well-known from the functional programming world. In this paper we describe our work on implementing RBMM for the logic programming language Mercury. One interesting point about Mercury is that it is designed with strong type, mode, and determinism systems. These systems not only provide Mercury programmers with several direct software engineering benefits, such as self-documenting code and clear program logic, but also give language implementors a large amount of information that is useful for program analyses. In this work, we make use of this information to develop program analyses that determine the distribution of data into regions and transform Mercury programs by inserting into them the necessary region operations. We prove the correctness of our program analyses and transformation. To execute the annotated programs, we have implemented runtime support that tackles the two main challenges posed by backtracking. First, backtracking can require regions removed during forward execution to be "resurrected"; and second, any memory allocated during a computation that has been backtracked over must be recovered promptly and without waiting for the regions involved to come to the end of their life. We describe in detail our solution of both these problems. We study in detail how our RBMM system performs on a selection of benchmark programs, including some well-known difficult cases for RBMM. Even with these difficult cases, our RBMM-enabled Mercury system obtains clearly faster runtimes for 15 out of 18 benchmarks compared to the base Mercury system with its Boehm runtime garbage collector, with an average runtime speedup of 24%, and an average reduction in memory requirements of 95%. In fact, our system achieves optimal memory consumption in some programs.Comment: 74 pages, 23 figures, 11 tables. A shorter version of this paper, without proofs, is to appear in the journal Theory and Practice of Logic Programming (TPLP

Structured Tools and Condiitonal Logic: an Empirical Investigation

An important outcome of recent work on the psychology of programming has been the recognition that we have a poor understanding of how various programming practices-indenting, commenting, naming, etc.-facilitate or inhibit the programming process. After a fairly extensive series of studies, many results obtained are contradictory and counterintuitive. The major probem seems to be that we have poor theoretical bases to drive the empirical research. In particular, we have little knowledge of the psychological constructs that programmers bring to bear when they perform various programming tasks, and we have little knowledge of what is natural for programmers. This research tested the propositon that the effectiveness of a programming practice is a function of the extent to which it provides a close cognitive fit with a programmers\u27 problem solving strategy when he or she performs a programming task. The proposition was tested in the context of two psychological processes that appear to be used by programmers when they design and code conditional logic: (a) taxonomizing-identifying the conditions that evoke particular actions; and (b) sequencing-converting the taxa to a linear sequence of program code. Three structured tools-structured English, decision tables, and decision trees-were investigated in a laboratory setting to determine how they facilitated these two processes. It was hypothesized that decision tables and decision trees would facilitate the taxonomising process because they allow conditions and actions to be easily identified, and that structurd English would facilitate the sequencing process because it provides a linear representation of logic that can be mapped easily into programming code. To test the hypotheses, 124 volunteer information systems and computer science students undertook three experiments. In the first experiment they were given a narrative description of some conditional logic and asked to represent the logic using one of the three types of structured tools. In the second experiment they were given conditional logic already represented via one of the tools and asked to convert it into COBOL code. In the third experiment they were given a narrative description of some conditional logic and asked to convert it into COBOL code after having first represented the logic using one of the three types of structured tools. Their perfomance was assessed in terms of the number of syntactic errors they made, the number of semantic errors they made, and the time taken to perform the experimental tasks. In general, the results confirmed the propostions investigated. When the taxonomizing task had to be undertaken, decision trees outperformed strutured English, although surprisingly structured English outperformed decision tables. When the sequencing task had to be undertaken, structured English outperformed decision tables, but decision trees evoked the same level of performance as structured English. Across all tasks, decision tables evoked relatively poor levels of perfomance. On the other hand, decision trees evoked high levels of performance across all tasks. It appears that the graphical tree structure allows taxon information to be represented poignantly. At the same time it appears relatively easy to trace a branch to its leaf node to perform the sequencing task. The superiority of decision trees seems to confirm the desirablity of graphically revealing the structure inherent in processes rather than using symbolic languages. Moreover, the results suggest that the syntax of current programming languages may be unnecessarily restrictive. Perhaps programming languages should provide decision trees as part of their syntax instead of providing only unidimensional, linear syntax to represent conditional logic

Alternative forms of program documentation for the support of audit review: An experimental investigation of usability: Working paper series--02-06

Auditors and programmers review information systems and application documentation for a number of purposes, including the evaluation and maintenance of controls. Information systems documentation may include application flowcharts, systems flowcharts, logic diagrams, etc. The same coded application procedure can be represented in the application documentation in different ways. Prior research suggests that the form of the documentation may affect the ability of auditors and programmers to efficiently and effectively review the documentation. This study reports an experiment that investigates the effect of alternate forms of documentation on the efficiency and effectiveness of the auditor and programmer's review of documentation. The review task of interest involves the auditor or programmer's identification and evaluation of control procedures within an application. The hypotheses are based upon the theory of cognitive fit which postulates that decision-making performance on a task will be enhanced when there is a cognitive fit (i.e., match) between the information emphasized in the representation and that required by the task. The results indicate that subjects using a spatial representation (flowcharts) took less time to complete the review task than the subjects using a symbolic (structured English) representation. There were, however, no differences in accuracy across the two representations. These results held for both spatial and symbolic review tasks

Is a Dataframe Just a Table?

Querying data is core to databases and data science. However, the two communities have seemingly different concepts and use cases. As a result, both designers and users of the query languages disagree on whether the core abstractions - dataframes (data science) and tables (databases) - and the operations are the same. To investigate the difference from a PL-HCI perspective, we identify the basic affordances provided by tables and dataframes and how programming experiences over tables and dataframes differ. We show that the data structures nudge programmers to query and store their data in different ways. We hope the case study could clarify confusions, dispel misinformation, increase cross-pollination between the two communities, and identify open PL-HCI questions

Four approaches to teaching programming

Based on a survey of literature, four different approaches to teaching introductory programming are identified and described. Examples of the practice of each approach are identified representing procedural, visual, and object-oriented programming language paradigms. Each approach is then further analysed, identifying advantages and disadvantages for the student and the teacher. The first approach, code analysis, is analogous to reading before writing, that is, recognising the parts and what they mean. It requires learners to analyse and understand existing code prior to producing their own. An alternative is the building blocks approach, analogous to learning vocabulary, nouns and verbs, before constructing sentences. A third approach is identified as simple units in which learners master solutions to small problems before applying the learned logic to more complex problems. The final approach, full systems, is analogous to learning a foreign language by immersion whereby learners design a solution to a non-trivial problem and the programming concepts and language constructs are introduced only when the solution to the problem requires their application. The conclusion asserts that competency in programming cannot be achieved without mastering each of the approaches, at least to some extent. Use of the approaches in combination could provide novice programmers with the opportunities to acquire a full range of knowledge, understanding, and skills. Several orders for presenting the approaches in the classroom are proposed and analysed reflecting the needs of the learners and teachers. Further research is needed to better understand these and other approaches to teaching programming, not in terms of learner outcomes, but in terms of teachers’ actions and techniques employed to facilitate the construction of new knowledge by the learners. Effective classroom teaching practices could be informed by further investigations into the effect on progression of different toolset choices and combinations of teaching approache