On Mon, 7 Aug 2017 13:04:17 +0200, Borneq <b...@a...hidden.pl>
wrote:
> nie było błędów czasu kompilacji. Ale to dobrze, bo w Rust więcej
niż w
> innych językach zależy od kompilacji, aby nie było gorszych błędów
czasu
> wykonania.


Nie wiem czemu, ale od lat 60-tych ta złota myśl powraca... i okazuje
się że ludzie generalnie wolą mniej bezpieczeństwa a więcej
kreatywności.

Na przykład: pliki BAT w ekosystemie MS. Toż to skrypty nijak nie
kompilowane. Powinno tego nie być. Przecież gdy powstawał DOS to
Pascal był już dojrzałym językiem. A jednak wygrało wyjątkowe
niechlujstwo.

Albo ECMA Script. Typowanie to jeszcze nie największa tragedia.
Gorzej jest, bo zmienne niezadeklarowane mogą przypadkiem być takie
jak globalne i wtedy robi się totalnie kuku. A jednak trudno upierać
się że Javascript jest niepopularny and/or nielubiany.

Z drugiej strony Ada. Szalenie popularna nie jest.

do góry

> Do tego problem braku new w embeded.

Jak mógłbyś, to rozwiń to.

do góry

On Mon, 7 Aug 2017 07:28:34 -0700 (PDT), s...@g...com wrote:
> > Do tego problem braku new w embeded.
> Jak mógłbyś, to rozwiń to.

Ok, rozwijam.

W programowaniu mikrokontrolerów, takich jak PIC czy ARM, nie używa
się new/delete. Albo dlatego że się nie da ("zapomniano
zaimplementować"), albo dlatego że się nie powinno (bo szkodzi).
Czyli jest sobie C++, tyle że rozsądnie używać tego bez sterty.
Dlaczego tak? Bo fragmentacja pamięci plus brak systemu operacyjnego.
Do tego całego RAM może być i 64 bajty...

Czy inny język dałby sobie radę lepiej? To bardzo ciekawe pytanie. W
zasadzie nie ma nic lepszego niż C jak na razie. Choć gdzieś tam
wypełza Python, jakaś Lua na horyzoncie, nawet Javascript i
oczywiście Java. Ale to na takie trochę większe.

do góry

W dniu 07.08.2017 o 22:42, slawek pisze:
> W programowaniu mikrokontrolerów, takich jak PIC czy ARM, nie używa się
> new/delete. Albo dlatego że się nie da ("zapomniano zaimplementować"),

W programowaniu mikrokontrolerów najlepszy będzie C. Ale w PC Tust ma
szansę nawet zastąpić C/C++. Jest lekki w tym sensie że kompiluje do
execa/binarki bez potrzeby instalowania środowiska komputera
wirtualnego. Do tego nie ma garbage collectora, ale własny sposób
radzenia sobie z wyciekami, to co zdawało się niemożliwe.
A w czym jest lepszy? Pod Windows często szukałem skompilowanych już
execów, bo była trudność skompilowania ze źródeł. Takie standardowe
źródła C zawierały kompilację z cmake, pliki .am, .sh. Pod Linuxem
dawało się to skompilować według readme, zależności doinstalować za
pomocą sudo apt-get install, ale w Windows klapa.
Tutaj chciałem program Racer, ściągnąłem paczkę źródeł z gihuba i
skompilowałem, dociągnął wszystkie zależności w tych wersjach które
potrzebował.

do góry

On Tue, 8 Aug 2017 07:46:08 +0200, Borneq <b...@a...hidden.pl>
wrote:
> W programowaniu mikrokontrolerów najlepszy będzie C.

A niby dlaczego?

do góry

W dniu 2017-08-07 o 22:42, slawek pisze:
> On Mon, 7 Aug 2017 07:28:34 -0700 (PDT), s...@g...com wrote:
>> > Do tego problem braku new w embeded.
>> Jak mógłbyś, to rozwiń to.
>
> Ok, rozwijam.
>
> W programowaniu mikrokontrolerów, takich jak PIC czy ARM, nie używa się
> new/delete. Albo dlatego że się nie da ("zapomniano zaimplementować"),
> albo dlatego że się nie powinno (bo szkodzi). Czyli jest sobie C++, tyle
> że rozsądnie używać tego bez sterty. Dlaczego tak? Bo fragmentacja
> pamięci plus brak systemu operacyjnego. Do tego całego RAM może być i 64
> bajty...
>
> Czy inny język dałby sobie radę lepiej? To bardzo ciekawe pytanie. W
> zasadzie nie ma nic lepszego niż C jak na razie. Choć gdzieś tam wypełza
> Python, jakaś Lua na horyzoncie, nawet Javascript i oczywiście Java. Ale
> to na takie trochę większe.

Używa się, używa... tylko, że samemu trzeba sobie obsługę heapa
oprogramować. Nie taka znowu wielka sztuka.
Wiem co mówię - sam to własnymi ręcami to robiłem.

--
pzdr,
Z.

Zwiedzaj Kraków: http://www.przewodnik-miejski.krakow.pl

do góry

On Monday, August 7, 2017 at 2:43:12 PM UTC+2, slawek wrote:
> On Sun, 6 Aug 2017 03:03:45 -0700 (PDT), "M.M." <m...@g...com>
> wrote:
> > ź sobie język taki
> > jak C++ który jest interpretowany?
>
> Ajtam, da się zrobić interpreter C. Był taki na Commodore 64.

Nie chodzi o to że się nie da, tylko jaki sens? Język interpretowany
bez możliwości wywołania funkcji po nazwie i z arytmetyką wskaźników? :D

Pozdrawiam

do góry

On Tue, 8 Aug 2017 11:41:07 +0200, Zenon Oktawiec <z...@s...com.pl>
wrote:
> Używa się, używa... tylko, że samemu trzeba sobie obsługę heapa
> oprogramować. Nie taka znowu wielka sztuka.
> Wiem co mówię - sam to własnymi ręcami to robiłem.


Oczywiście że nie sztuka i wszędzie pełno gotowców.

Tyle że mądrzy ludzie nie uzywają new/malloc/calloc, ani nawet
alloca. Segmentacja pamięci. A techniki jej unikania są, tyle że nie
opłaca się ich używać, prościej zrobić to inaczej, bez sterty.

do góry

On Tue, 8 Aug 2017 02:48:03 -0700 (PDT), "M.M." <m...@g...com>
wrote:
> Nie chodzi o to że się nie da, tylko jaki sens?

A to już pytanie filozoficzne.

do góry

W dniu 2017-08-08 o 14:14, slawek pisze:
...
> Tyle że mądrzy ludzie nie uzywają new/malloc/calloc, ani nawet alloca.
> Segmentacja pamięci. A techniki jej unikania są, tyle że nie opłaca się
> ich używać, prościej zrobić to inaczej, bez sterty.


Nie zawsze się da - zależy od wymagań.


--
pzdr,
Z.

Zwiedzaj Kraków: http://www.przewodnik-miejski.krakow.pl

do góry