🚀 go-pugleaf

ASSmodeus wrote:
> Wydaje mi sie, ze to troche demonizowanie jest.
> C czy C++ raczej nie wybacza bledow, a to jest dobra metroda na 
> nauczenie porzadnego, uporzadkowanego i przejrzystego programowania.

Zgadzam się, że C/C++ nie wybaczają błędów.
Swego czasu spędziłem naprawdę dużo czasu nie mogąc znaleźć
prostego błędu w pętli w C++. Błędu, który by mi JAVA i C# od
razu wskazały. Oczywiście błąd był mój, ale czasu straconego
nic mi nie zrekompensuje. I w związku z tym nie uważam, że
dobrą metodą jest nauka na takich błędach.
W C++ spędziłem mnóstwo czasu w debuggerach poszukując błędu,
a w C# włączam ten tryb tylko wtedy gdy wiem gdzie błąd wystąpił.
Popełniam błędy, jak większość programistów, ale cieszę się,
że pracuję z językiem, który w większości przypadków wyręcza
mnie z nudnego i uciążliwego poszukiwania drobnych pomyłek.
I dzięki temu skupiam się w 95% na działaniu modułu lub programu.

> Poza tym jezyki nizszego rzedu bardziej skupiaja sie na algorytmie niz 
> na obiekcie.
> A to z kolei dobra metoda nauki optymalnego tworzenia kodu.

Algorytmy żadko kiedy są obiektowe i wówczas pisze się je w
taki właśnie nieobiektowy sposób. Nie ogranicza to w żaden sposób,
żaden z języków obiektowych więc w czym problem?
Nie chcesz pisać obiektowo, to nie piszesz. To idea OOP
opiera się na obiekcie, a nie jezyk jest skazany na OOP.
Metody, które uruchamiają aplikacje w JAVA i C# są
metodami statycznymi dokłatnie tak samo jak w C i C++.

> Wiem, ze sa narzedzia prostrze i pozwalajace szybko tworzyc pieknie 
> wygladajace aplikacje, ale uwazam, ze nauczac sie ich powinno ludzi, 
> ktorzy potrafia utrzymac samodyscypline podczas programowania.
> 
> Poza tym tak rozbudowane narzedzia narzucaja zazwyczaj wiele ograniczen, 
> o braku jakiejkolwiek optymalizacji nie wspominajac.
> Ale jak to mowia cos za cos.

Nie zgadzam się z tym. Tu nie chodzi o narzędzia.
Ani w C# ani w JAVA'ie narzędzia nie mają nic wspólnego
z kompilatorem.
Framework lub SDK - są tu słowami kluczowymi. Zestaw gotowych
klas, które można łatwo użyć. Co nie ogranicza możliwości,
żeby móc "wynaleźć koło" i napisać algorytm sortowania samemu.

> W kazdym razie, ja uwazam, ze nauka podstaw jezykow strukturalnych 
> powinna byc prowadzona w szkolach (oczywiscie w nie powinna byc 
> dominujaca).

Uważam, że w dzisiejszych czasach szkoły<wyższe mogłyby
sobie odpuścić naukę języków strukturalnych. Powinny skupić
się raczej na idei programowania, która nie musi nawet obejmować
OOP. I bez względu na konkretny język i "narzędzia".
Tylko wówczas młodzież nie będzie bała się programowania
jak ognia, a dowie się w jaki sposób można tą wiedzę wykorzystać.

Co innego myślę, że na studiach conajmniej 1 jezyk strukturalny
powinien się pojawić. Ale to temat do osobnej dyskusji.

> Przeciez najpierw, zeby pilkarz potrafil dryblowac, kiwac, podkrecac 
> itd. musi wiedziec jak w ogole kopnac pilke.
> Bo ten co zacznie uczys sie "top2down" to moze i bedzie dobry jesli ma 
> talent, ale ktos z takimi samymi zdolnosciami zaczynajacy z dolu, bedzie 
> o niebo lepszy.

Obecnie gdy chce się kupić samochód to ABS, Airbag, Radio są
w standardzie. Jakbym miał kupić inny samochód kosztujący tyle
samo, który pali 2x więcej i do tego nie ma ogrzewania nie mówiąc
już o powyższych "gadgetach" to czym bym taki zakup podyktował?
Czy po zakupie samochodu wyjadę z salonu i będę próbował czy
wskazówka prędkościomierza dojdzie do ostatniej liczby?
Chyba nie.

Dlaczego stawiać "żótodzioba" twarzą w twarz z językiem C?
Dlatego, że go nie powinno być "stać" na używanie nowszego języka?
Czy może, w obawie przed tym, że jego nauczyciel nie potrafi
się go nauczyć?

> Bez podstaw, kazda piekna budowla predzej czy pozniej sie zawali ;-)

Na szczęście nowoczesne języki oparte są na solidnych filarach,
odziedziczonych po sprawdzonych językach, także strukturalnych.
Nie ma więc obaw, że nie wytrzymają najbliższych lat.

pozdrawiam
Marcin