On Wed, 02 Feb 2011 23:07:55 +0100, Wojciech Jaczewski
<w...@o...pl> wrote:

>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.
>

H,m... Hierarchia obiektow to sczegol implementacyjny? Moze tak by
bylo warto pzrestudiowac sparwy obiektowe jeszcze raz i przemyslec
jaka jezt rola obiektowosci w modelowaniu?... I przemyslec "co ma
obiektowosc do ejzyka programwoania"?...

>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.

Calkiem neidawno w Communications of the ACM byl artykul na temat
"szkodlowosci obiektowosci" - tak z grubsza. Zobacze czy jest
publiczna wersja...

A.L.