W dniu niedziela, 23 października 2016 10:15:03 UTC+2 użytkownik Sebastian Biały
napisał:
> > jednak tego łatwo się nauczyć. Ważniejsze jest wyrobienie intuicji
> > dotyczących złożoności obliczeniowej. Tego się nie da łatwo
> > przekazać w dokumentacji. A do wyrabiania tych intuicji Pascal
> > nadaje się moim zdaniem całkiem dobrze.
>
> To się da trywialnie pokazac w dokumentacji. Piszą że find ma log N i
> tyle. Gwarantuje Ci że wiele algorytmów pisanych od zera jako kwadratowe
> koła ma złe złożoności.
>
> I nie jestem wrogiem pisania sortowania przez studenta. Jestem wrogiem
> języka który *nie* ma innego wyboru jak tylko napisać od zera każdy byt
> potrzebny do pracy. Pascal, wypisz, wymaluj.

Do pewnych rzeczy Pascal się nadaje, do innych się nie nadaje.
Do wyjaśniania algorytmiki nadaje się dobrze.

> >> Takie dwa misie jak pisali wyszukiwarkę google to naprawde nie mieli
> >> pojecia jaka bedzie przyszłość. A pisali. Kretyni.
> > Otóż to. Robili to, co wydawało im się w danym momencie
> > najsensowniejsze. I założę się, że stawiali sobie po drodze
> > różne cele, które następnie realizowali.
>
> Celow nie da się zrealizować bo ich nie było, były tylko mętne,
> nieosiągalne zarysy. Chyba że celem jest dominacja nad światem. To sie
> udało.

To akurat zawsze jest celem. Ale myślę, że po drodze mogły się pojawić
np. takie, jak ułatwienie wyszukiwania rzeczy w internecie.

> >>> Zresztą taki np. SDCC, COSMIC czy uVision nie są, według mojej wiedzy,
> >>> kompilatorami C++.
> >> A clang/gcc jest? I dlaczego nie padły w tym wyliczeniu? I co to za
> >> wyliczenie?
> > GCC jest dostępne na army i na atmele, natomiast w embedded używa
> > się różnych architektur, nawet tak archaicznych, jak 8051.
>
> Serio? 8051 uzywa się gdziekolwiek poza domami starców? Serio, uważasz
> że wyciąganie potworka w designie CPU z lat 70tych ma cokolwiek
> udowadniać współcześnie? Czas 8051 odchodzi podobnie jak czas
> programistów Pascala. Trzeba tylko poczekać i kupić troche dębowych pudełek.
>
> Naprawdę, tłumaczenie że 8051 to przedstawiciel embedded to tłumaczenie
> że Ford T to przedstawiciel motoryzacji. Obecnie embedded stoi wyłacznie
> na ARMach które zebrały cały rynek i zostały tylko glitche i firmy z
> Bytomia od produkcji najszybszych furmanek na świecie.

Widzę, że trafiłem nie dość, że na jasnowidza, to jeszcze na
prawdziwego eksperta od embedded.
Otóż nie. ARMy to są w embedded duże procesory, używane przy
bardziej złożonych zastosowaniach. Do wielu prostych zastosowań
są po pierwsze zbyt kosztowne, a po drugie zbyt prądożerne.
Jeżeli projektujesz układ produkowany seryjnie i mający działać
na jednej baterii przez wiele lat, takie rzeczy mają kolosalne
znaczenie.

Jeżeli idzie o owe 8051, to jest duńska firma, która produkuje
rozwiązania bezprzewodowej automatyki domowej (bardzo nota bene
popularne) oparte właśnie na tej architekturze, i niestety jeśli
chcesz móc dostosowywać ich rozwiązania do swoich celów, musisz
się z tym pogodzić. (Zresztą ich wybór nie był nieracjonalny,
ponieważ dla 8051 istnieją działające, sprawdzone narzędzia).
No, ale co ja tam wiem.

> > W takim razie w jakich jeszcze dziedzinach C++ dominuje?
>
> A co to ma wspólego z Pascalem? Dominue tam gdzie wymagana jest kontrola
> na niskim poziomie i/lub wymagana jest wysoka abstrakcja. Można w nim
> napisać zarówno mała aplikację pod AVR jak i poteżny program z
> wypasionym GUI, zlożoną algorytmiką a w razie czego wyskalować go na
> klastry obliczeniowe.

Rzeczywiście, brzmi jak real-life use case.

> > Mam prośbę. Jeżeli uważasz, że C++ ma jakieś cechy, które miałyby
> > się okazać przydatne w embedded, to byłoby więcej warte, gdybyś
> > napisał, jakie to cechy, zamiast odnosić się do mojej rzekomej
> > niewiedzy w tym temacie.
>
> Pisałem o tym tak wiele razy na grupach (głównie pl.misc.elektronika) że
> aż się odechciewa. Podsumuje jednak:
> a) ścisłe typy. Większość embedded to zastanawianie się który #define
> bitu pasuje do którego rejestru. W C++ problem solved, nie da się
> popełnic tego błedu

Nie bardzo wiem, o czym piszesz z tymi "ścisłymi typami"
(ale w C++ da się popełnić każdy błąd, który da się popełnić w C)

> b) RAII. Powoduje że trywialne błędy z gatunku "zapomniałem zgasić flagi
> przerwania przy wychodzeniu w z funkcji" przestają istnieć.

Z jednej strony, podoba mi się, że C++ poniekąd wymusza
(czy też nakłania) wczesne myślenie o dealokacji zasobów.
Ale z drugiej strony to samo można osiągnąć korzystając
z odpowiednich makr preprocesora C.

> c) Templatey. Pozawalają pisać kod *lepiej* dostosowany do platformy i
> powodować że przenośność jest łatwiejsza.

To samo można zrobić w preprocesorze C, jeśli jest taka potrzeba.
(Tracisz co prawda bezpieczeństwo typów, ale jeżeli napiszesz sobie
dobre testy, nie jest to problemem w praktyce)

> > I uważam, że w kontekście embedded C++ to dużo narzutów i mało
> > korzyści (a często nawet "korzyści ujemne", związane z dużo większym
> > poziomem komplikacji języka)
>
> Uważasz to samo co legacy programmers. Tak więc czekamy na rozwiązanie
> biologiczne.

Rozumiem, że jako osoba żyjąca w przyszłości wiesz, co mówisz.