It’s now nearly a year that I started writing non-trivial amounts of C codeagain (the first sokol_gfx.h commit was on the 14-Jul-2017), so I guess it’stime f...
Nie do końca zgadzam się z argumentem, że wskaźniki są rozdmuchanym problemem.
Autor wpisu skupił się na problemie przynależności (ownership) wskaźników, którego faktycznie można uniknąć odpowiednim designem API.
Nie wspomniał za to o kwestii sprawdzania zakresów tablic, który obecnie rozwiązuje się lekkimi abstrakcjami (slice, span, itp.) i automatyczną iteracją (range for).
Przemilczał też, że (ze względu na brak generyczności) uniwersalnym typem wskaźnika w C jest void* (ewentualnie char*). W związku z czym powiększa się liczba miejsc, gdzie programista rzutuje swoje struktury na taki bazowy wskaźnik a później ręcznie odtwarza zagubione w ten sposób informacje o typie.
Ja rozumiem, że takie proste języki jak C mają swój urok, bo ich minimalizm redukuje programiście wybór dostępnych rozwiązań problemu.
Tylko wydaje mi się, że w 2024 mamy już kilka nowoczesnych języków, które są znacznie bezpieczniejsze i tak samo minimalistyczne jak C.
Traktuje to w kategorii programowania rekreacyjnego. Przy okazji można się dowiedzieć co i gdzie śmierdzi w bibliotekach.
Dziękuję, że wspomniałeś o tych abstrakcjach. To był odpowiedni czas. Wyobraziłem sobie dlaczego są lekkie.
Uważam, że jeśli ktoś sobie koduje w C i przez większość czasu kompilator nie pisze mu warningów, errorów, a program nie kończy się segfaultem, to może sobie kodować dla przyjemności. Bo raczej wie co robi. Miło się programuje w tym co się zna. Przy okazji mogą powstać fajne rzeczy.
Fajnie, że są nowe języki. Są też o nich podobne, zabawne opracowania u tsoding i jdh. Nie umiem tego oglądać, ale są to inspirujące rzeczy nawet po samym tytule.
Nie do końca zgadzam się z argumentem, że wskaźniki są rozdmuchanym problemem.
Autor wpisu skupił się na problemie przynależności (ownership) wskaźników, którego faktycznie można uniknąć odpowiednim designem API.
Nie wspomniał za to o kwestii sprawdzania zakresów tablic, który obecnie rozwiązuje się lekkimi abstrakcjami (slice, span, itp.) i automatyczną iteracją (range for).
Przemilczał też, że (ze względu na brak generyczności) uniwersalnym typem wskaźnika w C jest void* (ewentualnie char*). W związku z czym powiększa się liczba miejsc, gdzie programista rzutuje swoje struktury na taki bazowy wskaźnik a później ręcznie odtwarza zagubione w ten sposób informacje o typie.
Ja rozumiem, że takie proste języki jak C mają swój urok, bo ich minimalizm redukuje programiście wybór dostępnych rozwiązań problemu.
Tylko wydaje mi się, że w 2024 mamy już kilka nowoczesnych języków, które są znacznie bezpieczniejsze i tak samo minimalistyczne jak C.
Ostatnio jest wysyp tego typu wpisów.
np.: https://danielchasehooper.com/posts/shapeup/
Traktuje to w kategorii programowania rekreacyjnego. Przy okazji można się dowiedzieć co i gdzie śmierdzi w bibliotekach.
Dziękuję, że wspomniałeś o tych abstrakcjach. To był odpowiedni czas. Wyobraziłem sobie dlaczego są lekkie.
Uważam, że jeśli ktoś sobie koduje w C i przez większość czasu kompilator nie pisze mu warningów, errorów, a program nie kończy się segfaultem, to może sobie kodować dla przyjemności. Bo raczej wie co robi. Miło się programuje w tym co się zna. Przy okazji mogą powstać fajne rzeczy.
Fajnie, że są nowe języki. Są też o nich podobne, zabawne opracowania u tsoding i jdh. Nie umiem tego oglądać, ale są to inspirujące rzeczy nawet po samym tytule.