Niski poziom jest prosty

0

Niedawno przeczytałem ciekawy artykuł:
http://www.yosefk.com/blog/low-level-is-easy.html
Dosyć długi ale warto przeczytać. Generalnie zgadzam się z gościem, że niski poziom jest prostszy (tj. prostszy koncepcyjnie i mniej upierdliwy). Zastanawia mnie tylko skąd wzięła się powszechna opinia, że jest odwrotnie: że to niski poziom jest trudniejszy?
Zapraszam do dyskusji.

0

Trudne może być przejście z wysokiego poziomu na niski, bo trzeba jednak zmienić sposób myślenia. Nie jest prawdą, że niski poziom to łatwizna i każdy programista javy czy .net bez problemu nagle może przejść na programowanie niskopoziomowe, bo to łatwizna. Ogólnie to całkiem 2 różne rzeczy, ciężko powiedzieć co jest trudniejsze.

A czemu jest uwazany za trudniejszy? Pewnie dlatego że mało jest programistów "niskiego poziomu", a dla reszty to jakaś czarna magia. Tak samo jak reverse-engineering.

0

Ja się z tym nie zgadzam. Znacznie łatwiej jest napisać coś obiektowo. Napisałem wiele programów obiektowo, których albo nie potrafił bym przetłumaczyć na niski poziom, albo zajęło by mi to 5 razy więcej czasu..
Chyba samo założenie zakłada, że wyższy pozio
m jest przyjemniejszy dla człowieka..

0

Ogólnie nauczenie się składni języków niskiego poziomu nie jest trudne, trudne jest dopiero zastosowanie wiedzy w praktyce, bo np. wywołanie funkcji w asemblerze jest trochę bardziej skomplikowane, tak samo jak, np. tworzenie zmiennych lokalnych.
Osobiście uważam, że dużo łatwiej jest przenieść się z C na Asma niż na odwrót bo potem niestety ale programista Asm piszący w C tworzy straszne spaghetti ze względu na przyzwyczajenia, a nie na brak wiedzy.

0

Trudne może być przejście z wysokiego poziomu na niski, bo trzeba jednak zmienić sposób myślenia.

I vice versa. Szczególnie trudne dla niskopodłogowców gdy ma się podejście, że obiektowość to niepotrzebny bajer.

Nie jest prawdą, że niski poziom to łatwizna i każdy programista javy czy .net bez problemu nagle może przejść na programowanie niskopoziomowe, bo to łatwizna.

Akurat ja zrobiłem takie przejście (dokładnie z Javy). Na początku trzeba obczaić zbiór trochę innych zasad potem jest z górki. Na niskim poziomie wszystko jest bardziej przewidywalne i tak na prawdę łatwiej to ogarnąć niż np. takie bazy danych.

0

Z programowaniem niskopoziomowym problem jest taki, że masz do dyspozycji znacznie mniejszy arsenał, a musisz zrobić za jego pomocą dużo. Z kolei, jeśli chodzi o wysoki poziom (java, .net), arsenał jest tak ogromny, że mało kto w całości go ogarnia. Tym bardziej, że nie ma tu zastoju - ciągle pojawiają się usprawnienia, dodatkowe rzeczy i dodatkowe nowe frameworki.

Czyli problemem nie jest zrobienie czegoś, tylko ogarnięcie wszystkiego co się ma do dyspozycji aby osiągnąć cel i poskładanie tego razem w sensowny, logiczny nie tylko dla autora sposób.

0

autor:
Mieszasz dwie różne sprawy:

  1. Łatwość języka: Asembler jest zdecydowanie jednym z najprostszych języków. W zasadzie format instrukcji jest banalny, obsługa wskaźników jest oczywista, składnia (oprócz mnemoników) jest też zwykle dość prosta.
  2. Łatwość tworzenia programów: Programy w asemblerze są wielokrotnie większe, zawierają zwykle zbyt dużo ręcznych optymalizacji, aby analiza składniowa czy refaktoryzacja była efektywna. Wobec tego utrzymywanie kodu asemblerowego złożonego z milionów linijek jest bardzo kosztowne, generalnie koszty rosną dużo szybciej niż przy wykorzystaniu innych języków.

Ja zacząłem programować od czystego asemblera (pomijając HTML/ CSS/ JavaScript), potem K&R C oraz Turbo Pascal. Opanowanie C i Pascala było raczej łatwe, przede wszystkim dlatego, że te języki wiele się od asemblera nie różnią, w zasadzie można powiedzieć, że C to jest przenośny asembler. Problem miałem właśnie przy przejściu na Javę, zrozumienie obiektowości oraz rozróżnienia między zmiennymi statycznymi i zmiennymi instancji trochę mi zajęło (mimo iż używałem zmiennych lokalnych w asemblerze).

W sumie asembler to idealny język, jeżeli chce się dobrze zrozumieć ideę wskaźników.

0

Z programowaniem niskopoziomowym problem jest taki, że masz do dyspozycji znacznie mniejszy arsenał, a musisz zrobić za jego pomocą dużo

Wcale nie musisz zrobić dużo. Dużo to by było jakbyś musiał np. zaimplementować serwer http w assemblerze. Oczywiście zaimplementowanie serwera HTTP w Javie jest znacznie prostsze. Sęk w tym, że nikt nie implementuje serwerów HTTP w assemblerze.
Na niskim poziomie masz zupełnie inne zadania ładnie dostosowane do pracy w niskopoziomowych językach i środowiskach.

0

Ja miałem styczność i z niskim i wysokim poziomem. Dla mnie wysoki poziom jest łatwiejszy. Trochę ciężko mi wyjaśnić dlaczego ale w ogólności chodzi o to, że na wyższym poziomie łatwiej mi zbudować pewną abstrakcję która pomaga przy projektowaniu programu i organizacji kodu. Dzięki obiektowemu podejściu jakoś łatwiej mi rozrysować sobie schemat na kartce, widzę wtedy więcej zależności i jakoś tak samo wychodzi jakich mechanizmów muszę użyć.

0

Jak się wie co się robi to nic nie jest trudne. "Czarna magia" zaczyna się wtedy kiedy człowiek chce zrobić coś czego do końca nie czai.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0