eGospodarka.pl
bezpłatny program PIT 2019

eGospodarka.plGrupypl.comp.programming › Programming Language of the Year 2019
Ilość wypowiedzi w tym wątku: 8

  • 1. Data: 2020-01-11 23:49:59
    Temat: Programming Language of the Year 2019
    Od: Maciej Sobczak <s...@g...com>

    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


  • 2. Data: 2020-01-12 01:35:34
    Temat: Re: Programming Language of the Year 2019
    Od: g...@g...com

    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>


  • 3. Data: 2020-01-12 19:39:18
    Temat: Re: Programming Language of the Year 2019
    Od: Maciej Sobczak <s...@g...com>

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


  • 4. Data: 2020-01-12 21:23:51
    Temat: Re: Programming Language of the Year 2019
    Od: g...@g...com

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


  • 5. Data: 2020-01-13 19:30:18
    Temat: Re: Programming Language of the Year 2019
    Od: Maciej Sobczak <s...@g...com>

    > 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


  • 6. Data: 2020-01-13 22:27:40
    Temat: Re: Programming Language of the Year 2019
    Od: g...@g...com

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


  • 7. Data: 2020-01-14 08:45:27
    Temat: Re: Programming Language of the Year 2019
    Od: Maciej Sobczak <s...@g...com>

    [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


  • 8. Data: 2020-01-14 21:28:32
    Temat: Re: Programming Language of the Year 2019
    Od: "M.M." <m...@g...com>

    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

strony : [ 1 ]



Szukaj w grupach

bezpłatny program PIT 2019

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: