Found 7 bookmarks
Newest
Genetic Algorithms for Evolution of QWOP Gaits
Genetic Algorithms for Evolution of QWOP Gaits
QWOP is a browser-based, 2-dimensional flash game in which the player controls an Olympic sprinter competing in a simulated 100-meter race. The goal of the game is to advance the runner to the end of the 100-meter race as quickly as possible using the Q, W, O, and P keys, which control the muscles in the sprinters legs. Despite the game simple controls and straightforward goal, it is renowned for its difficulty and unintuitive gameplay. In this paper, we attempt to automatically discover effective QWOP gaits. We describe a programmatic interface developed to play the game, and we introduce several variants of a genetic algorithm tailored to solve this problem. We present experimental results on the effectiveness of various representations, initialization strategies, evolution paradigms, and parameter control mechanisms.
#game#gaming#programming#paper
·arxiv.org·
Genetic Algorithms for Evolution of QWOP Gaits
Evolution of Emacs Lisp | Proceedings of the ACM on Programming Languages
Evolution of Emacs Lisp | Proceedings of the ACM on Programming Languages

While Emacs proponents largely agree that it is the world’s greatest text editor, it is almost as much a Lisp machine disguised as an editor. Indeed, one of its chief appeals is that it is programmable via its own programming language. Emacs Lisp is a Lisp in the classic tradition. In this article, we present the history of this language over its more than 30 years of evolution. Its core has remained remarkably stable since its inception in 1985, in large part to preserve compatibility with the many third-party packages providing a multitude of extensions. Still, Emacs Lisp has evolved and continues to do so.

Important aspects of Emacs Lisp have been shaped by concrete requirements of the editor it supports as well as implementation constraints. These requirements led to the choice of a Lisp dialect as Emacs’s language in the first place, specifically its simplicity and dynamic nature: Loading additional Emacs packages or changing the ones in place occurs frequently, and having to restart the editor in order to re-compile or re-link the code would be unacceptable. Fulfilling this requirement in a more static language would have been difficult at best.

One of Lisp’s chief characteristics is its malleability through its uniform syntax and the use of macros. This has allowed the language to evolve much more rapidly and substantively than the evolution of its core would suggest, by letting Emacs packages provide new surface syntax alongside new functions. In particular, Emacs Lisp can be customized to look much like Common Lisp, and additional packages provide multiple-dispatch object systems, legible regular expressions, programmable pattern-matching constructs, generalized variables, and more. Still, the core has also evolved, albeit slowly. Most notably, it acquired support for lexical scoping.

The timeline of Emacs Lisp development is closely tied to the projects and people who have shaped it over the years: We document Emacs Lisp history through its predecessors, Mocklisp and MacLisp, its early development up to the “Emacs schism” and the fork of Lucid Emacs, the development of XEmacs, and the subsequent rennaissance of Emacs development.

#emacs#paper#lisp#elisp#software#programming
·dl.acm.org·
Evolution of Emacs Lisp | Proceedings of the ACM on Programming Languages
Conscientious Software
Conscientious Software
Software needs to grow up and become responsible for itself and its own future by participating in its own installation and customization, maintaining its own health, and adapting itself to new circumstances, new users, and new uses. To create such software will require us to change some of our underlying assumptions about how we write programs. A promising approach seems to be to separate software that does the work (allopoietic) from software that keeps the system alive (autopoietic).
#programming#paper#software
·dreamsongs.com·
Conscientious Software
What happens when software developers are (un)happy | Elsevier Enhanced Reader
What happens when software developers are (un)happy | Elsevier Enhanced Reader
The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding happiness and unhappiness in all its components – positive and negative emotions and moods – is an attractive and important endeavor. Scholars in industrial and organizational psychology have suggested that understanding happiness and unhappiness could lead to cost-effective ways of enhancing working conditions, job performance, and to limiting the occurrence of psychological disorders. Our comprehension of the consequences of (un)happiness among developers is still too shallow, being mainly expressed in terms of development productivity and software quality. In this paper, we study what happens when developers are happy and unhappy while developing software. Qualitative data analysis of responses given by 317 questionnaire participants identified 42 consequences of unhappiness and 32 of happiness. We found consequences of happiness and unhappiness that are beneficial and detrimental for developers’ mental well-being, the software development process, and the produced artifacts. Our classification scheme, available as open data enables new happiness research opportunities of cause-effect type, and it can act as a guideline for practitioners for identifying damaging effects of unhappiness and for fostering happiness on the job.
#programming#paper
·reader.elsevier.com·
What happens when software developers are (un)happy | Elsevier Enhanced Reader
Software Engineering for Machine Learning: A Case Study
Software Engineering for Machine Learning: A Case Study
Abstract—Recent advances in machine learning have stimulated widespread interest within the Information Technology sector on integrating AI capabilities into software and services. This goal has forced organizations to evolve their development processes. We report on a study that we conducted on observing software teams at Microsoft as they develop AI-based applications. We consider a nine-stage workflow process informed by prior experiences developing AI applications (e.g., search and NLP) and data science tools (e.g. application diagnostics and bug reporting). We found that various Microsoft teams have united this workflow into preexisting, well-evolved, Agile-like software engineering processes, providing insights about several essential engineering challenges that organizations may face in creating large-scale AI solutions for the marketplace. We collected some best practices from Microsoft teams to address these challenges. In addition, we have identified three aspects of the AI domain that make it fundamentally different from prior software application domains: 1) discovering, managing, and versioning the data needed for machine learning applications is much more complex and difficult than other types of software engineering, 2) model customization and model reuse require very different skills than are typically found in software teams, and 3) AI components are more difficult to handle as distinct modules than traditional software components — models may be “entangled” in complex ways and experience non-monotonic error behavior. We believe that the lessons learned by Microsoft teams will be valuable to other organizations.
#paper#machine-learning#ai#programming
·microsoft.com·
Software Engineering for Machine Learning: A Case Study