Polecam żebyś w pierwszej kolejności zapoznał się z paradygmatami programowania. Jeśli zmierzasz w kierunku wymienionych tu języków to szczegółowo musisz poznać paradygmat programowania obiektowego, po poznaniu tych podstaw nauka każdego kolejnego języka to będzie przyjemność.
Bardzo czytelnym podręcznikiem był dla mnie Thinking in c++/Thinking in JAVA. Nie mówię o czytaniu całości bo to bez sensu ale właśnie do podstaw.
Temat trochę umarł, a ja polecę inne podejście - może się komuś przyda. Nazwijmy to just-in-time learning.
Wymyśl sobie projekt (może na początek być coś prostego) - np aplikacja do pobierania wyników lotto ze strony totalizatora i robienie z tego statystyk.
Ważne, żeby nie było do tego gotowca w sieci (a jak znajdziesz taki to masz nie korzystać) i rusz głową. Podstawy znajdziesz w wyżej wymienionych tutorialach. Rozwiązania różnych problemów na stackoverflow i pisz swój program. Ważne żebyś w danym momencie uczył się tylko tego co jest Ci w danym momencie potrzebne.
Takie podejście nauczy Cię na początku znacznie więcej niż jakakolwiek książka czytana od deski do deski - z czasem sam zauważysz gdzie masz braki i będziesz wiedział jakiej książki szukać.
Pierwsze kroki w jakimkolwiek języku wyglądały by mniej więcej tak:
Konfiguracja srodowiska
Hello world
Pobranie tekstu z pliku (np na początek zapisujesz sobie liczby w pliku txt, potem stronę jako html z dysku, potem pobierasz bezpośrednio z serwera)
Wyszukiwanie tekstu (najpierw przez funkcje standardowe C++, potem Boost, czy cokolwiek innego wybierzesz)
Zapisanie wybranych wartości do tablicy
Eksport tablicy na dysk (np jako plik txt)
Jest prosto - teraz komplikujemy wg uznania
2a Zrobienie programu chodzącego w tle tak, żeby nie musieć go uruchamiać samoczynnie (np cron pod linux)
3a Może pobrać treść bezpośrednio ze strony totalizatora (można wykorzystać jakąś bibliotekę)?
4a To może wyszukiwanie wyrażeń regularnych
5a Kontenery (może lista może vector)
6a A może zapisywać do bazy danych?
2b Może jakiś interfejs? (może pod GTK lub Qt a może dotNET)
5b Może graficzna reprezentacja wyników?
6b Może powiadomienie o pobranych wynikach i statystykach wysłane na mojego maila?
I tak można w nieskończoność…
Ucząc się poprzez rozwiązywanie napotkanych problemów szybko nauczysz się programować, korzystać właściwie z google i selekcjonować źródła wiedzy 
Cron to cykliczne uruchamianie programu/skryptu a nie stworzenie programu działającego w tle. Aby program działał w tle musi być usługą, a usługi programuje się troszeczkę inaczej niż zwykłe apki.
Problem z Twoim podejściem jest taki, że mało komu chce się pomagać takim osobą. Jak ktoś się tak uczy i chce się dowiedzieć jak coś zrobić to nie jest w stanie opisać swojego problemu i nie jest w stanie zadać pytanie bo sam nie wie czego chce ponieważ brakuje mu wiedzy podstawowej. Ludzie którzy znają się i np programują widząc pytania których autor sam nie wie czego chce i co chce zrobić, a już na pewno nie wie jak to chce zrobić, a sposobów jest cała masa, to po prostu nie chce im się nawet pomagać bo co z tego że powiedzą aby zrobił tak czy siak jak taka osoba nie ma pojęcia o czym do niego piszą. W praktyce wygląda to tak że nie wystarczy powiedzieć jak uzyskać dany efekt lecz trzeba go wytłumaczyć dokładnie i jeszcze cofnąć się by wytłumaczyć podstawy problemu.
Przez takie podejście ludzie często się zrażają bo nikt im nie chce pomóc, przez co porzucają marzenia i zrażają się do tematu.
Ucz sie nie tyle jezyka, co metodologii programowania, architektury, jezykow obiektowych i funkcjonalnych, procedur testowych, wzorcow projektowych. Same kodowanie to malutka sprawa w procesie tworzenia oprogramowania, i zmiana jezyka na inny to pare tygodni, jezeli masz solidna wiedze o procesie.
a na poczatek, polecalbym ksiazki z head first:
head first object-oriented analysis and design, python (zawsze przydatny, neizaleznie od glownego jezyka), i inne. Ale tylko jako uzupelnienie do wlasnych cwiczen i wiedzy z internetu.
Niby tak, ale sprawa nie jest aż taka prosta. Ostatnimi laty języki obudowują się dosyć zamkniętymi ekosystemami. Co z tego, że pętli w C, Javie i C# używa się prawie tak samo, skoro biblioteki, frameworki, serwery aplikacji, managery projektu/budowania/integracji to zupełnie inne kosmosy, których naprawdę dogłębne poznanie to kwestia nie przejrzenia tutoriali, tylko lat praktyki? Do tego dochodzą konwencje pisania kodu, gdzie odnoszenie się do innych języków może nawet szkodzić. Jakiś czas temu firma, w której pracuję zrezygnowała z pisania kodu na rozmowach kwalifikacyjnych. Zamiast tego daje się kandydatowi jakiś legacy kawałek do review i dopytuje, skąd taka czy inna sugestia zmiany, często wchodząc przy tym na tematy niemal filozoficzne. Wtedy od razu wiadomo, kto poświęcił parę lat, a kto parę tygodni.
tl;dr
Tak, przestawienie się na inny język to kwestia paru tygodni. Ale na poziomie małych aplikacji. Kolosy z rozbudowanymi środowiskami developerskimi i milionami linii kodu to inna bajka.
Tak wiem - na poziomie nauki programowania gdzie ktoś pyta się o książkę to mało istotny niuans Bardziej chodziło o przedstawienie samej idei nauki w locie.
Co do chęci pomagania - naprawdę na większość problemów początkujących programistów już są odpowiedzi i wystarczy czytać. A jak ktoś pyta pod koniec semestru jak zrobić program sortujący bąbelkowo i widać, że jeszcze nawet nie wie na czym to polega to rozumiem, że entuzjazm do udzielenia odpowiedzi może być ograniczony
Kolosy z milionami linii kodu wymagaja setek programistow. W takim wypadku tworzenie indywidualnych lini jest naprawde drugorzedne, i bardzo latwo sie w to wbic. Unit test, dokumentacja klas, przepisujesz nazwe klas/metod i wypelniasz je kodem.
I jasne, nie bedziesz po paru tygodniach ekspertem, ale bedziesz w stanie pisac podstawowy kod jako programista, ale jako architekt nie bedziesz specjalnie sie w to ladowal…
tl;dr: wielkosc aplikacji nie ma znaczenia, jezeli projekt jest dobrze prowadzony;)
Niekoniecznie. Pracowałem przy takim. Ludzie przychodzili i odchodzili, ale grupa go rozwijająca nigdy nie była liczniejsza niż kilkanaście osób naraz.
Przeciwnie. Jedną “drugorzędną” linią kodu możesz zepsuć ogromny, skomplikowany mechanizm. Przy rozwijaniu takiej maszynerii najprawdopodobniej robisz coś, o czym nie myślano kilka-kilkanaście lat temu w czasie projektowania systemu. Wszystkie oczywiste rozwiązania zostały wyeksploatowane, więc czasem trzeba używać “dirty hacków”, unikając przy tym efektów podobnych zabiegów poprzednich pokoleń programistów.
Może i mam pecha, ale jeszcze nigdy nie widziałem sporego, nietrywialnego, niemłodego (na produkcji) projektu, którego stan określiłbym jako “naprawdę dobry”.