Grzegorz Krukowski wrote:

> To co zarzuca C A.L. to, moim zdaniem, domyślne pozwolenie na
> niskopoziomowe manewry i/lub upowszechnienie się takiego języka jako
> języka ogólnego zastosowania. Zachęca to do zajmowania się
> niskopoziomowymi szczegółami już na początku, zamiast na końcu, kiedy
> to jest potrzebne. W efekcie istnieje presja na powszechne stosowanie
> średnio bezpiecznych sztuczek, zamiast promowania, nazwijmy to,
> ładnego kodu. Pod tym względem C jest regresem, gdyż dotychczas
> większość języków wraz z czasem przechodzi do coraz bardziej
> wysokopoziomowych/abstrakcyjnych konceptów, tylko języki rodziny C i
> pochodnej idą trochę wbrew tym trendom.

Tak na prawdę, planując koncept na prawdę wysokopoziomowy, nie trzeba się
interesować językiem ani odrobinę. Często będąc zauroczonym programowaniem
obiektowym (przechodziłem ten etap - na szczęście szybko mi minął - w ciągu
jakichś 2-3 lat) pod pozorem projektowania wysokopoziomowego, projektowałem
tak na prawdę niskopoziomowo, bo zamiast zajmować się działaniem
programu/systemu jako całości (i tym, jak będzie on używany przez klientów),
zajmowałem się hierarchią obiektów, czyli szczegółem implementacyjnym, jakim
jest niewidoczna dla użytkownika struktura kodu źródłowego.

Nie ma nic złego w korzystaniu z abstrakcji, jakie dają języki wyższego niż
C poziomu. Ale zastanowienie się przez jakiś czas, jak mogłaby dana
funkcjonalność zostać zrealizowana w czystym C, albo nawet - w C na
mikrokontrolerze, powoduje że nieraz dochodzi się do rozwiązania nie tylko
znacząco wydajniejszego, ale też prostszego. Okazuje się, że ileś tam
przejściowych buforów, które tworzyło się w wysokopoziomowym projekcie, jest
całkowicie zbędnych. A program, który wykonuje rzeczy zbędne, zwykle nie
jest łatwy do zrozumienia dla programisty nie-autora, oglądającego ten kod.