Zbliżają się święta a cóż lepszego można dostać pod choinkę niż samouczek? A poważnie, pomysł jest następujący: do 10. grudnia dyskutujemy ramy samouczka, do 17. prezentuję pierwszą wersję i jest 5 dni na zgłaszanie uwag (dlatego “my piszemy”). 24. pod choinką ląduje samouczek.
Zdaję sobie sprawę z tego, że “społeczność pisząca samouczek” to nie jest najlepszy pomysł, bo i tak kończy się na tym, że pisze jedna osoba. Dlatego deklaruję, że taki samouczek sporządzę, ale że jestem przekonany o własnej ułomności i o tym, że popełnię błędy, nieoczywiste rzeczy przemilczę, itd., potrzebny będzie Wasz wkład (czyli krytyka samouczka).
Jako że tydzień na napisanie wartościowego (oby) tekstu to naprawdę niewiele czasu, nie należy się spodziewać cudów. Dlatego należy w miarę logicznie zawęzić ramy samouczka. Osobiście uważam, że najlepiej zacząć od podstaw, więc nie obędzie się od informacji o tym jak komputer liczy i dlaczego. Ale chcę uniknąć suchych, paskudnych opisów i posługiwać się prostymi analogiami. Moim zdaniem tak łatwiej wiedzę przyswoić. Chcę się skupić na C (nie C++). Przyczyna jest prosta: zanim się zacznie biegać, należy nauczyć się raczkować i chodzić. Dobre zrozumienie C jest kluczem do zrozumienia takich koncepcji jak “value parameter passed by reference” w C#. Nie rozumiejąc jak działa komputer nie jest się w stanie pisać dobrego kodu w żadnym języku.
Zatem sugerowany zakres to (w nawiasie szacunkowa ilość stron tekstu):
procesor i pamięć (2)
reprezentacja liczb i działania na liczbach całkowitych (3)
zmienne i widoczność (2)
struktura programu (5)
wskaźniki, ciągi znaków (5)
To 15-20 stron tekstu, którego nie muszę pisać. Ale chcę. Jakieś uwagi, propozycje? Konstruktywna krytyka?
Jeśli ma to być naprawdę dla początkujących to może lepiej jest przemilczeć istnienie wskaźników a np. napisać o podstawach tworzenia funkcji czy operacjach na tablicach (odwołanie przez indeks). Myślę iż warto wspomnieć także o operacjach na liczbach rzeczywistych (problem zera maszynowego).
Sądze iż opisanie funkcji jest ważne aby zrozumieć np. wywołanie tak elementarnego scanf czy printf. Godne uwagi jest także chociaż pobieżne opisanie podstawowych standardowych bibliotek. , , , ,
Trzeba także wspomnieć o reprezentacji znaków w pamięci kody ASCII.
Jestem też za pomysłem Derka. Ale jako to ma być samouczek raczej dla początkujących to tylko pobieżnie(można też nie opisywać math.h).
Jestem za opisaniem wskaźników. To wielkie i potężne rzeczy które trzeba znać(i używać), chociaż stwarzają początkującym(i nie tylko początkującym ) wiele kłopotów.
Można by też opisać rodzaje programowania(OOP, strukturalne liniowe itp.).
Inicjatywa bardzo dobra, zgłaszam się do pomocy! Te 5 myślników to jak najbardziej wstęp do programowania. Do tego wspomniane wyżej instrukcje warunkowe i pętle - również podstawowe zagadnienia i to raczej proste, a co najważniejsze występujące w praktycznie każdym języku programowania.
Problem w tym, że mój czas nie jest z gumy. Wolę wyczerpać 3-4 tematy niż liznąć 10 i zrobić je pobieżnie. Na kolejnym samouczku, który wymaga biegania po zagadnieniach praktycznie nikt nie skorzysta. Właśnie dlatego nie chciałem OOP, nie chciałem wyjaśniać poszczególnych bibliotek, chciałem pominąć zmienne rzeczywiste.
Operacje na tablicach to temat, który powinien zostać omówiony razem ze wskaźnikami. Jest kilka istotnych różnic między *tab i tab[] i warto je przedstawić tam, gdzie się pojawią. O reprezentacji danych (w tym znaków) w pamięci oczywiście chcę napisać (procesor i pamięć + wskaźniki i ciągi znaków).
Więc o ile zgadzam się, że instrukcje warunkowe i pętle to “must have” o tyle do “lizania” bibliotek nie jestem przekonany. Szczerze mówiąc zastanawiałem się nawet nad takim niekonwencjonalnym podejściem jak NIE wyświetlanie niczego na ekranie. Śledzenie kodu z debuggerem to umiejętność, którą 99% samouczków pomija. Tyle że to może być zbyt nietypowe, by kogokolwiek przyciągnęło. Nie bez przyczyny ludzie wolą “od zera do gier kodera” od setek innych tutoriali.
Ciekawe rozwiązanie z tym debuggerem. Ale jak tak, to można by też dopisać jakiś kursik pt. “Jak korzystać z debuggera” bo raczej niewielu początkujących to umie. Może być to dosyć trudne bo jest tyle IDE zintegrowanych z debuggerem, że ciężko wszystkie opisać. No chyba, że tylko dwa(Microsoftowy i GDB+Dev-c++).
@Ryan Myślę iż warto opisać funkcje (programowanie proceduralne) ale co do nowatorskiego podejścia bez wyświetlania niczego na ekranie… forum zbytnio na tym ucierpi “Hej program się kompiluje ale nic nie widać POMOCY !”. Co do samego debugowania to naprawdę jestem za… ale trzeba to opisać w różnych IDE np Dev a Visual C++ 2008 kolosalna różnica. Opcje debugowania lepiej zostawić na po świętach.
Wszystkie debuggery są zjadane przez kd i windbg, więc w zasadzie wystarczy opisać te dwa. Poza tym to są de facto standardowe kompilatory - każda firma pisząca dużo w C/C++ używa klasycznych debuggerów windowsowych lub wbudowanego z VS (oczywiście jestem brzydkim chłopcem i zupełnie pomijam Linuksa).
Według mnie to dobry pomysł. A w jakiej formie samouczek będzie publikowany? Jako strona internetowa?
Poza tym chciałbym dodać, że (przynajmniej mi) najłatwiej się uczyć na przykładach.
To tak jak z językiem, najpierw słuchamy i sami próbujemy, a potem uczymy się gramatyki, ortografii itp. (no, ale nauczyciele angielskiego tego nie rozumieją…)
Nie. Zwyczajnie nie mam czasu na pałowanie się z Linuksem. Nie używałem od ponad roku i nie mam ani chęci ani kompa na którym mógłbym go zainstalować. Poza tym wierzę, że mój kod jest bardzo przenośny - nie używam potworków typu conio.
@GL1zdA: poniekąd zgadzam się. Ale z drugiej strony uważam, że “back to basics” jest dzisiaj potrzebne bardziej niż kiedykolwiek. Jasne, że dziś można szybko zacząć programować. I nawet można całkiem szybko mieć wymierne efekty w postaci działającego programu. Ale jakość kodu ma sporą zależność o tego czy autor rozumiał jak jego kod będzie działał. Oczywiście w dobie Unicode wspominanie o ANSI czy ASCII jest bardziej ciekawostką a BCD ma rację bytu w kodzie dla systemów wbudowanych. Ale U2 jest moim zdaniem niezbędne.
A poważnie, pomysł jest następujący: do 10. grudnia dyskutujemy ramy samouczka, do 17. prezentuję pierwszą wersję i jest 5 dni na zgłaszanie uwag (dlatego “my piszemy”). 24. pod choinką ląduje samouczek.
Dlatego deklaruję, że taki samouczek sporządzę, ale że jestem przekonany o własnej ułomności i o tym, że popełnię błędy, nieoczywiste rzeczy przemilczę, itd., potrzebny będzie Wasz wkład (czyli krytyka samouczka).
Nie rozumiejąc jak działa komputer nie jest się w stanie pisać dobrego kodu w żadnym języku.
) wiele kłopotów.