W dniu niedziela, 23 października 2016 11:22:27 UTC+2 użytkownik Sebastian Biały
napisał:
> > 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.

Jakiego Bieleckiego? W Pascalu ostatni raz programowałem 15 lat temu.
(A obecnie najchętniej programuję w języku, który jest jego równolatkiem)

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

Owszem. I raczej nie chodzi to na armach. Texas Instruments
np. daje swój kompilator do mspków. I ogólniej, łatwiej stworzyć
autorski kompilator C, niż C++.

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

Nie o to chodzi. Jeżeli chcesz korzystać z ich protokołu komunikacyjnego
(który jest dość popularnym standardem), musisz używać ich czipów.
A wtedy możesz oczywiście dodawać swojego czipa, który komunikuje
się z ich czipem po uarcie, albo -- jeżeli logika jest prosta i zmieści
się w dostepnej pamięci -- możesz zmodyfikować program dostarczony
przez nich. A przy milionie wyprodukowanych sztuk Twoje ćwierć
dolara to będzie ćwierć miliona dolarów. No niestety, taki biznes.

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

Nie. ARM byłby w tym przypadku overkillem.
Ogólnie ARM to jest bardzo dobra architektura, ale nie nadaje
się do wszystkiego -- w niektórych zastosowaniach jest zbyt
kosztowna albo zbyt prądożerna.

> > No, ale co ja tam wiem.
>
> Niewiele jak widać. Jesteś typowy legacy embedded. Posługujesz się
> mitami w celu usprawiedliwienia głupich wyborów.

Z całym szacunkiem, ale ton, w jakim się do mnie odnosisz, jest
obraźliwy, a Twoje stwierdzenie całkowicie niemerytoryczne.
Żeby określić, że jakiś wybór jest "głupi", trzeba mieć nieco
większą wiedzę odnośnie okoliczności, w jakich był dokonywany.

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

Ależ rozumiem. Zazwyczaj jeżeli widzę define'y tam, gdzie
mogłyby być użyte enumy, szukam tego, który to zrobił.
Zasmuca mnie to, że pola bitowe w C są tak źle obsługiwane
(i rzeczywiście w C++ można to z pewnością zrobić lepiej)

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

A może to Ty nie masz pomysłu na to, jak użyć makr dla osiągnięcia tego celu?
Na przykład, mam takie makra w kodzie w C (nie-embedded):
https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/src/video.h?at=default&
fileviewer=file-view-default#video.h-16

i jeżeli chcę sobie użyć zasobu, nie martwiąc się o jego dealokację,
robię to w taki sposób:
https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/src/image.c?at=default&
fileviewer=file-view-default#image.c-573

ten sam cel jest osiągnięty. Czy coś pominąłem?

> >> c) Templatey. Pozawalajązpisać 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.

Raczej mam wrażenie, że to Ty masz religijne podejście do C++.
Ja po prostu mam świadomość, że kompilatory C++ nie są dostępne
na wielu systemach, z którymi jest mi dane pracować, i wiem,
że to się nie zmieni.

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

Cały czas mam wrażenie, że przypisujesz mi rzeczy, których
nie powiedziałem.
Ja mówię tylko tyle, że środki należy dobierać do celów.

A co do Twojego argumentu z biologii, to spodziewam się, że
pierwotniaki wyginą jako ostatnie.