I have been born in 1966 in Vigevano and I have always been living
here except for a few nice years during high school
when I was in Intra (on Lago maggiore) and for about one year
when I was living and working in California.
I also have a few social accounts/profiles, but I'm not very active
on any of them.
If you want to contact me for any reason feel free to send a
mail to email@example.com.
In case you are a recruiter I'm not offended at all (why
should someone be?) but please consider that I am not
currently looking for a new job.
Except for spam or spam-looking messages I normally reply to
personal emails, so if I don't please consider that your
email could have been lost somewhere. It may also take some
time for me to reply (even days).
I am a computer programmer.
I have been programming since 12, starting with programmable
calculators (a TI-57 and an HP that my brother got as a
bargain because the seller thought it was broken when it was
instead RPN based).
The first "real computer" I worked on was an Apple ][, 8
bit, 16Kb RAM and 1MHz clock (the computer I'm typing this
text now is 64 bit, 16Gb RAM and 3GHz clock x 4 CPUs, in
other words is roughly
i.e. ninety-six billions times better, not counting
the storage - magnetic tape cassette instead of a SSD).
I program in many computer languages.
Actually programming languages is one of my interests and
I have experimented quite a bit in many of them,
including exotic ones, and I also have created mines.
The languages that I currently use most often are
A very nice language. The first Python code I saw
was in an usenet post on it.comp.lang.c++ and I
thought it was pseudo-code.
It is so nice that this can even be a problem as I
got the impression that sometimes the temptation
is to write overly complex solutions because the
basic solution that one would implement in C++ is
too easy and a programmer's brain is always
looking for a challenge.
The other problem is speed compared to C++, but
this can be mitigated easily by writing C++
modules interfaced using sip, writing cython
modules or even more simply by using PyPy if the
dependencies allow it.
Python is my first choice in many cases and my rule
is roughly "Python if you can, C++ if you need".
A powerful but complex language. It has many
defects and problems, but still it can get the
job done without compromising too much (for the
The biggest problem in my opinion is the
"undefined behavior" concept that requires
programmers to never do mistakes. Paired with
the absurd complexity of the language this makes
most complex C++ software a ticking bomb just
waiting to explode.
C++ is not and will never be a high-level
language than can let you forget about its
problems and concentrate on the problem you are
working on. Sometimes it gives you that
illusion, but at the very first segfault you are
reminded that you're just a few millimeters
above the metal.
A terrible language but with a fantastic runtime
Actually the main architecture is ok, but the
details about the syntax and semantic are
terrible and make, in my opinion, the language
unsuitable for complex software.
What is really great is the runtime environment
in an HTML5 browser. The amazing combination of
three badly designed and quirk-riddled languages
powerful combination (for the end user).
## Lisp (my own dialect)
Lisp is a real eye-opener. More than a language
is a distilled essence of programming on which
you can build any language you like.
With "Lisp" I mean here the generic Lisp idea with
generic macros without self-inflicted amputations
like the ones of Scheme (template-based macros
only, only recursion for iteration) or of Clojure
(functional approach only).
For reasons that are not completely clear to me
basically no one (numerically speaking) uses Lisp
today. While ignorance (not knowing about it)
may be a reason for the majority, even who knows
very well (Peter Norvig, director of research at
Google, for example is an expert lisper) still is
not using it and this puzzles me.
I write most Lisp code in my own implementation of
Lisp named JsLisp (a Lisp compiler targeting
JsLisp is a compile-only implementation and
eval that allows the creation of new
When such a feature is not present a Lisp
compiler needs also to embed a Lisp interpreter
because Lisp macros require the ability of
execute arbitrary Lisp code at compile/read time.
The project is hosted
and some documentation (albeit a bit
outdated) is available
on JsLisp website.
Here you can see a small video showing the JsLisp
IDE (running inside a browser) and some demo
programs written with JsLisp.
I don't use C very often now because I am
currently working on mostly on PCs where resources
are abundant. Still the language is a nice
"portable assembler" with which you can implement
nice efficient algorithms without being annoyed by
registers and other limitations of CPUs.
For quite a long time I have been writing software
using the object-oriented paradigm in C using a
base object as first element of a derived object
for inheritance and using function pointers to
emulate dynamic dispatching.
Now I don't do this anymore and I simply work
with C++ when it makes sense and there are no
resource or interoperability problems.
I started writing code in assembler and, in
retrospect, I think this is a great path to
Assembler is conceptually simple (or at least it
was simple on Apple ][, with the fantastic 6502
processor from which I took my nickname).
I strongly believe that the human brain is wired
for a concrete-to-abstract path when understanding
and thus it makes sense to start with something
so simple and concrete that even the "function"
or "variable" concept are not natively present.
Once you have a mental model of how things are
working it is easy to build abstractions like
higher-level languages as BASIC. Even things
like a BASIC string are not "magic", but
something you have a rough idea of how are
For quite a long time I coded mostly in
assembler only and even the first commercial
program I completed (PaintStar, a pixel oriented
paint program for the Apple ][ family) was
written entirely in assembler.
I have devoted to my memories of 6502 a few
emulators. One is a simple text-mode only
Apple ][ emulator
written long ago in C and assembler and another
is an emulator of the processor only
attempt at writing a JIT compiler - something
slightly more complex for a processor where
self-modifying code is permitted and commonly
After 6502 I worked quite a bit using 68k
processors and x86 in 16/32 bit (including
manually selecting instructions for u/v
pipelines parallel execution in early Pentium
I've a much smaller experience in assembler-level
64-bit coding but I'm currently filling this gap
(I'm working on my first 64-bit native-code
compiler for a Lisp dialect that generates
x86-64 machine code directly, without depending
on a C compiler or an assembler).
The calling convention uses rdi for
as a pointer to the argument list
and rsi as the argument
count. Values are all stored in 64-bit
unions tagged using lowest 1-3 bits (one bit
only for floating point values, leaving 63
bits for the numeric value itself) and the
call convention is compatible with a "C"
declaration of Value foo(Value *args,
The first argument is always the closure
object itself; variadic calls do transform
the arglist parameter into a list object
in the function prologue.
I'm still reworking on the base object
representation but I expect that leaving
parameters out of the call stack will allow
a simpler gc logic still not paying too much
So far I'm impressed with the speed that
even for such a naïve implementation is not
far from much more sophisticated JIT
compilers (there is however no gc yet).
There are also programming languages I avoid.
I think that language can shape the thought process, and
this is true also for computer programming languages.
Some languages really allow you to think the previously
unthinkable and provide you with new weapons that can be
used when fighting with real world problems.
Other languages instead cripple your brain and to keep
it confined to predefined schemas. The sad part is that
this, in some cases, is not an accident but the target for
the language: the aim is not enabling programmers to do
great things, but just avoid doing big damages.
While of course big damages are not a good thing the
solution, in my opinion, is more on the education and
practice than in using blunt tools. A bad programmer is
not going to write good code if provided a bad language.
Languages that I prefer to avoid are
## Java (crippled and limited by design).
Long ago, when I was working for Enel, I was
given the opportunity of following a Java
training and I got a Java 1.1 certification.
Even in the course I however got the impression
that the language was full of bureaucracy and
wrinkles designed to constrain.
I did not follow closely the evolution of the
language as I decided back then that I would
try to avoid the language if possible. So far my
strategy has been successful.
## PHP (obscenely crippled because designed by
PHP is bad, so bad that's not even funny. It's
so bad that it's hard to distinguish it from a
caricature of bad programming languages.
Amazingly enough it's a winner on the web: the
worst possible language is probably one of the
most popular. Go figure.
In my opinion the bad parts of PHP (most of it)
are however due to simple ignorance and not to a
deliberate design. Moreover the limitations in the
language are there because the implementers
didn't know how to get certain features in, not
because they didn't want programmers to use
## COBOL (may be ok in '70s as better than assembler;
## FORTRAN (ditto).
## C++ extreme metaprogramming
C++ as a programming language is full of
problems but still reasonable. The
metaprogramming part however is awful.
Exploiting what I think was an unwanted
side-effect of the implementation of C++
templates, after some years people discovered
that the absurdly intricate rules for
overloading resolution and the strange rule
SFINAE ([template] Substitution Failure Is Not
An Error) could be used to make IFs and
recursion-based loops at compile time during
This would have been no problem if many
programmers (not understanding there is a
difference between what can be done and
what should be done) wouldn't have started
using these unwanted and unanticipated
"features" (basically bugs) to try to write real
This amazingly enough ended up in huge
template-based undebuggable libraries that take
forever to compile, that exhaust at compile time
all existing RAM, that give tens of screenfuls
of error message when you make a typo.
Even more amazingly this absurd way of
programming made it into the standard. Compilers
over the years have been fixed to handle "complex"
(i.e. non completely trivial) templates when in
the early days for example recursion limit was a
problem. C++11 now incorporates some of the
monstrosities that template metaprogramming
obsessed guys designed.
Thanks to this absurd choice of chosing
brainf**k to do metaprogramming it's still too
much to ask for a real loop, data structures or
even just enumerating members of a class at
compile time. Non-trivial metaprogramming in C++
is still impossible (and IMO it's not something
that will be fixed in any foreseeable future).
My choice for metaprogramming in C++ is writing
external code generators in Python. Of course
not an ideal solution as there is no compiler
telling you what it knows and you're forced
instead to work at the text level (a nightmare
thanks to C++ very complex grammar), but still
way better than writing metaprograms in such a
sad and poor environment.
It is now several years that I am not using Windows anymore
neither at home nor at work. At home I am currently using a
Linux Arch system and I also have an old Mac mini and an old
iPad on which I experiment a bit on OsX. I only use Windows
to check that software works reasonably on those systems.
I studied pure math at university (and loved it) but I always
worked programming computers, something for which I only have
a high-school diploma.
I took my degree in math while working full time because I
liked the subject (I fell in love with the book Algebra of
I. N. Herstein, one of the reasons of my change from
engineering to math).
I never formally used my degree for work (except that I was
able to work in the US thanks to it because immigration H1-B
rules at the time were translating "specialized" with
I don't believe too much in the value of formal studies:
much much more important to me is the personal dedication
and interest into the subject. For example, I know very good
programmers that have no formal training at all (not even
high-school level) and instead I know IT graduated that
literally don't understand anything they are talking about.
When I'm requested to evaluate someone, having a sci/tech
degree only means to me that the subject can (or could at
the time) provide some continuity: it is not a proxy for
being smart or being able to deliver in the specific field.
Of course NOT having a degree doesn't mean the subject
cannot provide continuity.
I am also a bad pianist, a bad chess player, bad speedcuber and
bad in sports. If you however never attempted seriously any of
these activities I am probably much better than you (with bad I
mean "worse than the average of who does it seriously").
I started studying piano when a kid because my mother wanted
us to try many different paths when young (thanks mom!).
I didn't practice much however, and in the end I dropped out
of the musical school after about three years of piano.
Many years later I fell in love with Chopin and got back to
piano this time self-teaching. The following is a video of
one of my early takes at what is considered the dream of
hobbyist piano players: Chopin Fantaisie Impromptu Op. 66...
I am a FIDE rated player with a current rating of about
1800. This means that I am weaker than the average of rated
players but that I just don't make random moves on the board
so even a professional player needs to pay some attention.
I am also a chess arbiter and a few times every year I spend
time in chess tournaments.
I also take care of online broadcasting of chess events
using a software I wrote myself after reverse-engineering
the serial protocol used by DGT chessboards (the software
provided with the board was pricey and, more importantly,
really really bad).
I own 5 DGT boards and about 20 wooden tournament boards and
clocks with which I'm happy to help friends when they need
to organize a chess tournament.
I also wrote several chess-playing programs some of which
ended up being stronger than me (writing a chess engine is a
very good programming exercise in my opinion, especially for
I first met Rubik's cube thanks to my brother in 1983, but
after a short time I forgot about it. Recently I found it
back in my mother's house and decided to look at what it is
now. I re-started learning it using more efficient methods
(I'm using CFOP)
and my average is now around 35 seconds... my aim is to get
to have an average below 30 seconds (it's going to be still
a long way :-D ).
I wonder why Rubik's cube is not used in math classes when
teaching about finite groups, it's IMO a very good example
and a lot of apparently strange concepts like subgroups,
cycles, closures, can be shown quite clearly on the cube and
other twisty puzzle variations.
I also own and love
but I'm still horribly slow at solving it... somehow I've
always had sort of a fetish for dodecahedrons.
I've been regularly practicing karate, ski and swimming for
some time; now I enjoy running for medium distances (about
40min). I've ran a few half-marathons (I was tempted by the
full marathon but read that while being of course feasible
by most people it's not really good for health as it's a bit
past the sustainable limit).
I live in Vigevano, a small city (~60k residents) not far from
Milan, in northern Italy.
I work for COMELZ, a company
that produces machines and software for the shoe/apparel/leather
The company recently acquired
a company created by long time friends from Florence.
Now the software team working on comelz products is much
bigger (tens of developers) and much more organized with all
pros and cons of the situation.
I've been basically of a lone wolf for very long time and
there are a few aspects of working in big groups I'm slowly
getting used to again (like meetings ;-) ).
I wrote much of the initial version of software for our
cutting machine family (CMxx/CZxx) and this allowed me to
work in several interesting areas:
## Axis control
In our company we produce ourselves the brushless
motors we use in our machines, both the mechanical
parts and the control electronic.
I wrote the software that computes online the space
positioning with 1ms accuracy minimizing total time
while keeping the motion below dynamic limits.
## Work plan optimization
The main cutting machine family is multi-headed, in
other words there are multiple cutting heads working
simultaneously on the same work area.
Simplifying a bit, work plan optimization is like
solving TSP instances adding the time dimension and
where there are multiple travelers that cannot get
closer than a certain distance from each other.
## Artificial vision
Our machines can also be equipped with cameras than
can be used for several purposes; from user
interface (pen tracking) to positioning error
compensation to printed material logo detection for
cut shape alignment to leather boundary detection.
I also recently worked on the interesting problem of
texture classification and found a novel "smart"
filtering approach that allows our machines to work
on previously difficult to handle materials (for
example single color or low contrast digital fabrics
where the design is visible only because of texture
## Cut waste minimization
This is the very interesting problem of placing
parts inside a leather, sheet or roll so that the
minimum amount of material is wasted. I was able to
design an implement algorithms that performed quite
well compared to the current state of the art in
Nesting of a shoe model on leather avoiding defects.
Of course even the most basic version of the problem
is NP-complete as it can be trivially seen that as
1-D subcase you can model the knapsack.
This is also my main area of interest at the moment.
to name a few.
I also designed and partly implemented early versions of our
specialized CAD/CAM software for the shoe/apparel/leather
a full reimplementation and extension of a previous CAD
software of the company.