Gezien uw voorkennis is het meest logische: c#->c++->C
Normaal zou ik aanraden C++ en dan C of C#. Reden hiervoor: van C++ naar C ga je vrij simpel, je moet enkel gewoon worden aan restricties en het iets lelijker programmeren. Van C++ naar C# is dan weer een overgang die bijna niets van gewenning vraagt doordat je in oo blijft denken en zelfs simpeler is door het gebrek aan geheugenmanagement. Van C naar C++ is extreem moeilijk als je die eerste gewoon bent, omdat dat oo denken toch wel sterk verschilt van het traditionele functionele denken. Van c# naar c++ is ook moeilijker omdat je ineens zelf aan geheugenmanagement moet doen.
Maar gezien jij al talen als vb.net en java gewoon bent is de stap naar c# ZEER snel gezet en kan je op die manier snel gewoon worden aan de C-familie syntax. Daarna is down-graden naar C++ ietsje moeilijker door het leren van geheugenbeheer, maar dan weer naar C gaan is vrij eenvoudig vanuit C++, minder evident echter vanuit C#
Over assembler:
Ik zou u aanraden dit te combineren met een tutorial over computerarchitectuur (bij ons is dat nu eigenlijk zelfs 1 vak: we zien asm gewoon bij computerarchitectuur). Maar geloof me dat assembler een kuttaal is om te leren. Debuggen daarin is vrij extreem hard. Het leert je natuurlijk wel veel over de werking van de machine, maar je zal het zeer zelden kunnen toepassen, tenzij je ofwel in low-level projecten of elektronica-projecten gaat terechtkomen.
Binary is gewoon belachelijk te leren, gezien dit eigenlijk overeen komt met assembler . Een assembler compiler zet in feite rechtstreeks je commandos over van die woordjes naar enen en nullen, in de handleidingen van processoren kan je dit perfect terugvinden. Er gebeurt dus geen spicifieke interpretatie zoals in andere talen (c, c++, java, ...), wel optimalisatie als je dit wilt natuurlijk, maar dat komt neer op het wegsmijten van onnuttige commandos en zo.
edit: @ crazy_frog: je kan even simpel of zelfs simpeler een 3D-engine maken in c# als c++ hoor, het is enkel de performantie die in sommige gevallen serieus onderdoet. Maar zelfs dit valt nog sterk mee gezien c# jit-based en niet interpreted based is. c# en java worden ook niet gebruikt omdat ze simpeler zijn maar meer bug-vrij. Memory leaks zijn nog altijd de Nr.1 fouten als het aankomt op c++ programmas (zelfs firefox had hier immens last van in de 1.x-versies) en bij c# en java is het nogal extreem moeilijk om stack-corruption te krijgen doordat out-of-bounds fouten exceptions gaan opwerpen op de juiste plaats. En 3: je moet bij c# en java applicaties zelden nog massas dlls of zo gaan bijleveren, als je goed zoekt zit bijna alles al verwerkt in de std-libs.