Edsger Dijkstra Research Articles

Searching For The Nearest Route To The Location Of Health Facilities Using The Djikstra Method

A health facility or health service facility is a tool or place used to carry out health service efforts, both in terms of promotive, preventive, curative and rehabilitative carried out by the central government, regional government or the community. This research contains development applications that cover every hospital, health center, and practice clinic located in the Langkat Regency area with the aim of facilitating the community in finding the nearest hospital, health center, and practice clinic. The application built can display the location of the health facility in map form and can display information in the form of name, address, telephone number, photo of the health facility, services available there, working hours, and further information on the place. In this study, the search for health facilities is only subject to distance as a health facility criterion, so that it can be developed further. To find the closest route to a health facility, here the author uses the Dijkstra Algorithm method which has been widely researched to be applied to the shortest route search system. This algorithm was invented by Edsger Dijkstra, a computer scientist from the Netherlands. The way Dijkstra's algorithm works is with a greedy strategy, namely at each step it chooses the side with the smallest value that connects the selected and unselected nodes/nodes. This algorithm requires a point of origin and a destination with the final result being the shortest distance from the point of origin to the destination along with the route.

Spillovers from Oil Firms to U.S. Computing and Semiconductor Manufacturing: Smudging State–Industry Distinctions and Retelling Conventional Narratives

Histories of semiconductor and computing technology in the United States have emphasized the supporting role of the U.S. state, especially the military, in answer to libertarian denials of state aid that are influential in Silicon Valley today. Somewhat implicit in that historiography, though, is the leading role of actors and organizations that blur any distinction between public and private. Some industries of this sort—telecommunications, aerospace, auto manufacturing—do figure in the historiography, but the class should be expanded further. One such industry—oil—has been exceptionally but almost invisibly influential in the development of computing and semiconductor manufacturing in the United States. Oil firms invested heavily in semiconductors and computing. There was also an “oil spillover” of personnel and technology from oil firms to computing and semiconductor manufacturing. Oil shows up in the biographies of many prominent individuals and organizations in the history of those technologies, from Fairchild Semiconductor to Edsger Dijkstra. These ties potentially hold important implications for the much-needed transition to a more sustainable energy regime.

Logic, Code, and the History of Programming

Astriking feature of the debates around the perceived software crisis in the 1960s and 1970s is the frank contempt expressed by some elite computer scientists for much work in the fields of programming and programming language design. The writings of computer scientist Edsger Dijkstra are a familiar source of such material: in his Turing Award lecture, he opined that “the sooner we can forget that FORTRAN ever existed the better” and likened an advocate of the PL/I language to a drug addict. In a slightly more restrained register, John Backus (another Turing Award winner) used his acceptance speech to denounce existing languages as “fat and flabby [2].” Dijkstra’s contempt for the tools of his trade easily slipped into contempt for their users.

The Man Who Carried Computer Science on His Shoulders

During the 1970s and 1980s, Edsger Dijkstra was possibly the most discussed scientist in his field, admired and criticized in equal measure. He largely ignored the work of others and rested on his own ideas, which he typed or handwrote, photocopied, and then mailed to other computer scientists. He was a pioneer and a genius whose work shaped the emerging field of computer science like few others.

Intellectual Control [Pragmatic Designer

In the early days of software engineering, Edsger Dijkstra warned us not to let the size and complexity of our programs cause us to lose “intellectual control” due to the limited nature of our minds. To my knowledge, he never defined precisely what intellectual control was. Our software today is staggeringly larger than the programs of the 1960s, so does that mean we have it under our intellectual control, or did we find ways to make progress without Dijkstra’s high standards? I see signs that we have some software that is under intellectual control and other software that is not. In this column, I’m going to discuss how we can recognize these two categories, what happens when engineers on a project have different attitudes about intellectual control, some advice on when we probably should insist on it, and some ideas about how we achieve it.

Software Structures: A Careful Look

In the half century since Edsger Dijkstra published “The Structure of the ‘THE’-Multiprogramming System,” it has become clear that the ability to design a software system’s structure is at least as important as the ability to design efficient algorithms or write code in a particular programming language. Although the word “structure” appeared in the paper’s title and was used seven more times, Dijkstra never defined the term. Closer examination revealed that he was discussing at least three distinct structures. His failure to define “structure,” or to clearly distinguish the structures that were important in his software, has led many to confuse those structures. This article aims to clarify what those structures are, their differences, and each one’s importance.

Dijkstraas Algorithm: An Analysis

It has been over 60 years since Edsger Dijkstra conceived an algorithm to find the shortest path in a graph with non-negative values. Despite the fact that the size of networks is increasing and becoming more complex, the traditional Dijkstra’s algorithm is still prevalent and popular amongst these modern mapping and navigation systems. The objective of this report is to study the functioning of Dijkstra’s algorithm to understand how it maintains efficiency and accuracy in determining the shortest path despite the complex architecture of the modern day network. Furthermore, the report discusses the shortcoming of this algorithm, if any, and how it impacts the viability of the algorithm in today’s context.

Challenges for Educational Technologists in the 21st Century

In 1972, Edsger Dijkstra claimed that computers had only introduced the new problem of learning to use them effectively. This is especially true in 2015 with regard to powerful new educational technologies. This article describes the challenges that 21st century educational technologists are, and will be, addressing as they undertake the effective integration of new technologies into K-12 educational systems and learning environments. The expanding Internet, ever more powerful mobile devices, and other innovations make the task of designing effective formal and informal learning challenging, especially in light of the high rate of change in these new technologies. While these technologies introduce many benefits, they are also causing serious threats to system security and personal privacy. Furthermore, as these technologies continue to evolve, ethical issues such as equal access to resources become imperative. Educational technologists must expand their forward-thinking leadership and planning competencies so as to ensure effective use of new technologies.

Hopper and Dijkstra: Crisis, Revolution, and the Future of Programming

In the late 1960s, tensions were erupting in corporate and academic computing cultures in the United States and abroad with competing views about the state of computer programming and possible future implications. A discourse of crisis was ignited in 1968 when NATO hosted a conference on the topic of software engineering. The author examines the rhetoric of crisis, revolution, and promise in computer programming cultures by viewing it through the lens of two dissimilar leaders, Grace Hopper and Edsger Dijkstra, who articulated views through discourses about computer programming that reveal multiple ideals and tensions. As representatives and exemplars of different communities, they emphasized pragmatic versus theoretical stances, respectively. The historical context they operated in also highlights the cultural complexities of gender in computer programming, a durable phenomenon that continues today.

Universality versus Locality: The Amsterdam Style of Algol Implementation

During the 1950s, computer programming was a local practice. Programs from one computing center would not work on computers elsewhere. For example, programs written in Munich differed radically in style from programs written in Amsterdam. Similar problems were also encountered in the United States, leading American computer programmers in 1954 to combine the ideal of a machine-independent programming tool with the metaphor of language. European researchers eagerly embraced this idea and subsequently collaborated with their American colleagues in developing such a language, called Algol. Although it was meant to be universal in terms of machine-independence, in order to be a working technology, Algol by necessity had to be implemented on a specific type of machine. As a result, the aspired universal Algol language would be bound to a compiler, or translator, which depended on the specificities of the underlying machine. Local machinery, traditions of programming, and compilers would in turn give Algol a local appearance and, in more than one case, led to the decision of working with a restricted version of the language. Thus, in practice, Algol came with local dialects. This article elaborates on the tension between universality and locality by contrasting the Amsterdam and Munich styles of programming. In addition to the famous controversy on recursive procedures, it also highlights Edsger Dijkstra's concept of a machine-independent object language.

Introducción breve a la ingeniería dirigida por modelos

La crisis del software es un concepto que comenzó a utilizarse en 1968, en la primera conferencia organizada por la Organización del Tratado del Atlántico Norte (OTAN) en el desarrollo de software. Allí, Edsger Dijkstra criticó que los proyectos no se completaban debido a la clásica triple restricción de la gestión de proyectos —alcance, tiempo y costo—, ya que la mayoría de ellos no alcanzaban los requisitos previstos, se entregaban fuera de plazo o superaban el costo esperado. Por desgracia, la realidad actual es que; si bien se han propuesto nuevas metodologías destinadas a la solución de los problemas habituales relacionados con el desarrollo de software, todavía no existe un método fiable para estimar el desarrollo de los sistemas informáticos. En este artículo se presenta el enfoque de Ingeniería Dirigida por Modelos que, según los expertos, ayudará a resolver muchos de los problemas que miles de equipos de desarrollo de software tienen a diario en todo el mundo.

The physics of distributed information systems

This paper aims to introduce Distributed Systems as a field where the ideas and methods of physics can potentially be applied, and to provide entry points to a wide literature. The contributions of Leslie Lamport, inspired by Relativity Theory, and of Edsger Dijkstra, which has the flavor of a growth process, are discussed at some length. The intent of the author is primarily to stimulate interest in the statistical physics community, and the discussions are therefore framed in a non-technical language; the author apologizes in advance to readers from the computer science side for the unavoidable impreciseness and ambiguities.

Building European software architecture community: how far have we come?

Whilst the references to the role and importance of software architecture started appearing since 1969 when NATO organized a conference on software engineering techniques, the term “software architecture” started gaining acceptance by the software engineering community in early 1990s. In 1992, Perry and Wolf [9] provided an earlier framework for grounding software architecture as an important area of research and practice. A few years later in 1996, Shaw and Garlan [11] published one of the first books on software architecture. Less than a year later, Bass et al. [2] published a practiceoriented book on software architecture. Whilst these efforts play a significant role in promoting software architecture as discipline of research and practice, the foundations of this discipline included seminal work of Edsger Dijkstra, David Parnas, and others between 1960s and 1980s [8]. There was also an increasing realization that an architectural description can play an important role in successfully understanding and managing large and complex software systems [3]. The need

Empirical research in software architecture: opportunities, challenges, and approaches

Software architecture has become an important area of research and practice since the late 1980s (Shaw and Clements 2006). The term “software architecture” started gaining acceptance by the software engineering community in early 1990s but the foundations of this field were laid by the seminal work of Edsger Dijkstra, David Parnas, and others between 1960s and 1980s (Clements 2000). The increasing size and complexity of software systems and demand for high quality are some of the most important factors that have driven the increased interest in this sub-discipline of software engineering. It has generally been realized that a high-level design description can play an important role in successfully understanding and managing large and complex software systems (Clements et al. 2002; Lung and Kalaichelvan 2000). The high-level design decisions regarding the software architecture of a system are not only the hardest and most expensive to change but also play a fundamental role in setting the boundaries for the required quality attributes such as maintainability, reliability, usability, performance, and flexibility of a system (Bass et al. 2003; Clement and Northorp 1996). As a result of increasing realization of the important role of software architecture in large-scale software development and evolution projects, the software architecture community has developed several methods, techniques, and tools to support the software Empir Software Eng (2011) 16:539–543 DOI 10.1007/s10664-011-9168-6

A Tribute to Jim Gray

Computer science attracts many very smart people, but a few stand out above the others, somehow blessed with a kind of creativity that most of us are denied. Names such as Alan Turing, Edsger Dijkstra, and John Backus come to mind. Jim Gray is another.

User-Centered Design Considered Harmful1(with apologies to Edsger Dijkstra, Niklaus Wirth, and Don Norman)

User-Centered Design Considered Harmful¹(with apologies to Edsger Dijkstra, Niklaus Wirth, and Don Norman)

On the necessity of removing "cruelty" from the teaching of computing

In his famous article [1] Edsger Dijkstra reflected upon how cruel it would be truly to teach computer science. For some reason the CS community over the years have taken the sadistic element of his entreaties to heart. Why is this so? Does it have intuitive appeal to those CS educators who believe in the "hard man" school of computer science and the "real programmers don't eat quiche" model of education?

Between the disciplines

Computer science as a discipline has come of age. In fact, as a human worker it could face retirement. Computer science is one of the few new disciplines that evolved and grew, searching and finding its place between other disciplines such as mathematics, electronic design, economics, and others. By its origin, it was an interdisciplinary challenge. And this challenge still exists. New fields of applications emerge, while the basic foundations are still in question. Is computer science really a "very large application of logic" as Edsger Dijkstra once summarized? Is it shifting towards one of the fashionable media studies, or should it evolve to a serious engineering practice as David Parnas points out? There seems to be a long winding road before us -- but there is neither a "dead-end road" nor a "giant leap" in sight. Quite certain, computer science will reposition under the influences of new application like digital media and the demands of other disciplines from genetics and nano-technology to marketing, also known as "customer relationship management". What is new for computer science compared, let's say, to literature, chemistry, or astronomy? Probably, it is the steady flow of new connections to other fields whether as application areas or as deeper connections as in bioinformatics, digital media, or computational linguistics, where computer science does neither stand as a fixed body of rules and methods, nor as a well-defined field of objects to be investigated.

What software engineering can learn from soccer

We've talked about software quality for a long time, developing numerous software quality assurance approaches in the hope of making our software increasingly better. Charles Mann, contributing editor of MIT's Technology Review, points out that other technologies-televisions, cars, airplanes, bridges-have improved over time as their engineering matured; he asks why software has not. In the February 2001 issue of Communications of the ACM, Edsger Dijkstra said that software's biggest challenge is "how not to make a mess of it." So, where have we gone wrong? To answer this question, we can look at how other disciplines learn and grow. Software development is as much an art as a science, and we learn lessons from both perspectives. Many of us think of ourselves as engineers: we train in engineering departments and rely on engineering tools, techniques, and quantitative methods to guide us. But our work's artistic side-which those who promote agile methods often emphasize-plays an important role, too. As good software developers, we are grounded in artistic engineering activities such as modeling and design. Our good people skills enable us to work with customers and on teams. And we need good instincts to select the best approaches and products to use.

Regular Expressions for Program Computations

In brief history of computer science, no single article has attracted more attention nor stirred more controversy than a seemingly innocuous 1968 letter to editor (of Communications of ACM) by Edsger Dijkstra [3], titled Goto Statement Considered Harmful. We were just emerging from Fortran era, when programming had not yet been thought of as an art or even a craft. A diagram of program flowlines, what came to be called a flowchart, would very nearly resemble a plate of spaghetti go to here and this, then go to there and that. Programs were held together with baling wire, little thought being given to their organizational structure. Dijkstra argued that an unbridled use of goto was heart of problem. In his opening sentence, he asserts that the quality of programmers is a decreasing function of density of goto statements in programs produce. He would later argue for elimination of goto statement altogether. At time, nothing could have been more controversial. Many programmers argued that some algorithms were impossible (or at very least, unnatural) to implement without use of goto. But new programming languages were on horizon (e.g., Pascal particularly), offering such structural constituents as do, until, then else, and case statements, whereby one could organize a program into successive levels of refinement, giving some credence to Dijkstra claim. Proponents of Dijkstra discipline of programming began to use a cryptic (at time) and somewhat obscure result of Corrado I3ohm and Giuseppe Jacopini [1] as justification for their optimism and enthusiasm. In effect, their work seemed to indicate that any algorithm could be written as a structuredprogram [2], i.e., as a program involving only repetition (whether of while do or repeat until variety), selection (typically characterized by if then else construct) and sequence of (possibly compound) statements, these three constructs perhaps being nested one within other to an arbitrary depth, down to level of elementary processes of assignment, input, and output. And most importantly, there was seen to be nb need whatsoever of employing harmful goto But Bohm-Jacopini result was not all that clearly understood at time. Even Dijkstra himself stated only that they seem to have proved logical superfluousness of goto statement. For it happens that it is not all that easy to give a totally convincing proof in elementary terms. We take up just such a challenge in this survey. We use opportunity to introduce reader to a modern software engineering framework for investigation, using topics that are important to a contemporary computer science research area known as software metrics, and we further employ an algebra of regular expressions, as most commonly encountered in theory of automata, all toward offering a modified form of now-classical Bohm-Jacopini result, and thus achieving a presentation blending new with old.