"Zawsze da się wczytać kod binarny"
???
Jeśli mikrokontroler ma ustawione bity blokady odczytu?
Jak?


Nie używałem C. Jesli w urządzenie sterowanym mikrokontroler używa całego zasobu sprzętowego przetworników AC, EEpromu,  wszyskich rodzajow przerwnań a nawet wielokrotnego użycia poszczególnych przerwać z wysokim rezimem synchronizacji poszczególnych funkcji to mieszanie C i assemblera moim zdaniem nie miałoby sensu.
Natomiast używanie gotowych macr i podprogramow czyni program względnie przejrzystym.

Zawsze da się wczytać kod binarny i wykorzystać disasembler, aby kod odczytać - nie jest to wielki problem (disassemblerów pod mikrokontrolery Atmel i inne jest pod dostatkiem ).

Co do "dlaczego assembler" to ja tam wolę C + wstawki ASM - ten sam poziom dostępu do hadware tam gdzie tego chcę, lepsza czytelność i przyjemniejsze pisanie i lepsze automatyczne optymalizatory kodu C niż jest wstanie zrobić to człowiek to ręcznie nawet z dużym doświadczeniem (C tam gdzie nie potrzeba specyficznych możliwości sprzętu, a wstawki ASM tam gdzie trzeba ręcznie wykorzystać możliwości danego kontrolera/procesora). Lata temu jeszcze czysty ASM miał rację bytu (kompilatory C kiepsko optymalizowały i dało się więcej ręcznie zrobić), ale przy obecnych kompilatorach nie ma najmniejszego sensu.

Cóż ja mogę rzec ze swoimi assemblerami na moje komputery jednoukładowe?  One mają jedną doskonałą właściwość, kod binarny programu wklepany w mikrokontroler jest niedostępny dla ewentualnego nieuprawnionego amatora owoców cudzej pracy...Wspomniane sztuczki z gmatwaniem programu są tu więc zupełnie  zbędne. Czy da się tworzyć assemblery, które byłyby przejrzyste? Moim zdaniem tak, pod warunkiem, że opanuje się przez długą praktykę jego właściwości, funkcje, niuanse, nie szczędzi się komentarzy, zgromadzi własną bibliotekę "gotowców" do wykorzystania. Dlaczego assembler? Ponieważ pozwala na bezpośredni dostęp do hardware'u (właściwości sprzętowych, układu) i pozwala maksymalnie zoptymalizować i wyzyskać jego właściwości

Z programowaniem, rzeczywiście, miałem do czynienia tylko na poziomie szkolnego kółka zainteresowań. Informatyka bardziej mnie interesuje w kontekście przemian kulturowych i mentalnych, które za sobą pociąga. Natomiast problem rosnącego zawikłania systemów, od których jesteśmy coraz bardziej uzależnieni (najlepiej to widać na przykładzie prawa, zwłaszcza w obszarze ekonomii) pozwala potraktować rzecz w ogólniejszym kontekście.

Nawiązuję tu do znanego motywu jednostki osaczonej przez mechanizmy, które prędzej czy później ujawniają sprzeczności zachodzące między jednostką a organizacją. Może to trochę anarchizujące, ale i ten anarchizm też taki z przymrużeniem oka raczej :)

Czy dobrze zgaduję, że nie miał Pan nigdy do czynienia z programowaniem i pisze pan bardziej ze słyszenia?
Mocno przejaskrawione i wyolbrzymione teksty.

Jeśli to kod kompilowalny to żadnych komentarzy cracker (nie hacker) nie zobaczy i tak żadnych komentarzy (nie ma takiej opcji) nie zobaczy nawet czytelnego kodu z nazwami funkcji (chyba, że programista był kiepski i kompilację debug udostępnił publicznie). Nie ma racjonalnego powodu w pisaniu kodu niezrozumiałego - nawet jeśli to są skrypty (kod widoczny dla klienta) lub z maszyną wirtualną (Java) to nikt sobie pracy utrudniać nie będzie i rozwija przejrzysty kod (trochę przez to nadmiarowy, ale to nie ma znaczenia dla wydajności), a po prostu przed wydaniem przepuszcza się przez automatyczny obfuscator i odszyfrowanie nawet mając kod jest nieporównywalnie trudniejsze niż odczytanie się z kodu o niskiej jakości (ofc jakość to stosunek wypowiadanego WTF na min).

Korporację już dobrze znają zagrożee i Code Review
są częste i o jakość kodu się dba. Odrobiono lekcję po wymarłym języku Cobol (do dziś używanego w bankach itp ;p).
dilbert.com/strips/comic/1997-11-05/
dilbert.com/strips/comic/1997-11-04/