On 2016-10-23 11:07, g...@g...com wrote:
> Do pewnych rzeczy Pascal się nadaje, do innych się nie nadaje.
> Do wyjaśniania algorytmiki nadaje się dobrze.

Nie. Nadaje się równie dobrze jak każdy inny język. Dodatkowo kazy inny
język *współczesny* nadaje się do masy innych rzeczy. Dlaczego więc
używać do czegokolwiek Pascala? Jaką on ma zaletę? Otóż nie ma żadnej.
Każdy współczesny język potrafi to samo i o wiele więcej.

Odrzuć guru Bieleckiego, przejrzyj na oczy. Świat zmienił się zasadniczo
od bardzo wielu lat.

> 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.

Nieprawda. Koszt STM32, SAM7, LPC i innych rodzin ARM jest obsultnie
znikomy, rzędu ułamków dolara. Pobór prądu jest rownież ulamkowy z
powodu znacznie nowoczesniejszych metod zarzadzania mocą jak również z
powodu znacznie nowszego kodu maszynowego dzięki czemu mozna zrobić to
samo co na 8051 w mniejszej ilości cykli i pójść spać wcześniej.

Tak, troche się na tym znam. Na tyle żeby rozpoznawać sektę 8051 która
posluguje się głównie ignorancją zamiast argumentacją.

> Jeżeli projektujesz układ produkowany seryjnie i mający działać
> na jednej baterii przez wiele lat, takie rzeczy mają kolosalne
> znaczenie.

I wtedy nie bierze się dziadowskiego 8051 tylko CPU przeznaczone do
kolsalnych zastosowań jak niski pobór prądu. Jest tego trochę na rynku.

> 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ć.

Straszne. Jest jakaś jedna duńska firma ktora wybrała Forda T joako
slużbowy? Straszne. To zmienia całkowicie świat motoryzacji.

> (Zresztą ich wybór nie był nieracjonalny,
> ponieważ dla 8051 istnieją działające, sprawdzone narzędzia).

ROFL. Przeciez mówiłem że problem rozwiązać można tylko na drodze
bilogicznej.

Co ciekawe za tego zdania wynika że na pozostałych architekturach co
najmniej mozna mieć wątpliwość w działające i sprawdzone rozwiązania.
Możesz podać przykłady np. tego że ARM jest niedziałający i
niesprawdzony? Że narzedzia popsute? Trzeba czym prędzej dać znać tym
milionom firm na świecie które w tym glupim ARMie klepią kod. Niesprawdzony!

> No, ale co ja tam wiem.

Niewiele jak widać. Jesteś typowy legacy embedded. Posługujesz się
mitami w celu usprawiedliwienia głupich wyborów.

>> 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.

Zdziwisz się jakie rzeczy pisuje się na świecie. W PL również.

>> 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)

Nie. Nie masz pojęcia o C++ i nie rozumiesz dlaczego tego błedu nie da
się popelnic jesli tylko zrezygnujesz z #define i zaczniesz pisać kod
silnie typowany.

>> 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.

Nie. Nie masz pojęcia o ogrniczeniach makr C skoro widzisz jakiekolwiek
analogie.

>> 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)

Nie. Nie masz pojęcia dlaczego tracenie czegokolwiek w imie religijnego
podejścia do C jest złem.

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

Niezupełnie. Do ciebie faktycznie jestem z przyszłości skoro wyjmujesz
40-letnią technologię i machasz nią mówiąz że nic lepszego nie
wymyślono. Sorry, wymyślono. Kwestia pozbycia się ignorancji,
doczytania, kupienia kilku płytek ewaluacyjnych i poczekania aż koledzy
... no wiadomo.