Czytałem ten artykuł jakiś czas temu. Pisany chyba z perspektywy osoby, która robi tylko obliczenia numeryczne w asemblerze.
Na dodatek autor sam sobie zaprzecza w kilku miejscach i ignoruje to, że większość projektów robi się dla pieniędzy a nie zabawy.
[…] writing good code with bad programmers is a problem of the XX century
Widziałem sporo kodu napisanego w XXI wieku i nie wydaje mi się.
I do think that writing in C++ is a bad habit. It is unsafe, not as effective as it is thought of, and it wastes a terrible amount of a programmer’s mental capacity on things that have nothing to do with making software.
Z tym mógłbym się zgodzić, ale trudno mi brać na poważnie ten argument, widząc kawałek dalej następujące stwierdzenie:
Assembly programming is also held back by a myth that writing in assembly is hard and therefore impractical.
Od kiedy to jest mitem? Może niech zaprezentuje jakieś statystyki, które to potwierdzą. Bo ja pamiętam jak niestabilny był Windows 95.
No chyba że Microsoft miał złych programistów, bo wiek był XX. Teraz jest na pewno lepiej.
Asembler też już nie obciąża mentalnie jak C++. Przecież od roku 2001 każdy rodzi się z alokatorem rejestrów w głowie.
We know that all the most common architectural families: x64, ARM, and RISC-V have different instruction sets. But no one knows a good reason to keep it this way.
Powiedziałbym, że jedną z przyczyn technicznych jest różna efektywność energetyczna i skalowalność pod kątem mniejszych lub większych rozwiązań.
Choć tak naprawdę chodzi o pieniądze z licencji.
This forward compatibility layer would heal the worse neurosis of every assembly programmer out there: “what if I write the one-in-a-lifetime code for this particular architecture, and this particular architecture will make itself obsolete in a year?”
Jeśli jakaś firma ma takie potrzeby i pieniądze na nową architekturę, to chyba zapłaci specjalistom za przepisanie kodu.
Reasumując, mogę się zgodzić, że C++ traci od kilku lat na znaczeniu.
Ale na pewno nie zabije go żadna z technologii opisanych w artykule.
Ja odebrałem kolesia jako miłośnika C++. Artykuł był fajnym przeglądem narzędzi o których nie wiedziałem. Dla atrakcyjności zawierał różne kontrowersyjne tezy zmęczonego/doświadczonego pracą człowieka.
Widziałem sporo kodu napisanego w XXI wieku i nie wydaje mi się.
Ale nawet ty pisałeś o jakiś specjalnych technikach pozwalających na pisanie lepszego kodu. To dość szerokie pojęcie. Wiele technik przeznaczonych jest dla różnych osób. Wiele było błędnych. Wiele jest prawdziwych. Tych ostatnich szacuję, że jest najmniej i są tak samo wymagające, jak skupianie się na dobrej jakości programowaniu.
Od kiedy to jest mitem?
Od kiedy 8bitguy napisał swoją grę Planet X3 całkowicie w asm x86 w notatniku Windows. Bo nie wiedział, że się nie da.
Powiedziałbym, że jedną z przyczyn technicznych
Ja bym powiedział, że przyczyną są lata 1970/1980. Gdzie opłacało się to robić. Bo liczyła się optymalizacja w krzemie dla całego produktu. A potem to już kwestia ilości oprogramowania i doświadczenia. Kompilator nie rozwiązuje przenośności automatycznie.
RV powstało chyba głównie z powodów licencyjnych. Tak jak ruch wolnego oprogramowania.
Czytałem, że do dzisiaj jeśli chodzi o efektywność energetyczną, bardziej opłaca się użyć MCS51.
Przecież od roku 2001 każdy rodzi się z alokatorem rejestrów w głowie.
To raczej kwestia doświadczenia. Doświadczeni używają papieru zamiast głowy.
Czytałem ten artykuł jakiś czas temu. Pisany chyba z perspektywy osoby, która robi tylko obliczenia numeryczne w asemblerze.
Na dodatek autor sam sobie zaprzecza w kilku miejscach i ignoruje to, że większość projektów robi się dla pieniędzy a nie zabawy.
Widziałem sporo kodu napisanego w XXI wieku i nie wydaje mi się.
Z tym mógłbym się zgodzić, ale trudno mi brać na poważnie ten argument, widząc kawałek dalej następujące stwierdzenie:
Od kiedy to jest mitem? Może niech zaprezentuje jakieś statystyki, które to potwierdzą. Bo ja pamiętam jak niestabilny był Windows 95.
No chyba że Microsoft miał złych programistów, bo wiek był XX. Teraz jest na pewno lepiej.
Asembler też już nie obciąża mentalnie jak C++. Przecież od roku 2001 każdy rodzi się z alokatorem rejestrów w głowie.
Powiedziałbym, że jedną z przyczyn technicznych jest różna efektywność energetyczna i skalowalność pod kątem mniejszych lub większych rozwiązań.
Choć tak naprawdę chodzi o pieniądze z licencji.
Jeśli jakaś firma ma takie potrzeby i pieniądze na nową architekturę, to chyba zapłaci specjalistom za przepisanie kodu.
Reasumując, mogę się zgodzić, że C++ traci od kilku lat na znaczeniu.
Ale na pewno nie zabije go żadna z technologii opisanych w artykule.
Ja odebrałem kolesia jako miłośnika C++. Artykuł był fajnym przeglądem narzędzi o których nie wiedziałem. Dla atrakcyjności zawierał różne kontrowersyjne tezy zmęczonego/doświadczonego pracą człowieka.
Ale nawet ty pisałeś o jakiś specjalnych technikach pozwalających na pisanie lepszego kodu. To dość szerokie pojęcie. Wiele technik przeznaczonych jest dla różnych osób. Wiele było błędnych. Wiele jest prawdziwych. Tych ostatnich szacuję, że jest najmniej i są tak samo wymagające, jak skupianie się na dobrej jakości programowaniu.
Od kiedy 8bitguy napisał swoją grę Planet X3 całkowicie w asm x86 w notatniku Windows. Bo nie wiedział, że się nie da.
Ja bym powiedział, że przyczyną są lata 1970/1980. Gdzie opłacało się to robić. Bo liczyła się optymalizacja w krzemie dla całego produktu. A potem to już kwestia ilości oprogramowania i doświadczenia. Kompilator nie rozwiązuje przenośności automatycznie.
RV powstało chyba głównie z powodów licencyjnych. Tak jak ruch wolnego oprogramowania.
Czytałem, że do dzisiaj jeśli chodzi o efektywność energetyczną, bardziej opłaca się użyć MCS51.
To raczej kwestia doświadczenia. Doświadczeni używają papieru zamiast głowy.