No i bombki strzelone. Tyle było wymądrzania, że Python, że Rust, że Haskell i że co
tam jeszcze.

https://www.tiobe.com/tiobe-index/

Spoiler: C dostał medal za wstanie z kolan.

Tylko żeby nie było płakania, że TIOBE nie jest miarodajny. Oczywiście, że nie jest.
Ale to, że język, którego miało już nie być a jest jak najbardziej, jest ciekawą
informacją.

Wszystko wina embedów.

--
Maciej Sobczak

do góry

W dniu sobota, 11 stycznia 2020 23:50:00 UTC+1 użytkownik Maciej Sobczak napisał:
> No i bombki strzelone. Tyle było wymądrzania, że Python, że Rust, że Haskell i że
co tam jeszcze.
>
> https://www.tiobe.com/tiobe-index/
>
> Spoiler: C dostał medal za wstanie z kolan.
>
> Tylko żeby nie było płakania, że TIOBE nie jest miarodajny. Oczywiście, że nie
jest. Ale to, że język, którego miało już nie być a jest jak najbardziej, jest
ciekawą informacją.
>
> Wszystko wina embedów.

<troll mode on>
Nie rozumiem. Dlaczego nie C++? Przecież C++ ma więcej ficzerów i jest obiektywnie
lepszy, i nie ma nic, co można zrobić w C, czego nie można by zrobić w C++?

No i przecież C jest już od dawna nierozwijany, a C++ złapał rytm, i co trzy lata są
wprowadzane do standardu nowe ficzery. Dlaczego ktoś w ogóle chciałby korzystać z
tego przestarzałego języka, skoro sięgnięcie po C++ nic go nie kosztuje? Przecież
embedded to teraz głównie ARMy, i GCC dla ARMów obsługuje oczywiście C++.
</troll mode off>

do góry

> <troll mode on>
> Nie rozumiem. Dlaczego nie C++?

Ależ nie ma w tym nic z trollowania. Też nie rozumiem w sensie własnych wyborów,
aczkolwiek potrafię sobie wyobrazić mechanizm, który wpycha ludzi w C. Otóż tym
mechanizmem są obecnie generatory kodu produkujące wstępnie zainicjalizowany projekt
na podstawie konfiguracji peryferiów. Np. (jeśli nie w szczególności) ten:

https://www.st.com/en/development-tools/stm32cubemx.
html

Nie opłaca się tego robić ręcznie a z wizarda wychodzi kod w C. Pozostaje go rozwijać
dalej. Inną metodą rozpoczynania projektu jest wzięcie na żywca jakiegoś przykładu z
zasobów producenta a takie przykłady niemal zawsze są w C.

I tak, jedną metodą lub drugą, wszystkie projekty startują jako C. Rozwijanie ich
przez dopisywanie kodu w C++ wymaga pewnego ogarnięcia, którego w tej branży może
brakować.

Ta teoria ma potwierdzenie również w kategorii desktop, gdzie kod w C++ był masowo
pisany wtedy, gdy projekty były inicjowane z wizardów lub frameworków w C++ (MFC, Qt,
itp.).

Czyli to nie całkiem jest wybór programisty. Producenci narzedzi (a w przypadku
embedów nawet producenci krzemu) mają istotny wpływ na to, jaki język "wybierze"
programista.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu niedziela, 12 stycznia 2020 19:39:19 UTC+1 użytkownik Maciej Sobczak napisał:
> > <troll mode on>
> > Nie rozumiem. Dlaczego nie C++?
>
> Ależ nie ma w tym nic z trollowania.

Pewnie kwestia perspektywy ;]

> Też nie rozumiem w sensie własnych wyborów, aczkolwiek potrafię sobie wyobrazić
mechanizm, który wpycha ludzi w C. Otóż tym mechanizmem są obecnie generatory kodu
produkujące wstępnie zainicjalizowany projekt na podstawie konfiguracji peryferiów.
Np. (jeśli nie w szczególności) ten:
>
> https://www.st.com/en/development-tools/stm32cubemx.
html
>
> Nie opłaca się tego robić ręcznie a z wizarda wychodzi kod w C.

Wręcz bym powiedział, że "gówno-kod w C".
Co jest smutne. Bo o ile pomysł "wykonywalnej dokumentacji" jest jak najbardziej
chwalebny, to - pomijając nawet kwestię samego działania narzędzia, które jest raczej
toporne - wygenerowany kod to jest jakiś koszmarek.

Podobnie jak to, żeby na mikrokontrolery dostarczać "warstwę abstrakcji sprzętowej"
(?).
Tzn. ja bym się raczej spodziewał po opisie takiego narzędzia, że dostanę wysoce
zoptymalizowany kod inicjalizujący, a nie jakąś monstrualną bibliotekę, najeżoną od
funkcji, których celem jest wypełnianie struktur danymi. (Serio, wygląda to tak,
jakby inżynierowe w ST nie rozkminili jeszcze, że w C istnieje składnia do
inicjalizacji struktur. I jakby nie wiedzieli, do czego służy const.)

> Pozostaje go rozwijać dalej.

Moim zdaniem to ma sens do szybkiego uruchomienia/wypróbowania czegoś.
Bo jest kod wygenerowany, który nie ja pisałem, i w którym wprowadzanie zmian jest
bolesne (bo muszę regenerować projekt)

> Inną metodą rozpoczynania projektu jest wzięcie na żywca jakiegoś przykładu z
zasobów producenta a takie przykłady niemal zawsze są w C.

I pewnie C jest do tego wystarczającym językiem.

> I tak, jedną metodą lub drugą, wszystkie projekty startują jako C. Rozwijanie ich
przez dopisywanie kodu w C++ wymaga pewnego ogarnięcia, którego w tej branży może
brakować.
>
> Ta teoria ma potwierdzenie również w kategorii desktop, gdzie kod w C++ był masowo
pisany wtedy, gdy projekty były inicjowane z wizardów lub frameworków w C++ (MFC, Qt,
itp.).
>
> Czyli to nie całkiem jest wybór programisty. Producenci narzedzi (a w przypadku
embedów nawet producenci krzemu) mają istotny wpływ na to, jaki język "wybierze"
programista.

Uwaga bardzo słuszna.

(Czasem sobie myślę, że ST specjalnie rozdmuchuje tego HALa, żeby klienci kupowali
kontrolery z większą ilością flasha na pokładzie.)

do góry

> Co jest smutne. Bo o ile pomysł "wykonywalnej dokumentacji" jest jak najbardziej
chwalebny, to - pomijając nawet kwestię samego działania narzędzia, które jest raczej
toporne - wygenerowany kod to jest jakiś koszmarek.

Tak. Tym bardziej jest to przerażające, jeśli sobie uświadomimy, że zapewne taki kod
steruje nie tylko spłuczką w kiblu, ale też np. dozownikiem lekarstw w szpitalu.

> Podobnie jak to, żeby na mikrokontrolery dostarczać "warstwę abstrakcji sprzętowej"
(?).

To nie jest zły pomysł (ale można go oczywiście źle zrealizować). Jeśli jest cała
rodzina mikrokontrolerów, które np. mają Ethernet, to nie jest złym pomysłem, żeby
ten Ethernet był obsługiwany z grubsza przez takie samo API.
To znakomicie ułatwia producentowi wciśnięcie odbiorcom nowego mikrokontrolera a
tempo tego wciskania jest coraz szybsze. Przecież bez takiego HALa nikt by nigdy nie
kupił nowego układu.

Pytanie 1: co ma dłuższy czas życia? Software czy hardware?
Pytanie 2: jak na poprzednią odpowiedź wpływa rozróżnienie pomiędzy PC i embedy?

> Tzn. ja bym się raczej spodziewał po opisie takiego narzędzia, że dostanę wysoce
zoptymalizowany kod inicjalizujący,

A po co zoptymalizowany? To się wykonuje tylko raz.
Być może chciałbyś mieć błyskawicznie startujący układ, ale oczekiwanie na fizyczny
rozruch peryferiów i tak trwa dłużej, niż wykonanie nawet najbardziej szmacianego
kodu inicjalizującego.

> a nie jakąś monstrualną bibliotekę, najeżoną od funkcji, których celem jest
wypełnianie struktur danymi.

Tu się zgadzam, efekt końcowy powoduje opad kończyn.
Ale wystarczy nie zaglądać do środka, i można pozostać optymistą.

> Moim zdaniem to ma sens do szybkiego uruchomienia/wypróbowania czegoś.

I nawet wtedy jesteś w plecy z robotą, bo ten produkt już jest komuś obiecany albo
wręcz sprzedany.

> Bo jest kod wygenerowany, który nie ja pisałem, i w którym wprowadzanie zmian jest
bolesne (bo muszę regenerować projekt)

Teoretycznie nie musi być bolesne, bo są mechanizmy pozwalające rozgraniczyć kod
generowany od modyfikowanego.

> (Czasem sobie myślę, że ST specjalnie rozdmuchuje tego HALa, żeby klienci kupowali
kontrolery z większą ilością flasha na pokładzie.)

Flash to pikuś. Możesz mieć ile chcesz. Wyścig jest raczej o peryferia. Typowy
mikrokontroler ma więcej funkcjonalnych peryferiów niż nóżek. A skoro ilość nóżek
przestała być ograniczeniem, to wyścig trwa w najlepsze. I po to jest ten HAL, żeby
użytkownik dzisiejszego mikrokontrolera nie miał obaw zamawiając nowy model.

Oczywiście to nadal nie usprawiedliwia wypychania języka C na tron. Ale tak się
właśnie dzieje.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu poniedziałek, 13 stycznia 2020 19:30:20 UTC+1 użytkownik Maciej Sobczak
napisał:
> > Podobnie jak to, żeby na mikrokontrolery dostarczać "warstwę abstrakcji
sprzętowej" (?).
>
> To nie jest zły pomysł (ale można go oczywiście źle zrealizować). Jeśli jest cała
rodzina mikrokontrolerów, które np. mają Ethernet, to nie jest złym pomysłem, żeby
ten Ethernet był obsługiwany z grubsza przez takie samo API.
> To znakomicie ułatwia producentowi wciśnięcie odbiorcom nowego mikrokontrolera a
tempo tego wciskania jest coraz szybsze. Przecież bez takiego HALa nikt by nigdy nie
kupił nowego układu.

No, ale w moim odczuciu lepszym pomysłem byłoby po prostu dbanie o zgodność
niskopoziomowego interfejsu pomiędzy kolejnymi urządzeniami kontrolera.
(A jeżeli miałoby to być niemożliwe, to zastanowienie się, dlaczego ma to być
niemożliwe)

> Pytanie 1: co ma dłuższy czas życia? Software czy hardware?
> Pytanie 2: jak na poprzednią odpowiedź wpływa rozróżnienie pomiędzy PC i embedy?
>
> > Tzn. ja bym się raczej spodziewał po opisie takiego narzędzia, że dostanę wysoce
zoptymalizowany kod inicjalizujący,
>
> A po co zoptymalizowany? To się wykonuje tylko raz.
> Być może chciałbyś mieć błyskawicznie startujący układ, ale oczekiwanie na fizyczny
rozruch peryferiów i tak trwa dłużej, niż wykonanie nawet najbardziej szmacianego
kodu inicjalizującego.

Zoptymalizowany pod dwoma kątami:
- rozmiaru, jaki zajmuje w pamięci stałej
- kolejności inicjalizacji, ze względu na czas inicjalizacji peryferiów (bo producent
wie to lepiej ode mnie)

> > Bo jest kod wygenerowany, który nie ja pisałem, i w którym wprowadzanie zmian
jest bolesne (bo muszę regenerować projekt)
>
> Teoretycznie nie musi być bolesne, bo są mechanizmy pozwalające rozgraniczyć kod
generowany od modyfikowanego.

Jest bolesne.
Fajny pomysł mają goście z Krakowa, język Luna
https://www.luna-lang.org
opiera się o "dualną reprezentację graficzno tekstową". Można sobie przełączać. To
jest lepsze od generowania, bo mamy izomorfizm. Czyli można np. używać tradycyjnych
narzędzi diffujących (o czym sam kiedyś wspominałeś).

W CubeMX nie można (albo ja nie wiem jak). A ich pomysł na rozwój aplikacji (że dają
mi szablony, i ja wciskam swój kod pomiędzy ich komentarze) jest po prostu koszmarny.

> Oczywiście to nadal nie usprawiedliwia wypychania języka C na tron. Ale tak się
właśnie dzieje.

Nie wiem jaki inny język mieliby wcisnąć.

do góry

[HAL]
> No, ale w moim odczuciu lepszym pomysłem byłoby po prostu dbanie o zgodność
niskopoziomowego interfejsu pomiędzy kolejnymi urządzeniami kontrolera.

Niskopoziomowego, czyli co? Adresy rejestrów i układ bitów w środku? To za nisko, bo
na tym poziomie i tak nikt nie chce pracować. Pomrugać LEDem to się jeszcze da na tym
poziomie, ale obsługa jakiegokolwiek interfejsu komunikacyjnego to już wyższa forma
masochizmu. Po prostu nikt normalny tak nie robi.
A cokolwiek powyżej tego poziomu to właśnie HAL.

[kod inicjalizacyjny]
> Zoptymalizowany pod dwoma kątami:
> - rozmiaru, jaki zajmuje w pamięci stałej

A po co? To i tak jest najmniejsza część całości, w skład której zwykle wchodzi jakiś
RTOS, być może też jakiś stos TCP, itd.
Optymalizowanie tego to strata czasu - chociaż, oczywiście, spodziewamy się jakiegoś
minimum rozsądku, np. że ten kod nie będzie zawierał fragmentów odpowiedzialnych za
nieużywane peryferia. Ale właśnie po to jest wizard, żeby taką konfigurowalność
zapewnić.

Mnie bardziej śmieszy fakt, że ten CubeMX wymaga Javy. I w ten sposób, żeby napisać
program liczony w kilobajtach trzeba zainstalować softu liczonego w gigabajtach. To
jest obiektywnie głupie. Konfigurator jądra Linuksa można było kiedyś zrobić kilka
rzędów wielkości taniej a teraz całe dziedzictwo IT z ostatnich 30 lat bierze udział
w konfigurowaniu nóżki w mikrokontrolerze.

> - kolejności inicjalizacji, ze względu na czas inicjalizacji peryferiów (bo
producent wie to lepiej ode mnie)

Zakładamy, że tak jest. Nie widzę powodu, żeby nie było.

> > Teoretycznie nie musi być bolesne, bo są mechanizmy pozwalające rozgraniczyć kod
generowany od modyfikowanego.
>
> Jest bolesne.

Dlaczego?

> Fajny pomysł mają goście z Krakowa, język Luna
> https://www.luna-lang.org
> opiera się o "dualną reprezentację graficzno tekstową". Można sobie przełączać. To
jest lepsze od generowania, bo mamy izomorfizm. Czyli można np. używać tradycyjnych
narzędzi diffujących (o czym sam kiedyś wspominałeś).

Izomorfizm daje np. konfigurator Texas Instruments (bo przecież ST to nie jedyna
firma na rynku). Konfiguracja to tradycyjny plik tekstowy, ale ogląda się to
graficznie (jeśli ktoś chce).

> W CubeMX nie można (albo ja nie wiem jak). A ich pomysł na rozwój aplikacji (że
dają mi szablony, i ja wciskam swój kod pomiędzy ich komentarze) jest po prostu
koszmarny.

To wciskaj tam nie swój kod, tylko jedną linijkę wywołującą właściwy program w innych
plikach. Wtedy nie jest bolesne a poniesione ryzyko to właśnie ta jedna linijka.

> > Oczywiście to nadal nie usprawiedliwia wypychania języka C na tron. Ale tak się
właśnie dzieje.
>
> Nie wiem jaki inny język mieliby wcisnąć.

C++? Przecież całe środowisko Arduino tak działa.
I tak każdy producent ma kompilator C++, więc nie widzę problemu.

Do zastosowań krytycznych te wizardy i tak się nie nadają, więc nie ma się co spinać.
A rozsądny pozdbiór C++ na tym poziomie (powiedzmy bez wyjątków i polimorfizmu) byłby
wystarczająco tani.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On Saturday, January 11, 2020 at 11:50:00 PM UTC+1, Maciej Sobczak wrote:
> [...]
> Wszystko wina embedów.

Nie wiem czy to wina embedów, ja na Atmega8 programowałem w C++:

https://pdf1.alldatasheet.com/datasheet-pdf/view/171
426/ATMEL/ATMEGA8.html

Cytat
[
- 8K Bytes of In-System Self-Programmable Flash
- 512 Bytes EEPROM
- 1K Byte Internal SRAM
]

Pozdrawiam

do góry

> Wadą TIOBE jest rozdzielanie C/C++/C# - choć należałoby sumować
> ich popularność jako dialektów jednego języka.

Oj, nie wiem. Związek między C i C# jest taki jak między polskim i łacińskim. Na oko
wygląda podobnie, nawet niektóre wyrazy da się użyć tu i tam.

C i C++ mają do siebie bliżej, z racji współdzielonych narzędzi i platform
docelowych. Ale C#? Nie, to jest odrębny język.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On Friday, January 24, 2020 at 8:19:44 AM UTC+1, Maciej Sobczak wrote:
> > Wadą TIOBE jest rozdzielanie C/C++/C# - choć należałoby sumować
> > ich popularność jako dialektów jednego języka.
>
> Oj, nie wiem. Związek między C i C# jest taki jak między polskim i łacińskim. Na
oko wygląda podobnie, nawet niektóre wyrazy da się użyć tu i tam.
>
> C i C++ mają do siebie bliżej, z racji współdzielonych narzędzi i platform
docelowych. Ale C#? Nie, to jest odrębny język.

C i C++ to też dwa zupełnie odrębne języki. Chyba, że łączymy języki wg pierwszej
literki, to wpadnie też Cobol, Closure czy Clean. :)

w.

do góry