Dlaczego ludzie nie lubią low-levelu?

Tak sie zastanawiam. Dlaczego własciwie sporo ludzi nie lubi programowania niskopoziomowego/babrania sie z asmem?
Moje założenie opieram na obserwacjach gdzie tematów o asm czy innych dowolnych-lowlevelowych-sprawach, widze stosunkowo niewiele.
Jak możecie to napiszcie czy lubicie/nie lubicie programowania low-level. Pamiętam że kurcze gdzieś ktoś kiedyś wstawił fajny post dlaczego low-levelu dziś sie nie lubi, ale nie pamiętam kto, i gdzie.

Większw ryzyko walenia bubli, więcej rzeczy na głowie, większy koszt projektów.

Czyli martw się o wszystko i rób to powoli

Nie przepadam. Miałem do czynienia tylko na studiach.

Wygodniej jest pisać na wyższym poziomie, gdy framework, język(wygodna składnia), kompilator, maszyna wirtualna (i wszystko inne co po drodze) rozwiązują wiele problemów za Ciebie :)
Dzięki temu jest łatwiej. Na niższym poziomie jest trudniej. Za to pewnych rzeczy na wysokości się rozwiązać nie da.

Za parę lat pewnie się wezmę za jakiś nisko poziomowy język dla podciągnięcia skilla (na razie mam co podciągać na "wysokim poziomie" i dopóki nie muszę na "niskim" to wole "wysoki").

Bo czas.
Bo wygoda.
Bo optymalizacje.
Bo biblioteka standardowa.
(...)

Lubię. I co z tego, skoro relatywnie mało roboty w tym jest? ;)

Ja do asma mam sentyment bo od niego zaczynałem i byłem wręcz fanatycznym asemblerowcem :P

Na niskim poziomie po prostu wolniej widać efekty.
Niski poziom zajmuje się też zwykle innymi problemami (np. jak przesłać bufor z A do B tak aby było jak najszybciej) niż poziom wysoki (np. trzeba wyświetlić Kowalskiemu historię rachunku w ładnej tabelce). Te problemy wysokopoziomowe zwykle są dużo bliżej klienta końcowego i łatwiej komuś wytłumaczyć co robimy. Dlatego niski poziom ma otoczkę magii i tajemniczości.

Osobiście wcale nie uważam, aby programowanie niskopoziomowe było trudniejsze niż wysokopoziomowe. Jest po prostu... trochę inne.

I jeszcze do poczytania w temacie: http://yosefk.com/blog/low-level-is-easy.html

Ja ostatnio przerzuciłem się trochę w stronę low/mid-level (Rust) z trochę wyższego (Ruby & OTP). Pisze się fajnie, porwałem się z motyką na słońce, więc jest zabawnie (http://lukasz.niemier.pl/octavo), narzędzia zajebiste, społeczność jeszcze lepsza. Low level is fun! :P

Udalo sie komus zalapac na jakis staz/praktyki i klepac glownie w asm/c? Wiekszosc firm jak juz cos oferuje to glownie web dev, c#, java. Z tych niskopoziomowych, to raczej nikt sie nie chce bawic z swiezakami i przyuczac, z reguly w ogloszeniu sa podane te +3 lata doswiadczenia.

Asembler nie jest zły. Jednak prawda jest taka, że narzędzie dobiera się do zadania, a nie na odwrót.
Asembler w większości zadań jest zbyt nieporęczny, to jak myć łazienkę szczoteczką do zębów, efekt będzie super, ale trzeba się napracować o wiele więcej niż gdy się zastosuje odpowiedni zestaw narzędzi.
Większość współczesnych aplikacji ma tak wysoki poziom skomplikowania, że nikomu nie starczyłoby życia na wykonanie tej samej pracy (szybciej braknie pieniędzy niż "życia").

Gdybym pisał sterownik to mieszałbym C i asemblera, szybkie obliczania w wąskiej pętli (np operacje macierzowe) też bym optymalizował asemblerem jeśli byłoby to konieczne.
Na szczęście przypadków, kiedy warto stosować asemblera jest mało i na dodatek przypadki te występują bardzo rzadko.
Z tego powodu ofert pracy dla ludzi z takimi umiejętnościami jest na prawdę bardzo mało, a jak już są, to są połączone z innymi niezwykłymi umiejętnościami: elektronika, znajomość jądra systemu, itp.

Do tego dochodzą problemy przywiązania do konkretnej architektury. Optymalizujemy kod pod Intela czy pod AMD, co z innymi procesorami: ARM (który króluje na komórkach), MIPS. Po co przepisywać ta samą aplikację skoro ten sam kod napisany w C będzie działał dostatecznie dobrze na każdej architekturze.

Ludzie nie lubia low-levelu? Powiedz to tworcom MenuetOSa albo KolibriOSa. Jestem bylym polskim crackerem i wrecz uwielbialem asma. Stosujac go czulem sie elitarny (fakt, ze wtedy mlody bylem), a na programistow stosujacych inne jezyki programowania patrzylem z gory i okreslalem mianem lamerow :). Ostatnio jak pisalem maly programik pod windows to napisalem go sobie w win32asm. Mysle, ze "mlodzi" programisci nie lubia low-levelu bo go nie znaja i po prostu nie musza znac. Szkoda tylko, ze nie wiedza dokladnie jak dziala komputer i co znacza te literki EAX, EBX, ECX, EDX, ESI, EDI, EIP itp kiedy jakis program sie wysypie :)

@evilshibe: inżynierowie Intela oraz AMD spoglądają na Ciebie z pogardą patrząc jak kodujesz w tym wysoko-poziomowym, w porównaniu do mikrokodu, assemblerze. Programiści kart perforowanych również nie są z Ciebie zadowoleni.
(...)
Nadążasz?

a na programistow stosujacych inne jezyki programowania patrzylem z gory i okreslalem mianem lamerow

Ale to oni pisali programy w trzy dni, a nie trzy miesiące :P

Ostatnio jak pisalem maly programik pod windows to napisalem go sobie w win32asm.

Spoko, a teraz napisz choćby taką pipirdółkę jak program dla pani recepcjonistki w bibliotece i zobacz, ile Ci to zejdzie w asm, a ile np. w Javie/C#/cokolwiek i wysuń wniosek, dlaczego programiści asm są pożądani tylko w bardzo ograniczonych dziedzinach (stąd już prosta droga do zasady popytu i podaży).

Szkoda tylko, ze nie wiedza dokladnie jak dziala komputer i co znacza te literki EAX, EBX, ECX, EDX, ESI, EDI, EIP itp kiedy jakis program sie wysypie :)

Generalizacja milion.
Używanie debuggera wymaga siłą rzeczy zapoznania się z tym tematem, a ten z kolei jest niezbędny w pewnych sytuacjach. Co nie oznacza, że muszą umieć pisać programy w assemblerze.
Znam osoby, które potrafią np. rozumieć niemiecki ze słuchu, lecz własnego zdania już nie złożą - to jest identyczna sytuacja.

evilshibe napisał(a):

[...]Mysle, ze "mlodzi" programisci nie lubia low-levelu bo go nie znaja i po prostu nie musza znac.[...]

Umiesz ty czytac ze zrozumieniem?

Programowanie okienek w WinAPI w assemblerze albo robienie cracków nie czyni nikogo automatycznie dobrym programistą niskopoziomowym, tak jak umiejętność mycia łazienki szczoteczką do zębów nie czyni z nikogo profesjonalisty od sprzątania.

Po prostu trzeba dobrze dobrac narzedzie do problemu: mozna kopac w ziemi lopata, koparka lub jak archelodzy oczyszczac cos pedzelkiem i kazde z narzedzi bedzie najlepsze do konkretnego zastosowania. Uzycie koparki do zasadzenia krzaka porzeczki bedzie przesada, z kolei wykopanie dziury pod fundament lopata czy pedzelkiem tez nie bedzie efektywne.

Pytanie powinno brzmieć: "dlaczego tyle firm woli wysokopoziomowe języki, zamiast niskopoziomowych?".

Ja osobiście lubię czasami zejść niżej, na poziom rejestrów (zaczynałem od Basic'a na Atari, razem z nieśmiertelnymi PEEK i POKE. Ale pracodawca raczej nie zapłaci mi za zabawę we wskaźniki lub rejestry, tylko za przygotowaną funkcjonalność.
Dlatego firmy nie wymagają znajomości programowania niskopoziomowego. Tak samo jak od budowlańców nie wymaga się, żeby za każdym razem projektowali domy od zera, wymyślali skład cementu i tworzyli narzędzia do szpachlowania.

Niektóre firmy bardzo cenią sobie programistów rozumiejących programowanie niskopoziomowe, nawet jeśli programują wysokopoziomowo i do asma czy C się nie dotkną nigdzie w projekcie. Po prostu choćby świadomość ile co kosztuje jest niezbędna do pisania szybkiego wysokopoziomowego kodu. Niestety wielu programistów wysokopoziomowych słabo orientuje się w tym, jak jest zrobiony sprzęt i jak to wszystko działa pod spodem.

W efekcie później pojawiają się pytania na Stack Overflow typu "puściłem mój program na 8 wątkach - dlaczego zamiast przyspieszyć, spowolnił?" albo "dlaczego liniowe wyszukanie czegoś tablicy składającej się z kilkunastu elementów jest szybsze niż wyszukanie w HashMapie; przecież na zajęciach było że O(1) jest lepsze niż O(n)?" :D

Dobry programista musi znać assembler, inaczej programowanie to mniejsza lub większa magia.
Za to pisanie w assemblerze nie ma sensu, nawet na mikrokontrolerach.

Brzmi to troche jak ewolucja wstecz, to tak jakbyśmy mieli z samochodów odremontowywać koła
Po to powstały języki wyższego poziomu by było łatwiej i klarownie, w asmie kod jest jakieś 10 razy dłuższy niż C więc po co się przemęczać i odwalać robote głupiego, poza tym zawsze można się pomylić w tej abstrakcji instrukcji procesora jeśli się w tym długo nie siedzi.
ASM dobry do DLL injectów PE injectów rootkiów, hooków, sterowników takich tam rzeczy związanych z inżynierią wsteczną , jakieś tam patchy do gier, cracki , ale nie widzę pożytecznej koncepcji strugania w Nasm-ie rozbudowanego programu okienkowego.

Inna sprawa jest wtedy gdy ktoś zajmuje się programowaniem sprzętu elektronicznego, np właśnie jak kolega powiedział jakieś mikrokontrolery AVR, jakiś zestaw arduino no to wypadałoby znać, moim zdaniem ogólnie jak ktoś zna ASMa to jest prawdziwym programistą ale z drugiej strony pisanie w ASMie każdego programu niezależnie od przeznaczenia mija się z celem.
Zreszta różnice między AMD i INTELEM które też trzeba znać sprawiają że programy w ASMie nie wykonają się na procesorach o przeciwstawnej architekturze po co to komu tak się męczyć?
Ja ASM-a używam w formie wstawek do Cpp , po co mam miałbym cały kod pisać w tym języku , musiałbym się bardzo nudzić.

Moim zdaniem nauka Assemblera powinna być standardem dla każdego programisty chociażby po to by umiał dobrze interpretować debugger, przede wszystkim znać chociaż jakieś podstawy mieć wiedze o break-pointach z wyuczonym ASMem to łatwiej wchodzi w głowę ale pisani w nim całych programów jest totalnie bezsensu

Dobry programista musi znać assembler

Dobry programista musi rozumieć przede wszystkim jak działa sprzęt.
Znajomość assemblera nie jest równoważna ze znajomością sprzętu, tak jak umiejętność wymiany oleju w samochodzie nie jest równoważna ze znajomością procesów zachodzących w silniku.

Problem z asemblerem jest taki, że, patrząc z perspektywy sprzętu, asembler sam w sobie jest już miejscami bardzo wysokopoziomowy. Np. mogę zapisać w Javie:

  volatile int x;
  ... 
  x = 5;

Albo w assemblerze:

  mov 5, %eax
  mov %eax, memlocation(....)
  sfence

I naprawdę nie ma dużej różnicy. Jedno i drugie można stosować na zasadzie "magii", nie rozumiejąc co jest pod spodem i jaki będzie koszt. Natomiast żeby opisać co robi ten kod od strony sprzętowej, zabrakłoby miejsca na kartce A4.

Dobry programista musi rozumieć przede wszystkim jak działa sprzęt.

Ja bym powiedział, że programista nie zrozumie jak działa sprzęt nie znając assemblera (przynajmniej w przybliżeniu). Więc znajomość assemblera jest warunkiem koniecznym ale nie wystarczającym do bycia dobrym programistą.

robienie cracków nie czyni nikogo automatycznie dobrym programistą niskopoziomowym

Jak ktoś jest dobrym Reversem Engineerem to niekoniecznie będzie dobrym programistą i vice versa. To po prostu dwie różne umiejętności.

@0x200x20 nie zgodzę się. Można rozumieć jak działa sprzęt bez znania assemblera (w sensie składni). Tak samo jak można rozumieć jak działa AES bez znania jego implementacji. Po prostu inny poziom abstrakcji, bardziej opisowy, ale dalej technicznie poprawny.

winerfresh napisał(a):

@0x200x20 nie zgodzę się. Można rozumieć jak działa sprzęt bez znania assemblera (w sensie składni). Tak samo jak można rozumieć jak działa AES bez znania jego implementacji. Po prostu inny poziom abstrakcji, bardziej opisowy, ale dalej technicznie poprawny.

Opis zasady działania komputera można przedstawić również tak:

• Jest sobie monitor który sobie fajnie daje obraz i taka skrzynka z guzikiem

Ale z takim podejściem opisowym pseudo-technicznym jesteśmy daleko daleko od rozumienia tego co daje ASM czyli instrukcji w formie kroków.
Każda instrukcja do procesora jest pojedynczym "słowem" które do niego mówimy i nie znanie tych słów to tak naprawdę brak kompentecji z perspektywy programisty i nie umiejętność rozmowy z nim, to nie rozumienie architektury sprzętu komputerowego.

A co do tego czy ASM jest najprostszy?
Nie sądzę by osoba która nie dotknęła języka wyższego poziomu nauczyła się ASMa szybciej niż tego wysokopoziomowego, zbyt duża abstrakcja, na pewno łatwiej z wysokiego przejść do niskiego, niż zaczynać od low-levela

Jak nie znasz najważniejszych intrukcji assemblerowych dla danego procesora to o jakim rozmumieniu sprzętu ty mówisz. Chyba bardzo płytkim.

Pewnie tak, tylko ile tych najważniejszych instrukcji asemblerowych jest? Kilkanaście?

Nie muszę się uczyć wszystkich wariantów instrukcji mov, aby móc zrozumieć, jak są realizowane odczyty i zapisy z pamięci na poziomie sprzętowym. Wystarczy, że założę, że istnieje jakaś instrukcja do przesłania danych z pamięci do rejestru i w drugą stronę (na niektórych CPU będzie się nazywać tak samo - np. mov, a na niektórych mogą być do tego zupełnie różne np. ld, sd na MIPS - ale to są szczegóły mające małe znaczenie). Dogłębne zrozumienie tego na poziomie sprzętowym da mi zapewne znacznie większe możliwości pisania szybkich programów niż nauczenie się wszystkich pozostałych popularnych instrukcji, wraz ze wszystkimi wariantami mov i skoków warunkowych.

Czasami drobne subtelności w assemblerze potrafią mieć znaczenie. Jako przykład podam instrukcję xchg.
xchg reg, reg - zwykła instrukcja która swapuje wartość rejestrów
xchg reg, mem - generuje barierę pamięci, która wali bo wydajności. I nie ma tu żadnego prefixa lock, żeby się tego można była domyślić bez uprzedniej wiedzy.
Podałem realny przypadek - JIT do rubyego generował taki kod. Nie wiesz - nie będziesz w stanie zdebugować spadku wydajności.

A mnie przeglądając ostatnio oferty pracy tak natchnęło: jak w PL przyglądnąć się ogłoszeniom związanym z low-levelem (szeroko pojętym: C/C++/programowaniem systemowym unixów/embedded bare-metal) to jakby roboty mało raczej. Wklepałem to samo w szukajki niemieckie, angielskie, skandynawskie czy holenderskie i nagle zrobiło się tych ofert sporo (ciągle mniej niż w javie itd., ale w stosunku do Polski i tak dużo). Zresztą przecież regularnie do Szwecji zapylać będę, żeby gdb się bawić... ;) To jak to jest? Moja wypowiedź oczywiście bazuje wyłącznoe na osobistych przemyśleniach i doświadczeniach, niczym więcej, ale ciekaw jestem jak inni to postrzegają...

Krolik napisał(a):

Dobry programista musi rozumieć przede wszystkim jak działa sprzęt.
Znajomość assemblera nie jest równoważna ze znajomością sprzętu, tak jak umiejętność wymiany oleju w samochodzie nie jest równoważna ze znajomością procesów zachodzących w silniku.

Nie, assembler to najniższa abstrakcja. Tu nie ma nic więcej do rozumienia, sprzęt nie istnieje.
Kod teoretycznie może być nawet wykonywany przez miliony dzieci z liczydłami.

Bezpośredniego przełożenia na sprzęt nie ma już od dawna, szczególnie na x86 z jego 39 letnią historią. Kiedyś w ogóle nie było czegoś takiego jak dekoder instrukcji, instrukcje były zapisane bezpośrednio w układzie tranzystorów; teraz każdy cpu x86/amd64 ma skomplikowany dekoder który kompiluje kod w assemblerze do rzeczywistych instrukcji danego procesora. Działanie 386 na poziomie sprzętowym nie ma żadnego związku z działaniem skylake - stała jest tylko abstrakcja, doszło tylko trochę rozszerzeń. Jak za 15 lat wejdą procesory oparte np. na memrystorach rewolucja będzie totalna - abstrakcja zostanie ta sama.

Można sobie optymalizować pod konkretną architekturę, ale na tym kończy się użyteczność wiedzy sprzętowej.

Disclaimer: Nie czytałem wszystkich postów w dyskusji.

Dlaczego ludzie nie lubią low-levelu?

Bo ma mniejszy "cool factor" dla początkujących. Jako newbie wolisz (zazwyczaj) pochwalić się znajomym taką stroną http://damian.drygiel.com/ niż rzeczami o których większość ludzi nie ma pojęcia jak działa, albo nawet że istnieją. Dlaczego tyle newbie chce pisać gry? Bo pisanie gier ma wysoki "cool factor" wśród znajomych (wiem że gry to nie high-level, nie trzeba mnie uświadamiać). Mniej jest ludzi, którzy już od początku lubią wnikać "jak to działa" głebiej i głębiej.