Onward! Essays 2020
ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and
Reflections on Programming and Software
Renaissance Chicago Downtown Hotel
Chicago, USA
November 18--20 2020
Part of SPLASH 2020
Systems, Programming Languages and Applications:
Software for Humanity
https://2020.splashcon.org/track/splash-2020-Onward-essays
Onward! is a premier multidisciplinary conference focused on everything to
do with programming and software: including processes, methods, languages,
communities, applications and education.
Compared to other conferences, Onward! is more radical, more visionary, and
more open to ideas that are well-argued but not yet proven. It is not
looking for research-as-usual papers. To allow room for bigger, bolder
and/or less mature ideas, it accepts less exact methods of validation, such
as compelling arguments, exploratory implementations, and substantial
examples.
Onward! Essays is looking for clear and compelling pieces of writing about
topics important to the software community (there is also a parallel Papers
track with a seperate announcement).
An essay can be an exploration of the topic and its impact, or a story about
the circumstances of its creation; it can present a personal view of what
is, explore a terrain, or lead the reader in an act of discovery; it can be
a philosophical digression or a deep analysis. It can describe a personal
journey, perhaps the one the author took to reach an understanding of the
topic. The subject area—software, programming, and programming
languages—should be interpreted broadly and can include the relationship of
software to human endeavors, or its philosophical, sociological,
psychological, historical, or anthropological underpinnings.
Format and Selection:
Onward! essays must describe unpublished work that is not currently
submitted for publication elsewhere as described by SIGPLAN's Republication
Policy. Submitters should also be aware of ACM's Policy and Procedures on
Plagiarism. Onward! essays should use the ACM SIGPLAN Conference acmart
format. Please refer to the conference's website above for full details.
The Onward! Essays track follows a two-phase review process. Essays are
peer-reviewed in a single-blind manner. Accepted essays will appear in the
Onward! Proceedings in the ACM Digital Library, and must be presented at the
conference. Submissions will be judged on the potential impact of the ideas
and the quality of the presentation.
Important dates:
All deadlines are midnight, anywhere on Earth.
Essay submission: 23 April
First-round notification: 11 June
Second-round submission: 15 July
Final notification: 30 July
Conference: 18--20 November
Programme Committee:
Didier Verna, EPITA Research lab, France (Program Chair)
Anya Helene Bagge, University of Bergen, Norway
Alexandre Bergel, University of Chile
Jean Bresson, Ableton, Germany
Maxime Chevalier-Boisvert, Université de Montréal, Québec
Elisa Gonzalez Boix, Vrije Universiteit Brussel, Belgium
Hidehiko Masuhara, Tokyo Institute of Technology, Japan
Kent Pitman, PTC, USA
Donya Quick, Stevens Institute of Technology, USA
Gordana Rakić, University of Novi Sad, Serbia
|
Didier Verna's scientific blog: Lisp, Emacs, LaTeX and random stuff. |
|
Tag - Programming Languages
Tuesday, March 3 2020
Onward! Essays 2020 Call for Papers
By Didier Verna on Tuesday, March 3 2020, 12:55 - Miscellaneous
Tuesday, February 26 2013
Dyla'13, 7th Workshop on Dynamic Languages and Applications
By Didier Verna on Tuesday, February 26 2013, 15:45 - Miscellaneous
Dyla'13, 7th Workshop on Dynamic Languages and Applications Colocated with ECOOP, ECMFA and ECSA 1–5 July, Montpellier, France http://rmod.lille.inria.fr/web/pier/Events/Dyla13 !! Important dates - Submission deadline: April 19th - Notification: mid-May - Workshop: July 1st - Ecoop early registration: mid-May !! Abstract The advent of Java and C# has been a major breakthrough in the adoption of some important object-oriented language characteristics. This breakthrough turned academic features like interfaces, garbage collection, and meta-programming into technologies generally accepted by industry. Nevertheless, the massive adoption of these languages now also gives rise to a growing awareness of their limitations. A number of reactions from industry testify this: invokedynamic bytecode instruction has been included in latest Java virtual machine release; the dynamic language runtime (DLR) is gaining popularity; C# adopted dynamic as a valid static type. Gartner prognoses further growth (http://blogs.gartner.com/mark_driver/2008/12/10) of dynamic languages. Researchers and practitioners struggle with static type systems, overly complex abstract grammars, simplistic concurrency mechanisms, limited reflection capabilities, and the absence of higher-order language constructs such as delegation, closures and continuations. Dynamic languages such as Ruby, Python, JavaScript and Lua are a step forward in addressing these problems while getting more and more popular. Making these languages mainstream requires practitioners to look back and pick mechanisms up in existing dynamic languages such as Lisp, Scheme, Smalltalk and Self. Practitioners also need to further explore discover new dynamic approaches in the context of new challenging fields such as pervasive computing. The goal of this workshop is to act as a forum where practitioners can discuss new advances in the design, implementation and application of dynamically typed languages that, sometimes radically, diverge from the statically typed class-based mainstream. Another objective is to discuss new as well as older "forgotten" languages and features in this context. Topics of interest include, but are not limited to: - programming language extensions - programming environment extensions - executing environments - static and dynamic analyses - optional type-checking - meta-object protocols - reserve engineering - domain-specific languages/tooling - testing environments - live programming !! Targeted audience The expected audience of this workshop is practitioners and researchers sharing the same interest in dynamically typed languages. Lua, Python, Ruby, Scheme and Smalltalk are gaining a significant popularity both in industry and academia. Nevertheless, each community has the tendency to only look at what it produces. Broadening the scope of each community is the goal of the workshop. To achieve this goal we will form a PC with leading persons from all languages mentioned above, fostering participation from all targeted communities. !! Workshop Format and Submission Information The workshop will have a demo-oriented style. The idea is to allow participants to demonstrate new and interesting features and discuss what they feel is relevant for the dynamic-language community. To participate to the workshop, you can either - submit (before __April 19th 2013__) an article (ACM Tighter Alternate style http://www.acm.org/sigs/publications/proceedings-templates) describing your presentation and/or tool. Articles whose length ranges from 2 to 15 pages will be carefully reviewed by a program committee including but not limited to the organizers. Each accepted paper will be presented for 20 to 30 minutes and be published to the ACM Digital Library (at the option of each author) and the workshop's web site. The submission website is http://www.easychair.org/conferences/?conf=dyla2013. - or give a 10-minute lightning demo of your work. A dedicated session will be allocated for this, provided there is ample time available. A session on pair programming is also planned. People will then get a chance to share their technologies by interacting with other participants. !! Program committee - Carl Friedrich Bolz, Heinrich-Heine-Universität Düsseldorf, Germany (http://cfbolz.de) - Camillo Bruni, Inria Lille-Nord Europe, France (http://rmod.lille.inria.fr/web/pier/team/bruni) - Adrian Kuhn, University of British Columbia, Canada (https://www.cs.ubc.ca/people/adrian-kuhn) - Lukas Renggli, Google, Switzerland (http://www.lukas-renggli.ch/) - Juan Pablo Sandoval Alcocer, University of Chile (http://users.dcc.uchile.cl/~jsandova/) - Bastian Steinert, Hasso-Plattner-Institute, Germany (http://www.bastiansteinert.org) - Veronica Uquillas Gomez, Vrije Universiteit Brussel, Belgium (http://soft.vub.ac.be/~vuquilla/) - Simon Urli, University of Nice-Sophia Antipolis, France (http://www.simonurli.fr/) - Didier Verna, EPITA Research and Development Laboratory, France (http://www.lrde.epita.fr/~didier) - the 4 workshop organizers !! Workshop Organizers - Alexandre Bergel (http://bergel.eu) - Damien Cassou (http://damiencassou.seasidehosting.st) - Jorge Ressia (http://www.jorgeressia.com) - Serge Stinckwich (http://www.doesnotunderstand.org) !! News feed Follow us on twitter: http://twitter.com/dyla2013 For further information: http://rmod.lille.inria.fr/web/pier/Events/Dyla13
Thursday, July 12 2012
Language wars
By Didier Verna on Thursday, July 12 2012, 11:42 - Lisp
Programming languages are tools. Just like hammers. There's nothing personal about them. They just help you build stuff. Yet, there are many religious wars about programming languages out there. Wars which despite being all about science, are much more related to emotions, beliefs and personal aggressions than about objective arguments.
This is funny because do you know of any religious wars about hammers? So what's the difference?
Here's a recent personal example. A guy explaining how the static typing of Common Lisp works (type declarations) and what kind of performance-oriented optimization can be achieved with it (C-like, static but weak typing in SBCL for instance). And then, there's inevitably the troll (whom I know knows better) in the audience who goes:
So, yeah, what you're doing is just C code, and you have to type manually, and it's ugly. So if it's just for writing C code, I don't see the point in using another language.
Hmmm. Let's see. So, yes indeed, static typing in Common Lisp is ugly. And yes, it's not even strong typing. And yes, it would be nicer to have run-time hotspot detection and automatic type-dependant optimization like what's found in some other languages or virtual machines, rather than having to do it by hand (BTW, that would make for a nice Ph.D. I think). But what does that really tell you? That no language is perfect? Wow, thank you very much, that's new. For as much as I think that Lisp The Idea™ is perfect, I don't think anyone ever pretended that Common Lisp (or any Lisp for that matter) was. But is that a reason for not using it at all and sticking to C? Any sane computer scientist knows that the choice of a language doesn't boil down to only one parameter. Any computer scientist who tells otherwise is a troll.
In spite of all its defects, I still have a gazillon reasons to prefer Common Lisp over C, C++, or any language that I know of currently (and this may very well change in the future). The flexibility of lambda lists, the macros, the MOP or more generally its structural and behavioral reflexivity. Its run-time compilation, debugging, introspection and intersession capabilities. These are just a few examples. Still, I don't deny anyone the right to prefer another language for whatever purpose and whatever reasons they may feel legitimate.
So, I normally just ignore those purposedly trollesque and completely idiotic remarks. Yet, sometimes like yesterday, I snap. It gets on my nerves and I become all upset and angry. Why? I never get angry when someone tells me that my hammer is a piece of crap (it's not). I do enough Aikido to know how to control my temper, but for some reason, it doesn't always work when it comes to programming languages. So what is it about them that in spite of all your efforts, you can't help from getting personally and emotionally involved once in a while?
I think the answer becomes apparent when you consider the artistic aspect in programming. When an artist creates a piece (music, theater, dance, painting, architecture, whatever you like), (s)he exposes a very intimate part of himself through his creation. The art "is" the artist, and the artist "is" his art. In doing so, he puts himself in danger. It's like yelling out to the whole world Hey, look, I'm vulnerable right here!!
. It's a well know fact that many artists are very fragile, in the sense that they suffer from their creation not being liked. Because a piece of art is intrinsically a piece of the artist himself, when you say I don't like this piece of art
, you're actually saying I don't like the artist
. Then, it's up to artist to handle the fact of not being liked.
And that's the whole problem, which, as a musician, I know all too well. Where does the artistic fiber come from? It's an urge to express yourself. To express something that you can't express in any other way. A very deep and perpetual wound of some sort, a feeling of not really belonging. More importantly, it's a calling. Sometimes, the simple fact of creating is enough to heal you a bit, but more often, you create in order for your creation to be seen or heard. So yes, it's a calling to the Others. You expect them to answer your call by telling you that they like you (your art, but that is the same). Artists often have this urge to be liked by the Others. So when you dislike some artwork, you're also not liking the artist himself (the part of him that lives in his creation) and you're actually giving him the exact opposite of what he was looking for. And that hurts.
Back to programming languages. Why do we get all emotional about them, and not about hammers? The answer is in fact quite simple. Look at an architectural masterpiece. Do you see the hammer that was used to build it? Now look at a software masterpiece. Do you see the language that was used to write it? That's the crucial difference. You cannot decouple the language from the software, even once it has been written (the art is not in the executable; it's in the source code). The language itself will always be here for you to contemplate.
All in all, I think that's why there will always be language wars. Languages are not just tools, actually. They're not just like hammers. As soon as you care about the code you write, your software becomes artwork, you become an artist, and you start to be personally and emotionally involved. Your software becomes part of you. And contrary to the hammer, your sticky programming language, being intrinsically bound to the artwork, also becomes part of you. That's when the battle for objectivity is lost. By criticizing the language, the troll also criticizes your artwork, and in doing so, he tells you that he doesn't like you. That may hurt.
It's good to consider programming as art. Unfortunately, this also means that there will always be language wars.
Tuesday, May 22 2012
Call for Papers: ACM SAC'13 PL: ACM Symposium on Applied Computing, Programming Languages track
By Didier Verna on Tuesday, May 22 2012, 11:23 - Miscellaneous
CALL FOR PAPERS SAC'13 - ACM 2013 SYMPOSIUM ON APPLIED COMPUTING Technical Track on "Programming Languages" March 18-22, 2013 Coimbra, Portugal SAC '13 Over the past 27 years, the ACM Symposium on Applied Computing has become a primary forum for applied computer scientists, computer engineers, software engineers, and application developers from around the world to interact and present their work. SAC 2013 is sponsored by the ACM Special Interest Group on Applied Computing (SIGAPP). For additional information, please check the SAC web page: http://www.acm.org/conferences/sac/sac2013/. This document is also available at: http://www.cse.unt.edu/~bryant/sac2013/PL-SAC13-CFP.pdf PROGRAMMING LANGUAGES (PL) TRACK A technical track on Programming Languages will be held at SAC'13. It will be a forum for engineers, researchers and practitioners throughout the world to share technical ideas and experiences relating to implementation and application of programming languages. Original papers and experience reports are invited in all areas of programming languages. Major topics of interest include but are not limited to the following: − Compiling Techniques, − Domain-Specific Languages, − Formal Semantics and Syntax, − Garbage Collection, − Language Design and Implementation, − Languages for Modeling, − Model-Driven Development and Model Transformation, − New Programming Language Ideas and Concepts, − New Programming Paradigms, − Practical Experiences with Programming Languages, − Program Analysis and Verification, − Program Generation and Transformation, − Programming Languages from All Paradigms (Agent-Oriented, Aspect-Oriented, Functional, Logic, Object-Oriented, etc.), − Visual Programming Languages. GUIDELINES FOR SUBMISSION Paper submissions must be original, unpublished work. Submissions should be in electronic format, via the START site: https://www.softconf.com/c/sac2013/. Author(s) name(s) and address(es) must not appear in the body of the paper, and self-reference should be avoided and made in the third person. Submitted papers will undergo a blind review process. Authors of accepted papers should submit an editorial revision of their papers that fits within six two-column pages (an extra two pages, to a total of eight pages, may be available at a charge). Please comply with this page limitation already at submission time. For accepted papers, registration for the conference is required and allows accepted papers to be printed in the conference proceedings. For each accepted paper, an author or a proxy attending SAC MUST present the paper. This is a requirement for the paper to be included in the ACM/IEEE digital library. A set of selected papers, which did not get accepted as full papers, will be accepted as poster papers and will be published as extended 2-page abstracts in the symposium proceedings. After the conference, selected accepted papers will be invited to a special issue of the Computer Languages, Systems and Structures journal (http://www.journals.elsevier.com/computer-languages-systems-and-structures/). IMPORTANT DATES September 21, 2012: Full Paper Submissions November 10, 2012: Author Notification November 30, 2012: Camera-Ready Copy The SAC 2013 Programming Language Track Program Committee Members Vasco Amaral, Universidade Nova de Lisboa, Portugal Roberto da Silva Bigonha, Universidade Federal de Minas Gerais, Brasil Haiming Chen, Chinese Academy of Sciences, China Johan Fabry, University of Chile, Chile Sebastian Guenter, Vrije Universiteit Brussel, Belgium Gopal Gupta, University of Texas at Dallas, USA Christian Haack, University of Nijmegen, The Netherlands Christian Hammer, Saarland University, Germany Matthias Hauswirth, University of Lugano, Switzerland Pedro Henriques, University of Minho, Portugal Michael Hind, IBM, USA Nigel Horspool, University of Victoria, Canada Zoltan Horvath, Eotvos Lorand University, Hungary Bo Huang, Intel, China Geylani Kardas, Ege University, Turkey Shih Hsi "Alex" Liu, California State University, Fresno, USA Hanspeter Moessenboeck, Johannes Kepler Universitat Linz, Austria Jesús García Molina, University of Murcia, Spain Nikolaos Papaspyrou, National Technical University of Athens, Greece Corneliu Popeea, Technical University of Munich, Germany Andre Santos, Universidade Federal de Pernambuco, Brazil Bostjan Slivnik, University of Ljubljana, Slovenia Didier Verna, EPITA, France Wuu Yang, National Chiao-Tung University, Taiwan Youtao Zhang, University of Pittsburgh, USA Track Chairs Marjan Mernik, University of Maribor, Slovenia, marjan.mernik@uni-mb.si Barrett Bryant, University of North Texas, USA, Barrett.Bryant@unt.edu
Wednesday, March 21 2012
Star TeX, the Next Generation
By Didier Verna on Wednesday, March 21 2012, 10:14 - LaTeX
I'm happy to announce that my contribution to TUG 2012, the next TeX Users Group International conference, has been accepted. Please find the title and abstract below.
Star TeX, the Next Generation
In 2010, I asked Donald Knuth why he chose to design and implement TeX as a macro-expansion system (as opposed to more traditional procedure calls). His answer was that:
- he wanted something relatively simple for his secretary who was not a computer scientist,
- the very limited computing resources at that time practically mandated the use of something much lighter than a true programming language.
The first part of the answer left me with a slight feeling of skepticism. It remains to be seen that TeX is simple to use, and when or where it is, its underlying implementation has hardly anything to do with it.
The second part of the answer, on the other hand, was both very convincing and arguably now obsolete as well. Time has passed and the situation today is very different from what it was 50 years ago. The available computing power has grown exponentially, and so has our overall skills in language design and implementation.
Several ideas on how to modernize TeX already exist. Some have been actually implemented. In this talk, I will present mine. Interestingly enough, it seems to me that modernizing TeX can start with grounding it in an old yet very modern programming language: Common Lisp. I will present the key features that make this language particularly well suited to the task, emphasizing on points such as extensibility, scriptability and multi-paradigm programming. The presentation will include reflections about the software engineering aspects (internals), as well as about the surface layer of TeX itself. Most notably, I will explore the possibilities of providing a more consistent syntax to the TeX API, while maintaining backward compatibility with the existing code base.
Tuesday, January 31 2012
JSPP: Morphing C++ into JavaScript
By Didier Verna on Tuesday, January 31 2012, 17:15 - Miscellaneous
I'm happy to announce the publication of a new technical report entitled JSPP: Morphing C++ into JavaScript. The abstract is given below.
In a time where the differences between static and dynamic languages are starting to fade away, this report brings one more element to the "convergence" picture by showing that thanks to the novelties from its recent 0x standard, it is relatively easy to implement a JavaScript layer on top of C++. By that, we not only mean to implement the language features, but also to preserve as much of its original notation as possible. In doing so, we provide the programmer with a means to freely incorporate highly dynamic JavaScript-like code into a regular C++ program.
|
|
