Witam,
Ostatnio stwierdziłem, że mam dosyć programowania wysokopoziomowego (obiektówka to imho b. przereklamowana sprawa) a że w językach na prawde wysokiego poziomu (np. Haskell) praktycznie nic się nie programuje komercyjnie stwierdziłem, że wolę zejść na niski poziom. Na niskim poziomie przynajmniej decyzje projektowe podejmuje się kierując realnymi przesłankami jak rozmiar kodu, zużycie pamięci szybkość wykonania.
No ale ten post nie miał być o porównywaniem niższego levelu z wyższym. Mianowicie chciałbym zająć się systemami czasu rzeczywistego na platformy embedded. Niestety nie mam w tym żadnego doświadczenia (jedynie jakaś tam znajomość budowy wewnętrznej Linuksa i Windowsa). Co muszę się nauczyć, żeby zatrudnić się w firmie programującej RTOSy tudzież inne niskopoziomowe rzeczy? Jak przygotować się do rozmowy w takiej firmie? Czy moje poprzednie 2 letnie doświadczenie w programowaniu wysokopoziomwym ma jakieś znaczenie?
Pozdrawiam.
recordable napisał(a)
Na niskim poziomie przynajmniej decyzje projektowe podejmuje się kierując realnymi przesłankami jak rozmiar kodu, zużycie pamięci szybkość wykonania.
No, jeżeli programując wysokopoziomowo nie zwracałeś na to uwagi, to nic dziwnego, że uważasz to za przereklamowane. [rotfl]
somekind napisał(a)
recordable napisał(a)
Na niskim poziomie przynajmniej decyzje projektowe podejmuje się kierując realnymi przesłankami jak rozmiar kodu, zużycie pamięci szybkość wykonania.
No, jeżeli programując wysokopoziomowo nie zwracałeś na to uwagi, to nic dziwnego, że uważasz to za przereklamowane. [rotfl]
To ty chyba jeszcze nie wiesz co znaczy oszczędność pamięci na mikrokontrolerze z 64kB ramu.
To Ty nie wiesz co to oszczędność pamięci przy pisaniu 'podejrzanych' rzeczy.
Możemy się licytować na rozmiary do woli, tylko do czego to prowadzi?
To Ty nie wiesz co to oszczędność pamięci przy pisaniu 'podejrzanych' rzeczy.
Możemy się licytować na rozmiary do woli, tylko do czego to prowadzi?
Zauważ, że ja tej licytacji nie zacząłem. Chodzi mi tylko, że dla zwykłych programów użytkowych dostępna pamięć jak i procesor jest prawie nieograniczona. Inaczej rzecz się ma z urządzeniami o ograniczonych zasobach.
recordable napisał(a)
Chodzi mi tylko, że dla zwykłych programów użytkowych dostępna pamięć jak i procesor jest prawie nieograniczona.
Tja, takie założenia przyjęli Twórcy Firefoksa czy KDE...
A ja Cię rozumiem. Niski poziom ma 2 niesamowite zalety:
- Jest mniej rzeczy do nauczenia, specyfikację do wielu mikrokontrolerów można sobie przyswoić w weekend, no może w dwa, jeśli się programowało wcześniej. Porównaj to sobie z przyswojeniem powiedzmy JEE i technologii około-JEE :>
- Jest bardziej sexy. Stronę w PHP potrafi wyklikać byle gimnazjalista i nikogo to nie dziwi, ale jak napiszesz kawałek softu w assemblerze, to już możesz robić za mega-haxiora. :D
recordable napisał(a)
To ty chyba jeszcze nie wiesz co znaczy oszczędność pamięci na mikrokontrolerze z 64kB ramu.
Masz rację, nie wiem tego. :( Nigdy nie potrzebowałem aż takich ilości pamięci, zadowalałem się takimi z 8kB. Może mi opowiesz o tych swoich?
W każdym programie, bez względu na platformę, powinno się zwracać uwagę na ilość zajmowanych zasobów, bez względu na to, ile ich jest. Zasady są te same, tylko skala się zmienia.
A ja Cię rozumiem. Niski poziom ma 2 niesamowite zalety:
- Jest mniej rzeczy do nauczenia, specyfikację do wielu mikrokontrolerów można sobie przyswoić w weekend, no może w dwa, jeśli się programowało wcześniej. Porównaj to sobie z przyswojeniem powiedzmy JEE i technologii około-JEE
No porównanie mam - rok pracowałem w Spring + Hibernate.
Zgadzam się, że przyswoić prościej ale za to programuje się trudniej.
- Jest bardziej sexy. Stronę w PHP potrafi wyklikać byle gimnazjalista i nikogo to nie dziwi, ale jak napiszesz kawałek softu w assemblerze, to już możesz robić za mega-haxiora.
To mi akurat lata.
recordable napisał(a)
Zgadzam się, że przyswoić prościej ale za to programuje się trudniej.
Dobre, zgodne z inżynierią oprogramowania programowanie wysokopoziomowe jest trudniejsze od niskopoziomowego, zdecydowanie.
Dobre, zgodne z inżynierią oprogramowania programowanie wysokopoziomowe jest trudniejsze od niskopoziomowego, zdecydowanie.
Możesz wyjaśnić czemu?
Bo programowanie niskopoziomowe to znacznie niższa abstrakcja? W praktyce 'dobry styl' to zbiór zasad na poziomie elementarnej matematyki. Ograniczone liczba tricków, które można sprowadzić do gotowych schematów. Fakt, nauczenie tego wymaga dużo czasu, jednak 'w użyciu' jest znacznie prostsze niż wysoka abstrakcja + IO.
Nie porównuj tworzenia dużego i naprawdę skomplikowanego oprogramowania z mikrokontrolerami.
Na niskim poziomie abstrakcji nie rozwiązujesz tak złożonych problemów jak na wysokim.
I analogicznie nie budujesz tak złożonych systemów.
@Królik, Świętowit: Jakie projekty wykonaliście (uC programming) że macie takie dobre porównanie?
EDIT
Jeżeli autor pisząc niski poziom miał na myśli niskopoziomowy soft na PC to pewnie macie racje, nie znam się na tym.
Jeżeli piszemy o projektowaniu i programowaniu urządzeń elektronicznych opartych na uC to nie zgodzę się że wiedzę do tego potrzebną można zdobyć w krótszym czasie niż wiedzę potrzebną do projektowania i programowania wysokopoziomowych systemów.
Królik, Świętowi - uważacie, że np. router wifi jest prostszym systemem niż jakiś CRM pisany w J2EE? A właśnie o taki soft mi chodzi.
Dlaczego J2EE jest prościej się programuje? Chociażby dlatego, że posiada zarządzanie wątkami. Trzeba mieć jakąś tam więdze na temat wątków ale nie tak dogłębną jak w przypadku RTSów.
Z kolei programując mikrokontrolery nie musisz mieć wiedzy na temat inżynierii oprogramowania, wzorców projektowych, baz danych, itp. Do tego ograniczasz się do jednego-dwóch języków, a nie kilku-kilkunastu języków, technologii oraz bibliotek. Ponadto nie musisz znać się na tworzeniu interfejsów użytkownika, nie musisz też zajmować się analizą funkcjonalną.
Generalnie możesz sam wszystko zrobić, zaś w przypadku systemów wysokopoziomowych potrzebny jest sztab fachowców.
Generalnie możesz sam wszystko zrobić, zaś w przypadku systemów wysokopoziomowych potrzebny jest sztab fachowców.
LOL. :D
nie musisz mieć wiedzy na temat inżynierii oprogramowania
Bzdura. W takim razie ciekawe czemu w niektórych ofertach na embedded wymagają UML <rotfl> Już pomijam to że niektóre urządzenia programuje się obiektowo w C++.
Do tego ograniczasz się do jednego-dwóch języków
Bzdura. Assemblery na wszelakie procesory, C, C++, VHDL, Verilog. Do tego dochodzi znajomość elektroniki cyfrowej jak i analogowej oraz takich dziedzin jak teoria sygnałów, czy metody numeryczna (np znajomość standardu ieee 754 na dosyć głębokim poziomie).
Ponadto nie musisz znać się na tworzeniu interfejsów użytkownika
Bzdura. Część urządzeń wbudowanych ma jak najbardziej interfejs graficzny.
nie musisz też zajmować się analizą funkcjonalną
A to czemu niby nie musisz?
I te wszystkie cuda, na które się powołujesz niby dotyczą wspomnianych przez Ciebie mikrokontrolerów wyposażonych w całe 64kB pamięci?
Świętowit napisał(a)
I te wszystkie cuda, na które się powołujesz niby dotyczą wspomnianych przez Ciebie mikrokontrolerów wyposażonych w całe 64kB pamięci?
Zauważ, że w temacie nie pisałem o uc tylko ogólnie o platformach embedded.
Mikrokontrolerów dotyczy współbieżność, znajomość elektroniki i standardu liczb zmiennopozycyjnych.
recordable napisał(a)
Bzdura. W takim razie ciekawe czemu w niektórych ofertach na embedded wymagają UML
UML to tylko niewielka część IO.
Bzdura. Assemblery na wszelakie procesory, C, C++, VHDL, Verilog. Do tego dochodzi znajomość elektroniki cyfrowej jak i analogowej oraz takich dziedzin jak teoria sygnałów, czy metody numeryczna (np znajomość standardu ieee 754 na dosyć głębokim poziomie).
A ja muszę znać zasady i reguły programowania obiektowego, wzorce projektowe (w tym MVP i MVC), zasady projektowania i optymalizacji baz danych. Jeśli chodzi o języki i technologie, to: C#, ASP.NET, CSS, (X)HTML, JS, ADO.NET, Entity Framework, Linq to SQL, NHibernate, NLog, Windsor, T-SQL, MS-SQL Server, MySQL, PostgreSQL, protokół HTTP, działanie przeglądarek internetowych, itd.
Zauważ, że wymieniłem tylko czystą technikę, jeszcze bez jakiejkolwiek dziedziny problemu, którą muszę zrozumieć, żeby zrobić cokolwiek przydatnego.
I generalnie jest tak, że im więcej masz elementów składowych tym trudniejsze jest złożenie tego do kupy.
Część urządzeń wbudowanych ma jak najbardziej interfejs graficzny.
Tworzenie użytecznych, funkcjonalnych i estetycznych interfejsów użytkownika jest odrębną dziedziną wiedzy. Duże firmy płacą ogromne pieniądze za badania opinii użytkowników o ich produktach, aby móc je bardziej dopasowywać do ich potrzeb.
Nie ma porównania między interfejsem graficznym, o którym piszesz, a super-wypasionym, interaktywnym, czytelnym, eleganckim i kompatybilnym ze wszystkimi przeglądarkami interfejsem "jakiegoś CRMa", którego wymagają użytkownicy.
A to czemu niby nie musisz?
A musisz? W jakim stopniu?
@somekind: Żadnego projektu na uC nie zrobiłeś prawda? Gdybyś wiedział ile skilli musi mieć zawodnik żeby dobrze zarabiać na projektowaniu elektroniki....
Dlaczego tak usilnie próbujesz autora przekonać o poziomie trudności jednej dziedziny nie znając drugiej?
Poza tym nie czujesz, że offtopujesz? Potrzeba wyrażenia jaki jesteś mądry jest aż tak silna? Wierz mi, nie musisz tego robić. Jakbym potrzebował pomocy dotyczącej chociażby C# w którym dłubię co nie co to Twoje rady byłyby dla mnie niezwykle cenne.
Autor zakładając ten temat raczej nie miał zamiaru umniejszać złożoności wiedzy wysokopoziomowej. Szkoda że wysokopoziomowcy chcą dyskutować o złożoności wiedzy której nie posiadają.
(edit literówki)
A ja muszę znać zasady i reguły programowania obiektowego, wzorce projektowe (w tym MVP i MVC), zasady projektowania i optymalizacji baz danych. Jeśli chodzi o języki i technologie, to: C#, ASP.NET, CSS, (X)HTML, JS, ADO.NET, Entity Framework, Linq to SQL, NHibernate, NLog, Windsor, T-SQL, MS-SQL Server, MySQL, PostgreSQL, protokół HTTP, działanie przeglądarek internetowych, itd.
Większość z tego jest do przyswojenia 1-30 dni. Przykładowo MVC nauczyłem się wykorzystywać w kilka godzin.
Spróbuj sobie przyswoić teorie sygnałów albo zaimplementować standard IEEE754 np. dla ARMa w kilka godzin.
Śmieszą mnie te wszystkie oferty Javowo-C# gdzie wymieniają 20 technologii w tym biblioteke do logowania, którą można nauczyć się w pół godziny. Być może dlatego wysokopoziomowcy myślą że mają taką potężną wiedzę [rotfl]
@up: Bo mają. No przynajmniej na tym forum jestem w stanie pokazać Ci paluchem którzy wysokopoziomwcy znają się na rzeczy. Jeżeli mówimy o budowaniu profesjonalnych systemów trzeba poruszać się w zagadnieniach obiektowych które wcale nie są takie intuicyjne.
Szkoda tylko, że nie dopuszczają do siebie myśli że zagadnieniami z samej szeroko pojętej elektroniki możnaby pokryć (mam na myśli rozpiętość materiału do przyswojenia) połowę technologii które wymienił somekind.
recordable napisał(a)
Przykładowo MVC nauczyłem się wykorzystywać w kilka godzin.
Które MVC?
several napisał(a)
Autor zakładając ten temat raczej nie miał zamiaru umniejszać złożoności wiedzy wysokopoziomowej.
Nie? Przeczytaj sobie od początku.
recordable napisał(a)
Na niskim poziomie przynajmniej decyzje projektowe podejmuje się kierując realnymi przesłankami jak rozmiar kodu, zużycie pamięci szybkość wykonania.
recordable napisał(a)
Chodzi mi tylko, że dla zwykłych programów użytkowych dostępna pamięć jak i procesor jest prawie nieograniczona.
Też uważasz, że komputery mają nieograniczone zasoby i nie trzeba zwracać uwagi na wydajność?
Ja sobie zdaję sobie sprawę, że elektronika, technika cyfrowa, sygnały wymagają ogromnej wiedzy (dla Twojej wiedzy - studiowałem kiedyś elektronikę). Ja nie dezawuuję tego, tylko piszę o tym, że tworzenie aplikacji wysokopoziomowych również wymaga ogromnej wiedzy, a ponadto wymaga jednak zwracania uwagi na rzeczy, które autor niesłusznie uważa za nieważne. Licytacji na akronimy też chyba nie ja zacząłem.
Pewno chodzi Ci o to moje zdanie:
somekind napisał(a)
Generalnie możesz sam wszystko zrobić, zaś w przypadku systemów wysokopoziomowych potrzebny jest sztab fachowców.
Faktycznie, mogłem przesadzić z tym "sam". Chyba trochę za bardzo uprościłem, po prostu opieram się w zasadzie na tym, co sam widziałem i słyszałem. Znam programistów mikrokontrolerów realnie pracujących w przemyśle, wiem o nich, że sami ogarniają swoją działkę, od początku do końca. Nie spotkałem się natomiast z tworzeniem dużych systemów informatycznych jednoosobowo, bo nie ma np. osób, które znałyby się na BD i UX jednocześnie.
I najważniejsze - nie jestem mądry.
somekind napisał(a)
several napisał(a)
Autor zakładając ten temat raczej nie miał zamiaru umniejszać złożoności wiedzy wysokopoziomowej.
Nie? Przeczytaj sobie od początku.
Przeczytałem, sądzę że rok doświadczenia autora w programowaniu wysokopoziomowym to trochę za mało, być może uczestniczył w mniejszych projektach? Za krótki jestem żeby wdawać się w polemikę dotyczącą projektowania wysokopoziomowego. Zdaje sobie tylko sprawę ile trzeba ogarniać do tego.
somekind napisał(a)
Znam programistów mikrokontrolerów realnie pracujących w przemyśle, wiem o nich, że sami ogarniają swoją działkę, od początku do końca.
No tak, ale Ty też ogarniasz swoją działkę/zadanie do wykonania od początku do końca prawda? Ty piszesz o dużych systemach wysokopoziomowych, do dużych projektów sprzętowych też jest potrzebny zespół ludzi. Mam tu na myśli projekty dla awioniki, czy chociażby głupią z pozoru elektronikę do miejskich autobusów (tych "mówiących"). Nie uwierzę też, że projekty dla wojska są wykonywane przez jednego człowieka. Do takich projektów napisanie softu często jest najłatwiejszym i najprzyjemniejszym zadaniem, nawet jeśli jesteśmy skazani na pisanie w asm.</quote>
Które MVC?
Zarówno dla aplikacji webowych jak i dla aplikacji gdzie MVC możę używać observera (czyli GUI). Jak coś pomieszałem to przepraszam, nie używałem tego już ponad rok.
Nie? Przeczytaj sobie od początku.
Nie miałem. Po prostu rozczarowałem się obiektówką i wysokim poziomem. A pracowałem w projekcie b dużych (~800k linii) i właśnie po nim doszedłem do takich wniosków.
Też uważasz, że komputery mają nieograniczone zasoby i nie trzeba zwracać uwagi na wydajność?
Nie trzeba zwracać uwagi w takim stopniu jak na platformach wbudowanych. Pracowałem przy pisaniu serwera aplikacji dla pewnej działki przemysłu: nikt się nie szczypał z alokowaniem pamięc. Jak przy 2G zaczynał zbyt często GC chodzić to po prostu dołożyli kolejne 2G.
A główną intencją mojego postu było się dowiedzieć jak wygląda rozmowa na programiste embedded. Widać będe musiał poszukać innegog forum.
http://www.ganssle.com/startinges.htm
I jeszcze mały link jak ktoś myśli że programowanie embedded jest takie proste.
a mi się wydaje że programowanie niskopoziomowe to zupełenie inny sposób myślenia. W obiektówce "mówię" zrób coś do zmiennej (i często nie interesuję się jak "ta zmienna coś robi") a niskopoziomowym trzeba samemu napisać obsługę operacji ze zmienną. Dalej, niskopoziomowe jest pełne wskażników (chyba, programowałem troszeczkę tylko w asm) w Javie się zbytnio nie martwię że zapomniałem zwolinić pamięć, albo zmieniłem referencję do obiektu i mi się wyciek pamięci zrobił. Z kolei programowanie użądzeń wymaga oprócz znajomości programowania... znajomości urządzenia (chociażby w asm są różne listy rozkazów) i przypuszczam że też są jakieś wzorce, bo ilość kodu w takich programach jest kilkakrotnie większa.
Wspomniałem o asm. Osobiście próbowałem się kiedyś go nauczyć, ale mój obiektowy sposób myślenia, który jest dla Mnie naturalny mocno kłócił się z tym czego próbowałem się nauczyć i na kilku tygodniach się skończyło. Ale z tego co pamiętam to w asm wszystko było w pewnym sensie łamigłówką, jak przemieszczać dane między rejestrami aby sobie czegoś nienadpisać, bo laboga, później nie znajde gdzie jest błąd.
Jakiś czas temu na tym forum był topic o programowaniu dla wojska:
http://4programmers.net/Forum/viewtopic.php?id=160641
może znajdziesz coś co się przyda.
at higher levels, you can’t even understand what’s going on
To zdanie IMHO jest kluczowe. Dlatego na niskim poziomie da się stosować logikę a na wysokim poziomie często trzeba robić tępy brute force, aby coś zadziałało.