A very nice language. The first Python code I saw was in a 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 overcomplex 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 end user).

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 an 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 millimiters above the metal.

A terrible language but with a fantastic runtime environment.

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 like HTML, CSS and Javascript still make a powerful combination (for the end user).

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 Javascript).

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 pardigm 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 any more 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 programming.

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 make 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 implemented.

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 written in Javascript (my first and so far only attempt at writing a JIT compiler - something slightly more complex for a processor where self-modifying code is permitted and commonly used).

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 :-D).

I've a much smaller exprience in assembler-level 64-bit coding but I'm curretly 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).

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 at 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 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. Also 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 them.

C++ as a programming language is full of problems but still reasonable. The metaprogramming part however is really bad.

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 template expansion.

This would have been no problem if many programmers (not understanding that there is a difference between what can be done and what should be done) wouldn't had started using these unwanted and unanticipated "features" (basically bugs) to try to write real metaprogramming code.

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 monstruosities 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.