Article View: pl.comp.programming
Article #216744Re: Programming Language of the Year 2019
From: Maciej Sobczak
Date: Tue, 14 Jan 2020 07:45
Date: Tue, 14 Jan 2020 07:45
46 lines
4823 bytes
4823 bytes
[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
Technical Details
Message-ID:
<458090e0-d3af-4b52-9d74-037e2608157c@googlegroups.com>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!feeder.erje.net!2.eu.feeder.erje.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!g89no7150097qtd.0!news-out.google.com!w29ni1070qtc.0!nntp.google.com!g89no7150093qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mailReferences:
<f7543b8e-17ef-4de4-a4ab-ccbc8e683bb3@googlegroups.com> <63880fc0-7a6e-44a1-8c26-a3d1d019efb2@googlegroups.com> <d055f5e8-8eb3-41b4-b903-c996bb7b2503@googlegroups.com> <72160e5d-7727-46e7-b2f0-1567e4bb4ad0@googlegroups.com> <72bb82b7-b6ad-4754-ad52-5b2b7e600e7c@googlegroups.com> <bc16a817-045a-4d11-aa66-4cd1cda6d67b@googlegroups.com>Show Full Headers
Complete Article Headers
X-Received: by 2002:ac8:7a6c:: with SMTP id w12mr2426440qtt.233.1578987928263; Mon, 13 Jan 2020 23:45:28 -0800 (PST) X-Received: by 2002:a37:274a:: with SMTP id n71mr19518652qkn.302.1578987928017; Mon, 13 Jan 2020 23:45:28 -0800 (PST) Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!feeder.erje.net!2.eu.feeder.erje.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!g89no7150097qtd.0!news-out.google.com!w29ni1070qtc.0!nntp.google.com!g89no7150093qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: pl.comp.programming Date: Mon, 13 Jan 2020 23:45:27 -0800 (PST) In-Reply-To: <bc16a817-045a-4d11-aa66-4cd1cda6d67b@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=213.108.152.51; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 213.108.152.51 References: <f7543b8e-17ef-4de4-a4ab-ccbc8e683bb3@googlegroups.com> <63880fc0-7a6e-44a1-8c26-a3d1d019efb2@googlegroups.com> <d055f5e8-8eb3-41b4-b903-c996bb7b2503@googlegroups.com> <72160e5d-7727-46e7-b2f0-1567e4bb4ad0@googlegroups.com> <72bb82b7-b6ad-4754-ad52-5b2b7e600e7c@googlegroups.com> <bc16a817-045a-4d11-aa66-4cd1cda6d67b@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <458090e0-d3af-4b52-9d74-037e2608157c@googlegroups.com> Subject: Re: Programming Language of the Year 2019 From: Maciej Sobczak <see.my.homepage@gmail.com> Injection-Date: Tue, 14 Jan 2020 07:45:28 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit