Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 135

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 135

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 187

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 188

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 189

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 194

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 195

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 196

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 197

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 241

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 264

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 269

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 275

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 285

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 286

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 296

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 297

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 298

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 308

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 309

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 310

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 311

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 321

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 322

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 323

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 324

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 325

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 497

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 527

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 540

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 587

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 626

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 668

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 668

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 670

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 673

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 682

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 688

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 693

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php on line 699

Deprecated: Function get_magic_quotes_gpc() is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 410

Deprecated: Function get_magic_quotes_gpc() is deprecated in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 410

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 272

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 274

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/public/lib.urlhandlers.php on line 110

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/public/lib.urlhandlers.php on line 130

Warning: Cannot modify header information - headers already sent by (output started at /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.json.php:309) in /home/didierve/didierverna.net/blog/inc/libs/clearbricks/common/lib.http.php on line 295
Didier Verna's scientific blog: Lisp, Emacs, LaTeX and random stuff. 2024-01-31T17:45:28+00:00 Didier Verna urn:md5:a22c53786aff986a2da4c770c233a8f9 Dotclear urn:md5:3bc9cf9a8b41a032bdf8c87c1df194a1 Tuesday, March 3 2020 Tuesday, March 3 2020 Didier Verna Miscellaneous computer scienceconferenceProgrammingProgramming Languages <pre> 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 </pre> https://www.didierverna.net/blog/index.php?post/2020/03/03/Onward%21-Essays-2020-Call-for-Papers#comment-form https://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/163 urn:md5:d8daa14fee6247e4fd01c604457d81dc Tuesday, February 26 2013 Tuesday, February 26 2013 Didier Verna Miscellaneous conferenceDynamic LanguagesProgramming Languages <pre> 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 &quot;forgotten&quot; 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 </pre> https://www.didierverna.net/blog/index.php?post/2013/02/26/Dyla-13%2C-7th-Workshop-on-Dynamic-Languages-and-Applications#comment-form https://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/112 urn:md5:c259990b394d3d3cd44f1884d8d1a38f Thursday, July 12 2012 Thursday, July 12 2012 Didier Verna Lisp ArtCommon LispProgramming Languagessoftware <p>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.</p> <p>This is funny because do you know of any religious wars about hammers? So what's the difference?</p> <p>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 <em>know</em> knows better) in the audience who goes:</p> <blockquote><p>So, yeah, what you're doing is just C code, and you have to type manually, and it's <strong>ugly</strong>. So if it's just for writing C code, I don't see the point in using another language.</p></blockquote> <p>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 <em>really</em> 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 <em>at all</em> 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.</p> <p>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.</p> <p>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 <a href="https://www.didierverna.net/sciblog/index.php?post/2008/09/08/Lisp%2C-Jazz%2C-Aikido">Aikido</a> 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?</p> <p>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 <q>Hey, look, I'm vulnerable right here!!</q>. 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 <q>I don't like this piece of art</q>, you're actually saying <q>I don't like the artist</q>. Then, it's up to artist to handle the fact of not being liked.</p> <p>And that's the whole problem, which, as a <a href="http://www.didierverna.com">musician</a>, 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.</p> <p>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.</p> <p>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 <strong>you</strong>. And contrary to the hammer, your sticky programming language, being intrinsically bound to the artwork, also becomes part of <strong>you</strong>. 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.</p> <p>It's good to consider programming as art. Unfortunately, this also means that there will always be language wars.</p> https://www.didierverna.net/blog/index.php?post/2012/07/12/Language-Wars#comment-form https://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/105 urn:md5:7307e4e19000561944fbca6bdffc5f28 Tuesday, May 22 2012 Tuesday, May 22 2012 Didier Verna Miscellaneous ACMconferenceProgramming LanguagesSAC <pre> CALL FOR PAPERS SAC'13 - ACM 2013 SYMPOSIUM ON APPLIED COMPUTING Technical Track on &quot;Programming Languages&quot; 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 &quot;Alex&quot; 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 </pre> https://www.didierverna.net/blog/index.php?post/2012/05/22/Call-for-Papers%3A-ACM-SAC-13-PL%3A-ACM-Symposium-on-Applied-Computing%2C-Programming-Languages-track#comment-form https://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/102 urn:md5:93c43e63a05de4e3e5699b499982a951 Wednesday, March 21 2012 Wednesday, March 21 2012 Didier Verna LaTeX Common LispconferenceProgramming LanguagesTeXTUG <p>I'm happy to announce that my contribution to <a href="http://www.tug.org/tug2012/">TUG 2012</a>, the next TeX Users Group International conference, has been accepted. Please find the title and abstract below.</p> <p><br /> <br /></p> <p><strong>Star TeX, the Next Generation</strong></p> <p>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:</p> <ol> <li>he wanted something relatively simple for his secretary who was not a computer scientist,</li> <li>the very limited computing resources at that time practically mandated the use of something much lighter than a true programming language.</li> </ol> <p>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.</p> <p>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.</p> <p>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.</p> https://www.didierverna.net/blog/index.php?post/2012/03/21/Star-TeX%2C-the-Next-Generation#comment-form https://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/100 urn:md5:741576760db6c8f42deffff0ff1de886 Tuesday, January 31 2012 Tuesday, January 31 2012 Didier Verna Miscellaneous CJavaScriptProgramming Languagespublicationsoftware <p>I'm happy to announce the publication of a new technical report entitled <a href="https://www.didierverna.net/sciblog/public/chedeau.12.tr.pdf">JSPP: Morphing C++ into JavaScript</a>. The abstract is given below.</p> <blockquote><p>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.</p> </blockquote> https://www.didierverna.net/blog/index.php?post/2012/01/31/JSPP%3A-Morphing-C-into-JavaScript#comment-form https://www.didierverna.net/blog/index.php?feed/navlang:en/atom/comments/96