I'm happy to announce that my contribution to TUG 2011, the next TeX
Users Group International conference, has been accepted. Please find the
title and abstract below.
LaTeX Coding Standards
Because LaTeX (and ultimately TeX) is only a macro-expansion system, the
language does not impose any kind of good software engineering practice,
program structure or coding style whatsoever. As a consequence, writing
beautiful code (for some definition of "beautiful") requires a lot of
self-discipline from the programmer.
Maybe because in the LaTeX world, collaboration is not so widespread
(most packages are single-authored), the idea of some LaTeX Coding
Standards is not so pressing as with other programming languages. Some
people may, and probably have developed their own programming habits,
but when it comes to the LaTeX world as a whole, the situation is close
to anarchy.
Over the years, the permanent flow of personal development experiences
contributed to shape my own taste in terms of coding style. The issues
involved are numerous and their spectrum is very large: they range from
simple code layout (formatting, indentation, naming schemes etc.),
mid-level concerns such as modularity and encapsulation, to very
high-level concerns like package interaction/conflict management and
even some rules for proper social behavior.
In this talk, I will report on all these experiences and describe what I
think are good (or at least better) programming practices. I believe
that such practices do help in terms of code readability,
maintainability and extensibility, all key factors in software
evolution. They help me, perhaps they will help you too.
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-BicĂȘtre, France
Tel. +33 (0)1 44 08 01 85 Fax. +33 (0)1 53 14 59 22
Hello, and happy new year to everyone!
I'm pleased to announce that I will be holding a 90 minutes session at
the next ACCU conference in Bristol. The abstract is given below.
The Bright Side of Exceptions
In many programming languages, the term "exception" really means "error". This
is rather unfortunate because an exception is normally just something that
does not happen very often; not necessarily something bad or wrong.
Some ancient languages like C don't support exceptions at all. You need to
indicate them with specific return values from functions. Languages with
explicit support for exceptions (e.g. Java, C++ or Python) provide built-in
facilities for handling them. The most traditional approach to this is the
"try/catch/throw" system, whatever it may actually be called in your favorite
language. As it turns out, this system suffers from limitations which affect
its usability in complex situations. The two major problems are 1. the
obligatory stack unwinding on error recovery and 2. a two-levels only
separation of concerns (throwing / handling).
In this talk, we will demonstrate the benefits of using a system which does
not suffer from these limitations. More precisely:
- the stack is not necessarily unwound on error recovery, which means that the
full execution context at the time the error was signaled is still
available,
- the separation of concerns is 3-fold: the code that signals an error (throw)
is different from the code that handles the error (catch) which itself is
different from the code that chooses how to handle the error (restart).
It turns out that an exception handling mechanism like this is able to handle
more than just errors and in fact, even more than just exceptional events. In
Lisp, this system is called the "condition" system. Conditions are the bright
side of exceptions: not necessarily bad, not even necessarily exceptional.
Conditions become an integral part of your programming paradigms toolkit. We
will provide two examples of "condition-driven development". The first one
will show how to handle actual errors, only in a more expressive and cleaner
fashion than with a regular try/catch/throw system. The second example will
demonstrate the implementation of something completely unrelated to error
handling: a user-level coroutine facility.
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-BicĂȘtre, France
Tel. +33 (0)1 44 08 01 85 Fax. +33 (0)1 53 14 59 22
;; ______ _ _____ _ __ ____
;; | ____| | | / ____| ( ) /_ | |___ \
;; | |__ | | | (___ |/ | | __) |
;; | __| | | \___ \ | | |__ <
;; | |____ | |____ ____) | | | ___) |
;; |______| |______| |_____/ |_| |____/
;;
;; European Lisp Symposium 2013 - ELS'13
;; Madrid, Spain
;;
;; June 3-4, 2013
;;
;; http://els2013.european-lisp-symposium.org/
The purpose of the European Lisp Symposium is to provide a forum for
the discussion and dissemination of all aspects of design,
implementation and application of any of the Lisp and Lisp-inspired
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP,
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We
encourage everyone interested in Lisp to participate.
The main theme of the 2013 European Lisp Symposium is on the use of
these languages with respect to the current grand challenges: big
tables, open data, semantic web, network programming, discovery,
robustness, runtime failures, etc.
The European Lisp Symposium 2013 solicits the submission of papers
with these specific themes in mind, alongside the more traditional
tracks which have appeared in the past editions.
We invite submissions in the following forms:
Papers: Technical papers of up to 15 pages that describe original
results or explain known ideas in new and elegant ways.
Demonstrations: Abstracts of up to 4 pages for demonstrations of
tools, libraries, and applications.
Tutorials: Abstracts of up to 4 pages for in-depth presentations about
topics of special interest for at least 90 minutes and up to 180
minutes.
Lightning talks: Abstracts of up to one page for talks to last for no
more than 5 minutes.
All submissions should be formatted following the ACM SIGS guidelines
and include ACM classification categories and terms. For more
information on the submission guidelines and the ACM keywords, see:
http://www.acm.org/sigs/publications/proceedings-templates and
http://www.acm.org/about/class/1998.
Submissions should be directed, before March 1st, to
https://www.easychair.org/conferences/?conf=els13
Invited speakers:
Florian Loitsch, Google: Dart, why you should care.
GĂrard Assayag, Ircam: Lisp and Music Research.
Important dates:
March, 1st 2013: submission deadline
April, 5th 2013: acceptance results
June, 3-4 2013: symposium
Program Commitee:
Pascal Costanza, Intel, Belgium
Ludovic Courtes, INRIA, France
Theo D'Hondt, Vrije Universiteit Brussel, Belgium
Florian Loitsch, Google, Denmark
Christian Queinnec, UPMC, France
Kurt Noermark, Aalborg University, Denmark
Olin Shivers, Northeastern University, USA
Manuel Serrano, INRIA, France
Didier Verna, EPITA, France
Chair:
Juan Jose Garcia-Ripoll, local organizer
Christian Queinnec, PC co-chair
Manuel Serrano, PC co-chair
--