Czy inżynierowie oprogramowania naprawdę muszą już znać rzeczy na niskim poziomie? [Zamknięte]

W miarę rozwoju języków programowania wysokiego poziomu, takich jak C #, Java itp., Wiele osób twierdzi, że będą one alternatywą dla języków takich jak język asemblera i C / C ++, który zapewnia dostęp i kontrolę nad sprzętem komputerowym, ponieważ programiści powinni na temat tworzenia programu i rozwiązywania problemów, nie marnowania czasu na pracę z komputerem, aby działał. Ponieważ sprzęt ciągle się poprawia, różnica w wydajności między C / C ++ a Javą nie będzie znacząca, a duże gry mogą być programowane w języku takim jak Java.

Oto ogólny pomysł, który krótko streszczam po zapoznaniu się z tym tematem w Internecie. Czy uważasz, że stanie się to rzeczywistością w najbliższej przyszłości? Czy to oznacza, że ​​wszystko, czego dowiadujemy się o rzeczach niskiego poziomu, nie jest już praktyczne dla branży oprogramowania? Czy to oznacza, że ​​język asemblera i C / C ++ będą odpowiednie tylko dla inżynierów elektryków, ponieważ tylko oni będą musieli programować swoje komponenty elektryczne?

---

Ile wystarczy nauki? Jeśli nauczymy się zbyt wielu rzeczy na niskim poziomie, ostatecznie staniemy się bardziej zorientowani w elektrotechnice lub jeśli nauczymy się zbyt dużej matematyki, moglibyśmy uczyć się, jak zostać matematykami, a nie programistami. Chcę tylko wiedzieć, czy rzeczy matematyczne, których się nauczyłem (wziąłem kurs matematyki, który obejmuje materiał podobny do tej książki (używali innego podręcznika): Matematyka dyskretna i jej zastosowanie) jest tak samo przydatne, jak nasz zestaw umiejętności programistycznych. Wiele ćwiczeń matematycznych może zająć nam większość godzin, a jeśli mówisz poważnie, będziesz mieć mniej czasu na naukę programowania. Na naszym forum gamedev nawet matematyka i fizyka mają tylko jedną sekcję, w porównaniu do programowania.

Właśnie teraz zacząłem czytać „The Art of Computer Programming”. Matematyka jest omówiona tylko w około jednej czwartej książki, ale ćwiczenie to jest trudne dla nas, nie matematyków. Nawet taka „podstawowa” matematyka, czy wykorzystaliśmy ją tak często w naszej karierze? Niektórzy ludzie pewnie powiedzieliby mi, że czytanie książki TACOP to strata czasu i prawdopodobnie powinni spędzić czas na czymś bardziej praktycznym, nawet jeśli w książce chodzi o programowanie (nieco bardziej akademickie w porównaniu do książki wyjaśniającej podobne rzeczy). Ale myślę, że autor poświęcił wiele czasu i wysiłku, aby go wyprodukować. Może nawet napisać pełny zestaw 5 książek, a my - publiczność - mamy tylko misję go przeczytać. Dlaczego nie?

Interesujące pytanie. Jestem od dawna programistą C ++, który teraz pracuje w C # (z odrobiną niezarządzanego C ++ do pracy krytycznej pod względem wydajności) i historycznie musiałem dodawać sporadyczne fragmenty kodu asemblera, zwykle ze względu na wydajność.

Kilka punktów w przygotowaniu odpowiedzi na pytanie:

• Dla własnego porównania sugeruję, że podstawową różnicą między wspomnianymi językami, C # i Javą, z drugiego zestawu, Assembly, C / C ++ jest to, że te pierwsze używają zarządzanego środowiska wykonawczego do zapewnienia odśmiecania. Istnieją inne różnice (np. Przenośność binarna, rozmiar frameworku i przenośność), ale gdy patrzysz na porównywanie różnic w wydajności, jest to (?) Ważny czynnik.

• Asembler, C i C ++ są dalekie od równie „niskiego poziomu”. Myślę, że masz rację, łącząc języki asemblera i C z programistami sprzętu / oprogramowania układowego / sterowników, ale C ++ jest zwykle używany na wyższym poziomie i nadal jest intensywnie używany - chociaż wyraźnie C # / Java pisze go zgodnie z TIOBE indeks.

• W warstwie C ++ dodałbym Objective-C, ponieważ bardziej przypomina on C ++ niż C # / Java. Na koniec chciałbym zauważyć, że po dodaniu shared_ptr <> i innych funkcji automatycznego zarządzania zasobami języki te obsługują coś zbliżonego do wyrzucania elementów bezużytecznych.

OK - przejdź do głównego pytania: czy inżynierowie oprogramowania naprawdę muszą już znać rzeczy na niskim poziomie?

Moja odpowiedź: tak

Powody:

• Nawet podczas korzystania z C # / Java prawdopodobnie natkniesz się na jednostki frameworka, które wymagają jawnego zarządzania zasobami i / lub napotkasz problemy z „przypiętymi” wykresami pamięci w dowolnych nietrywialnych aplikacjach. Musisz zrozumieć, jak działają te systemy, aby skutecznie unikać tych problemów i debugować je.
• Platformy mobilne mają bardziej ograniczone zasoby i chociaż na niektórych obsługiwana jest ograniczona wersja Java i .NET, obecna dominacja iOS i Objective-C sugeruje, że jest to od dawna przedłużone życie.
• Wydajność: za każdym razem, gdy natrafisz na ścianę wydajności, prawdopodobnie będziesz musiał wpaść do natywnie skompilowanego fragmentu kodu, aby go obejść.
• Starsza obsługa: za każdym razem, gdy trzeba interopować, aby uzyskać dostęp do funkcji, która nie została (jeszcze) ujawniona w kodzie zarządzanym, musisz zrobić to samo.

Dobre pytanie - ale nie widzę, żeby niezarządzane języki znikały w najbliższym czasie.

• To, że ktoś zgodnie z prawem nie dowie się i nie zrozumie funkcjonalności niższego poziomu, i nadal będzie bardzo produktywnym i wartościowym programistą, już tak jest.
• Nigdy nie będzie tak, że nikt nie będzie musiał uczyć się ani rozumieć funkcjonalności niższego poziomu, że zawsze będzie to strata czasu.

Jak w każdej dyscyplinie inżynierii, istnieje wiele kroków do produktu końcowego, z których wszystkie są ważne, wymagają specjalistycznej wiedzy i są cenne. W szczególności w inżynierii oprogramowania mamy wiele warstw abstrakcji. Wszystkie są potrzebne i nikt nie może być ekspertem od nich wszystkich.

Biorąc to pod uwagę, potrzebujemy więcej programistów C # / Java / Ruby niż programistów Assemby / C. Dla nas programistów „wyższego poziomu” zrozumienie więcej o tym, co się dzieje „pod maską” jest pomocne i sprawi, że będziemy lepszymi programistami. Ale robi to również wiele innych rzeczy . Jako programista .NET, na przykład, jest tyle rzeczy, które mogę się nauczyć, aby uczynić mnie bardziej produktywnym, że nauka naszego języka pośredniego (znacznie mniej C ++ / C / Assmebly), choć bardzo pomocna, często musi zająć miejsce.

Możesz zarabiać na życie jako programista, nie znając rzeczy na niskim poziomie. Myślę, że dzięki temu jesteś lepszym programistą.

Utrzymanie wysokiego poziomu kompetencji w zakresie rzeczy niskiego poziomu staje się jednak coraz mniej ważne. Mam na myśli, że nie robiłem nic na zgromadzeniu przez 20 lat i prawdopodobnie potrzebowałbym poważnego odświeżenia, zanim znów będę mógł być produktywny, ale ogólne koncepcje działania rzeczy na tym poziomie są nadal częścią mojej świadomości i uważam, że jest pomocny od czasu do czasu, nawet podczas pracy w językach wyższego poziomu.

Nie sądzę, programiści jądra zawsze będą potrzebować rzeczy niskiego poziomu. Nie szkodzi również zrozumienie, jak wszystko działa, jeśli zasadniczo zrozumiesz, co właściwie pisze kod, nauczysz się pisać lepszy kod. Myślę, że usunięcie rzeczy niskiego poziomu jest okropnym pomysłem, ponieważ takie abstrakcyjne myślenie jest czasami przydatne, ale może być przeszkodą, jeśli chcesz rozwiązać problem w najlepszy sposób. Na przykład zrozumienie, że podczas łączenia łańcuchów faktycznie tworzysz nowe łańcuchy, jest ważne, ale jeśli nie rozumiesz, w jaki sposób łańcuchy zostały zaimplementowane, możesz po prostu połączyć je i poczekać 5 minut, które zajmie uruchomienie programu. To jest doskonały artykuł na takie tematy: http://www.joelonsoftware.com/articles/fog0000000319.html

Zależy to od tego, nad czym tak naprawdę pracuje inżynier oprogramowania. Możliwe jest produktywne, szczęśliwe i dochodowe zajęcie bez dotykania niczego na niskim poziomie, ale to nie wszystkie zadania programistyczne. Aby istniały systemy operacyjne i kompilatory, muszą istnieć inżynierowie pracujący nad systemami operacyjnymi i kompilatorami, którzy będą musieli znać C, C ++ i język asemblera swojego komputera.

Wydajność może również mieć znaczenie. Mój obecny laptop jest bardzo z grubsza milion razy potężniejszy niż mój pierwszy komputer domowy, a uruchamianie oprogramowania może wciąż wymagać czasu. Nadal mogę mieć opóźnienie w grach wideo. Oczywiście gry wideo wyglądają lepiej, ponieważ każdy z ponad miliona pikseli na ekranie może mieć jeden z milionów kolorów (w przeciwieństwie do tysiąca czarno-białych pozycji znaków, przy czym niektóre postacie są używane w grafice ). Wątpię, czy w najbliższej przyszłości uzyskamy kolejny tysiąckrotny wzrost mocy komputera, a jeśli tak, spodziewam się, że będzie on wykorzystywany przez coraz bardziej złożone oprogramowanie.

Podczas gdy większość oprogramowania biznesowego będzie nadal pisana w najszybszym możliwym do wyprodukowania i dostępnym miejscu, co zwykle nie jest C, nadal będzie dużo miejsca dla ekspertów C i C ++.

„Ponieważ sprzęt ciągle się poprawia, wydajność między C / C ++ a Javą nie będzie znacząca, a duża gra może być programowana w języku takim jak Java”.

Nie wierzę, że to stwierdzenie będzie poprawne w najbliższym czasie. W kodzie zarządzanym zawsze występuje trafienie z powodu kontroli przeprowadzonych za sceną. Nie jest to również kwestia sprzętu, ponieważ sprzęt staje się lepszy, podobnie jak aplikacje, które mają na nim działać. System napisany w natywnym kodzie musi mieć interfejs do kodu zarządzanego. Jest hit wydajności, który występuje podczas przełączania między nimi.

Jednak tylko niewielki procent aplikacji naprawdę potrzebuje tego zoptymalizowanego kodu. Większość aplikacji biznesowych jest w porządku z dowolnym kodem zarządzanym, .net, java itp. Nie oznacza to jednak, że aplikacje, które tego potrzebują, wkrótce dokonają zmiany. Jednak ręczne pisanie jest teraz znacznie mniej używane, a optymalizujące kompilatory C / C ++ są tak dobre. Ostatnio pojawił się system operacyjny napisany całkowicie w asemblerze, więc niektórzy wciąż go mają. Jest to również bardzo ważne w dziedzinie bezpieczeństwa.

Powiedziałbym jednak, że aby być naprawdę dobrym programistą, należy zrozumieć, co się dzieje na niskim poziomie. Pomaga w rozwiązywaniu niektórych trudnych problemów, szczególnie podczas wywoływania kodu macierzystego.

Myślę, że znajomość niektórych rzeczy niskiego poziomu jest bardzo pomocna przy debugowaniu, jak na przykład przy programowaniu Embedded, większość z nich odbywa się za pomocą C, jednak podczas debugowania znajomość asemblera dla tego konkretnego Mikrokontrolera jest niezwykle przydatna.

Gdy komputery zostały wynalezione po raz pierwszy, tylko kilka osób wiedziało, jak z nich korzystać. Teraz większość domów w bogatym kraju ma 1 lub więcej komputerów, które są użyteczne dla przeciętnego człowieka. Wiele zwykłych ludzi codziennie pracuje na komputerach. Przeciętny człowiek potrafi posługiwać się komputerem, ale wciąż potrzebujemy programistów.

Podobnie przeciętny programista nie musi znać ani regularnie programować w asemblerze. Jest to zarówno warunek umiejętności rynkowych, jak i salut, jak daleko zaszliśmy w świecie technologii. Biznes potrzebuje komputerów do automatyzacji zadań. Dlatego programiści, którzy mogą programować w .NET / Java, są bardzo poszukiwani.

Zadania, które można zautomatyzować, zostaną zautomatyzowane. Nie wszystkie zadania można zautomatyzować. Nie cała automatyzacja jest idealna. Czy więc montaż jest ważny? Oczywiście. Czy wymagane jest bycie „programistą”? Oczywiście nie.

Hmmm Właściwie to lubię uczyć się rzeczy na niskim poziomie.

Może to nie jest najdokładniejsze porównanie, ale dla mnie to jak nauka mechaniki w samochodzie. Mogę nie wiedzieć, jak wszystkie elementy działają przeciwko sobie, ale fajnie jest wiedzieć, że jest silnik, wał korbowy, cylindry, dyferencjały, dźwigi, hamulce, olej, spalanie, chłodzenie, a następnie tarcie, stres, ciepło, siły, nauka - termodynamika, fizyka, mechanika płynów ...

Może niezbyt przydatny (nie będę w stanie naprawić samochodu, wiedząc o tym wszystkim), z pewnością niepraktycznie praktyczny, ale, cóż, zabawny. L'art pour l'art: la connaissance pour la connaissance.

Myślę, że użyteczną praktyczną zasadą jest - im szybciej musi być, tym niższy poziom musisz uzyskać.

Więc twoja intensywna strzelanka FPS lub algorytmiczny system handlu FX nadal są na dość niskim poziomie (C ++ itp.), Ponieważ szybkość jest kluczowa. Ale aplikacja internetowa, która na czas wyrzuca raport sprzedaży? Do diabła, mógłbyś napisać to w Sinclair BASIC, i nadal byłoby to do przyjęcia.

Nie wszystkie zadania inżynierii oprogramowania są takie same . Ludzie pracujący nad systemami operacyjnymi, kompilatorami, frameworkami, sterownikami urządzeń, systemami osadzonymi i wysokowydajnymi komputerami naukowymi powinni dobrze znać „rzeczy niskiego poziomu”. Ludzie piszący formularze Access CRUD lub wózki sklepowe PHP dla sklepów Mom i Pop, może nie tak bardzo. Jaki rodzaj inżynierii oprogramowania chcesz robić i czy chcesz to robić do końca życia?

Uważam, że musisz nauczyć się przynajmniej jednego poziomu abstrakcji poniżej tego, w którym zwykle pracujesz. Jeśli pracujesz w C / C ++, powinieneś wybrać architekturę i montaż maszyny. Jeśli pracujesz w PHP, powinieneś zrozumieć HTTP i trochę C / C ++ lub Perl. Jeśli Access to Twój chleb powszedni, lepiej poznaj teorię RDB, a może trochę o COM lub .Net. W pewnym momencie w swojej karierze w końcu zostaniesz zatrzymany na martwym punkcie przez problem na niższym poziomie abstrakcji i będziesz w stanie przynajmniej trochę komunikować się z kimś, kto jest ekspertem w tej dziedzinie. Czy potrafisz „przetrwać” bez tych rzeczy? Jasne, ale planowanie po prostu „przetrwania” na konkurencyjnym rynku pracy jest niebezpieczne.

Sam pracuję intensywnie w C # .NET i zawsze kierowałem się z dala od C, C ++. Ostatnio zacząłem szukać pracy i byłem zaskoczony, widząc, ile pracy jest dostępnych i wymaga doświadczenia w C, C ++. Początkowo myślałem, że C, C ++ stają się przestarzałe, ale patrząc na dostępne zadania, nie wygląda na to, że tak jest.

Wszystkie wymienione języki zarządzane mają interpretery lub maszyny wirtualne napisane w C / C ++. Bez tych dwóch języków zarządzanych i tłumaczonych nawet nie byłoby. Powiedziałbym, że nie doceniasz ich wartości.

Naprawdę nienawidzę samego pojęcia „praktycznej” wiedzy . Wszystko, czego się nauczysz, jest równie praktyczne. Nie ma znaczenia, czy nie będziesz działał na poziomie abstrakcji zbliżonym do sprzętu, po prostu znajomość pojęć z tej dziedziny jest zawsze korzystna dla budowania nowej wiedzy na innym poziomie abstrakcji. Im więcej powiązanych koncepcji znasz, tym lepiej.

Do tego, co zwykle robię, C # jest językiem bardzo niskiego poziomu i uważam go za coś bardzo zbliżonego do sprzętu. Ale nadal uważam, że nawet moja podstawowa, zardzewiała wiedza na temat elektroniki cyfrowej, projektowania procesorów itp. Jest bardzo przydatna do wszystkiego, co kiedykolwiek robię.

Nie większość nie musi. Chociaż praktykowanie technik niskiego poziomu daje deweloperowi lepszą wiedzę na temat tego, co może wpłynąć na cały cykl, obecnie programista może wykorzystać ten czas na badanie nowszych technologii, co z kolei wymagało znajomości rzeczy na niskim poziomie, które należy opracować, ale nie można na nich polegać na.

Moim zdaniem, kiedy używasz słowa „Inżynier”, masz na myśli, że to mężczyzna / kobieta projektuje i buduje rzeczy od zera. Prawdziwym problemem inżynierów oprogramowania jest rozwiązanie problemu, ale jaki problem? To wielkie pytanie.

Deweloper różni się od Inżyniera pod wieloma względami. „Deweloper” to osoba, która zwykle buduje rzeczy na już istniejących platformach. Opracowuje istniejące platformy lub buduje nowe platformy odziedziczone po starszych, z pewnością używając komponentu systemu nadrzędnego.

Deweloper zwykle myśli z perspektywy biznesowej, nie jest naukowcem. :) Deweloper jest bliżej użytkownika systemu, myśli rzeczy z perspektywy użytkownika i dlatego rozwiązuje problemy użytkownika za pomocą technologii.

Inżynier inteligentny. Jest naukowcem, rozwiązuje bardzo prawdziwy problem. Większość problemów, które sam komputer ma jako funkcję. Nigdy nie zbliżamy się do tego problemu, jest on zamknięty. Inżynierowie porzucili studia po wielu badaniach istniejącego systemu i opracowali coś nowego, aby rozwiązać problem, jeśli wymaga tego rozwiązanie, jeśli ich system potrzebuje nowego języka, wymyślają nowy język, ponieważ istniejący system nie jest w stanie rozwiązanie tego problemu. Inżynierowie zbudowali system, na którym programiści budują swój system.

Rzeczywiście inżynier oprogramowania musi się uczyć i dobrze znać rzeczy niskiego poziomu ... :)

Podczas gdy Deweloper, zależy to całkowicie od jego zainteresowania. :)