W tamtych czasach programiści pracowali znacznie bliżej metalu. C było zasadniczo wyższym poziomem zamiennika dla montażu, który jest prawie tak blisko sprzętu, jak to tylko możliwe, więc było rzeczą naturalną, że potrzebne były wskaźniki, aby skutecznie rozwiązywać problemy z kodowaniem. Wskaźniki są jednak ostrymi narzędziami, które mogą powodować duże uszkodzenia, jeśli są używane beztrosko. Również bezpośrednie użycie wskaźników otwiera możliwość wielu problemów związanych z bezpieczeństwem, które wtedy nie były problemem (w 1970 r. Internet składał się z kilkudziesięciu maszyn na kilku uniwersytetach i nawet nie był tak nazywany ...), ale odtąd zyskuje na znaczeniu. Tak więc obecnie języki wyższego poziomu są świadomie zaprojektowane w celu uniknięcia wskaźników surowej pamięci.
Powiedzenie, że „zaawansowane rzeczy zrobione w VB.Net lub Java nie są możliwe w C”, pokazuje co najmniej bardzo ograniczony punkt widzenia :-)
Po pierwsze, wszystkie te języki (nawet asembler) są kompletne, więc teoretycznie wszystko, co jest możliwe w jednym języku, jest możliwe we wszystkich. Wystarczy pomyśleć o tym, co się stanie, gdy fragment kodu VB.Net lub Java zostanie skompilowany i wykonany: w końcu jest tłumaczony na (lub odwzorowywany) kod maszynowy, ponieważ jest to jedyna rzecz, którą maszyna rozumie. W skompilowanych językach, takich jak C i C ++, można uzyskać pełną treść kodu maszynowego równoważną oryginalnemu kodowi źródłowemu wyższego poziomu, jako jeden lub więcej plików / bibliotek wykonywalnych. W językach opartych na maszynach wirtualnych uzyskanie bardziej reprezentatywnego kodu maszynowego twojego programu jest trudniejsze (i może nawet nie być możliwe), ale w końcu jest ono gdzieś w głębokich zakamarkach systemu wykonawczego i JIT.
Teraz oczywiście jest zupełnie inne pytanie, czy jakieś rozwiązanie jest wykonalne w określonym języku. Żaden rozsądny programista nie zacząłby pisać aplikacji internetowej w asemblerze :-) Warto jednak pamiętać, że większość lub wszystkie te języki wyższego poziomu są zbudowane na bazie ogromnej ilości kodu wykonawczego i kodu biblioteki klas, dużej części który jest implementowany w języku niższego poziomu, zwykle w C.
Aby przejść do pytania,
Czy uważasz, że wiedza na temat wskazówek dla młodych ludzi [...] jest ważna?
Pojęciem wskaźników jest pośrednictwo . Jest to bardzo ważna koncepcja i każdy dobry programista IMHO powinien ją zrozumieć na pewnym poziomie. Nawet jeśli ktoś pracuje wyłącznie z językami wyższego poziomu, pośrednictwo i referencje są nadal ważne. Niezrozumienie tego oznacza brak możliwości korzystania z całej klasy bardzo potężnych narzędzi, co poważnie ogranicza zdolność rozwiązywania problemów na dłuższą metę.
Tak więc moja odpowiedź brzmi tak, jeśli chcesz zostać naprawdę dobrym programistą, musisz także zrozumieć wskaźniki (jak również rekurencję - to kolejny typowy problem dla początkujących programistów). Być może nie musisz zaczynać od tego - nie sądzę, aby C był obecnie optymalny jako pierwszy język. Ale w pewnym momencie należy zapoznać się z pośrednią. Bez tego nigdy nie będziemy w stanie zrozumieć, w jaki sposób używane przez nas narzędzia, biblioteki i frameworki. A rzemieślnik, który nie rozumie, jak działają jego narzędzia, jest bardzo ograniczony. Szczerze mówiąc, można go zrozumieć także w językach programowania wyższego poziomu. Jednym dobrym testem lakmusowym jest prawidłowe wdrożenie podwójnie połączonej listy - jeśli możesz to zrobić w swoim ulubionym języku, możesz twierdzić, że wystarczająco dobrze rozumiesz pośrednictwo.
Ale gdyby nie cokolwiek innego, powinniśmy to zrobić, aby nauczyć się szacunku dla dawnych programistów, którym udało się budować niewiarygodne rzeczy za pomocą śmiesznie prostych narzędzi, jakie mieli (w porównaniu z tym, co mamy teraz). Wszyscy stoimy na barkach gigantów i dobrze jest nam to przyznać, niż udawać, że sami jesteśmy gigantami.