On 22/09/2019 22:20, J-23 wrote:
>> Wszystkie języki imperatywne sa bardzo podobne. Czy to C czy to
>> Pascal, jeden H. Po co więc wyciągać trupa i pudorwać.
> Ty Patrzysz na Pascala w obecnym kształcie a ja mówie o jego rozwoju
> stąd ta różnica

Jak rozwija się stary jezyk imperatywny możesz zobaczyć na przykładzie
C++. Nie wiem czy to jest specjalnie interesująca wizja.

>> Bo są też zapewne koszmarnie łatwe w skalowaniu albo, co może nawet
>> bardziej prawdopodobne, pisane przez imbecyli. Nie zmienia to jednak
>> faktu że co najmniej kilka bardzo responsywnych aplikacji w Javie
>> miałem okazję używać. Często powody "powolności" Javy sa zupełnie inne
>> niż można przypuszczać.
> Podam dwa:
> KSIP - Krajowy System Informacji Policji
> SWD - System Wspomagania Dowodzenia
> Oba są pisane przez Oracle a oni Jave "raczej" znają :P

Być może poświęcili responsywnośc i zyskali coś innego jak skalowalność,
bezpieczeństwo czy cokolwiek innego. Ponadto może nie przesadzajmy też
że Oracle ma hiper programistów. Nie ma, tak samo jak MS, tak samo jak
Apple itd itp.

>>> Ale czy go wykonasz tak szybko jak w środowiskach RAD?
>> Przeciez RAD istnieją też w C++.
>>> Nie
>> Tak. Ojej, przeciez jest Builder.
> Popraw mnie oba pisane o ile dobrze pamiętam przez Embarcadero. W
> Builder pisałem mało ale jak to wygląda tak samo jak Delphi w sensie
> bugów to ja wole np CodeBlocks

Narzekasz że nie ma RADów w C++ a tu proszę.

Co do bugów to Buildera od razu złapałem na popsutych kontenerach std::,
głupie i trywialne wycieki albo problemy z szablonami. Co jednak nijak
nie zmienia faktu że jest RAD w C++. Pomijam, że z punktu widzenia
inżynierii programowania RAD to obecnie nie jest zaleta, no może w
malutkich firemkach robiących jakieś duperelowate programy do obsługi aptek.

>> Nie, niektóre języki współczesne stawiają na garbage collecting. Nie
>> dlatego że to jest wydajniejsze, tylko dlatego że poświęca się runtime
>> i zyskuje w dev time. Lepszy komputer jest tańszy niż szybszy developer.
> I ja nie miał bym nic przeciwko zaprojektować coś takiego w Pascalu
> tylko że jeszcze lepiej :P

Po co. Jest C# i Java.

> Spróbuj np na przeglądarke napisać np aplikacje do montażu filmow i
> zobaczysz co będzie szybsze. Język dowolny.

Spróbuj to zrobić w Delphi. Myslę że pierwsze co będziesz szukał w necie
to jak wrapować API ffmpeg do głupiego Pascala. I zapewniam, znajdzie
się jakiś miszczu w necie który to już zrobił. W zasadzie znajdzie się
ich kilku i każdy zrobił to inaczej i u każdego działą tylko połowa.
Wiem bo takie problemy ludzie piszący zawodowo w Delphi mają.

> Tylko nie chodzi mi o przetwarzanie gdzieś po za przeglądarką i
> wywalenie wyniku w przeglądarce. Chodzi mi o pełną konwersje i zastanów
> sie dlaczego jeszcze takie cos nie powstało

Ja się nie muszę zastanawiać, tylko sam mówisz że Delhip to db i świata
poza tym nie ma. No więc Delphi da się w 100% takich zastosowań zamienić
na JS+server side. Prawdopodobnie studentami na praktykach.

> A to ciekawe Django da się bez przęglądarki :P? JS też :P?

Chodzi o to że przeglądarka jest obecnie zawsze jakaś dostepna. To nie
lata 90. Możesz zakładać że ją masz, podobnie jak pisząc w Delphi
zakładasz że user ma CPU.

> Zaczynam sie dowiadywać "cudów na kiju"

Raczej wymyślać co nie zostało powiedziane.

do góry

On 23/09/2019 11:58, J-23 wrote:
> Bo ja nie widzę problemu by z
> języka imperatywnego zmienić go w coś nowego co będzie pasowało do
> obecnych standardów

Ludzkość jednak widzi pewne drobne przeszkody w zamianie języka
imperatywnego na coś innego (na co? funkcyjny, deklaratywny, logiczny,
mieszany?). Takie drobne "duperele składniowe". Nie przejmowałbym się
tym, można iść na całego i dodać do Delphi możliwość interpretacji
innych języków w komentarzach np.

Tacy kolesie z np. Veriloga mieli właśnie takie poczucie humoru żeby
zmieścić kilka składni w jednej. Kto bogatemu zabroni?

Świelana przyszłość :D

Jakie szczęście że to już wymiera.

do góry

On 25/09/2019 09:16, slawek wrote:
>> Wychodzi na to że faktycznie Pascal był pierwszy a BCPL to po prostu historia z
innego wymiaru.
> Ale wiesz że Algol i BCPL to trochę różne są?

Ba, a słyszałeś że Kangury to nie to samo co spinacze biurowe?

Jakie pytanie nie na temat taka dygresja.

do góry

heby <h...@p...onet.pl> wrote:
>
> - Panie Mareczku, trzeba program napisa?, na wczoraj. Co tam si?
> ostatnio u?ywa?o do pisania?
>
> - Yyyyy, znaczy tego, Pascala chyba. Turbo. Bo najlepszy.
>
> - No, to Pascala i jedziemy. To na jakiego? ARMa jest, taki sterownik
> czy co?, tak ?e Panie Mareczku, wierz? w Pana.
>
> Nie, to nie bajka, tylko autentyczny dialog zas?yszany w jednej ze
> sporych firm kt?ra w?asnie dzielnie stara?a si? wkroczy? na rynek
> sterownik?w kot??w.
>
> Szcz??liwie cz?ek kt?ry to us?ysza?, zareagowa?. Rok jaki? mo?e ko?o
> 2010. Ca?e szcz?scie to tylko anegdota. Wybrali C bez plus?w pono?. Bo
> plusy s? z?e a ponadto Mareczek co? tam pisa? na studiach.

Pan Mareczek pewnie nie wiedzial co mowi. Ale mam wrazenie ze
ty tez nie wiesz co piszesz. Jest pare sposobow zeby kod
Turbo Pascala przekompilowac na ARM-a. A Pascal bywal preferowany
w stosunku do C systemach wbudowanych. Dlaczego? Dosc powszechne
jest przekonanie ze Pascal jest mniej blednogenny niz C, czyli
po prostu ze latwej jest napisac _poprawny_ program w Pascalu
niz w C. A w przypadku sterownika kotla poprawnosc jest
kluczowa...

--
Waldek Hebisch

do góry

> Dosc powszechne
> jest przekonanie ze Pascal jest mniej blednogenny niz C, czyli
> po prostu ze latwej jest napisac _poprawny_ program w Pascalu
> niz w C. A w przypadku sterownika kotla poprawnosc jest
> kluczowa...

Tam, gdzie poprawność jest kluczowa, nie polega się na powszechnym przekonaniu o
mniejszej błędogenności jakiegoś języka. Procesy weryfikacyjne są zwykle bardziej
rozbudowane (powiedzmy w stosunku 10:1), niż proces kodowania. W tym kontekście wybór
Pascala nie ma wielkiego uzasadnienia, zwłaszcza jeśli z tym wyborem wiąże się użycie
wymierającego kompilatora albo znikającego z rynku producenta.

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

do góry

On 26/09/2019 02:06, a...@m...uni.wroc.pl wrote:
> Pan Mareczek pewnie nie wiedzial co mowi. Ale mam wrazenie ze
> ty tez nie wiesz co piszesz. Jest pare sposobow zeby kod
> Turbo Pascala przekompilowac na ARM-a.

Niemożliwe! A Brainfucka też się da? To czemu nie jest równiez brany pod
uwagę? Tak on śliczny, amerykański!

> A Pascal bywal preferowany
> w stosunku do C systemach wbudowanych.

Bywał? Co najmniej od lat 80 nie pamiętam grama Pascala na systemach
wbudowanych choć oczywiscie nie widziałem *wszystkich* systemów
wbudowanych i niewątpliwie z zachodnim Texasie na sterownikach automatów
do Coli mógł taki faktycznie banglać. Obecnie, jesli jest, to ma pewnie
udział w rynku na poziomie szumu kwantowego.

Bywał preferowany ... no cóż może i ktoś tam preferował, wiec
twierdzenie akademicko rozgrzeszam.

> Dlaczego?

No własnie, dlaczego?

> Dosc powszechne
> jest przekonanie ze Pascal jest mniej blednogenny niz C, czyli
> po prostu ze latwej jest napisac _poprawny_ program w Pascalu
> niz w C.

No tak, to przeciez ZUPEŁNIE inny język, jak się napisze := zamiast =.
Natychmiast poprawia to wszelakie bugi, generuje kod magicznie
działający i krowy dają więcej mleka.

Zawsze mnie zastanawiało skąd ten pogląd o lepszości składni pascala nad
c. W sumie to identyczne języki, może więc wchodzi w rachubę jakaś magia
albo inna religia.

> A w przypadku sterownika kotla poprawnosc jest
> kluczowa...

Na szczęscie od dziesięcioleci potrafimy badać poprawnośc kodu innymi
metodami niż intensywnie gapienie się Panów Mareczków w kod.

do góry

Maciej Sobczak <s...@g...com> wrote:
> > Dosc powszechne
> > jest przekonanie ze Pascal jest mniej blednogenny niz C, czyli
> > po prostu ze latwej jest napisac _poprawny_ program w Pascalu
> > niz w C. A w przypadku sterownika kotla poprawnosc jest
> > kluczowa...
>
> Tam, gdzie poprawno?? jest kluczowa, nie polega si? na powszechnym przekonaniu o
mniejszej b??dogenno?ci jakiego? j?zyka. Procesy weryfikacyjne s? zwykle bardziej
rozbudowane (powiedzmy w stosunku 10:1), ni? proces kodowania. W tym kontek?cie wyb?r
Pascala nie ma wielkiego uzasadnienia, zw?aszcza je?li z tym wyborem wi??e si? u?ycie
wymieraj?cego kompilatora albo znikaj?cego z rynku producenta.

Wycieles kontekst tak ze nie widac o co mi chodzi. Glowna sprawa
to ze trzeba myslec i uwzgledniac potrzeby, a nie opierac sie
na niewiele mowiacych tabelkach popularnosci. Co do weryfikacji:
rozdzielanie kodowania i weryfikacji jest pod wieloma wzgledami
sztuczne. Po prostu zle napisany program nie da sie zweryfikowac:
solidna weryfikacja da wynik ze program jest bledny. Mozna
dyskutowac jak bardzo jezyk wplywa na koszt (i czas) otrzymania
zweryfikowanego programu. Byc moze masz jakies solidne dane
wskazujace na to ze jezyk jest nieistotny. Jak na razie ja
mysle ze jezyk jest istotny (choc argumenty bylyby dlugie
i moglbys sie z nimi nie zgodzic).

Co do Pascala: rozpatujac jezyk w izolacji C jest jednym
z najgorszych jezykow do programowania wbudowanego i
w szczegolnosci Pascal jest lepszy. Jak sie patrzy na
calosc to wchodzi wiele innych rzeczy i C ma duze szanse
wygrac. Ale wybor (C czy inny jezyk) powinien byc
swiadomy zas bezmyslne wycinanie innych kandydatow
moze (nie musi) oznaczac utrate okazji by zrobic cos lepiej
niz konkurencja.

--
Waldek Hebisch

do góry

heby <h...@p...onet.pl> wrote:
> On 26/09/2019 02:06, a...@m...uni.wroc.pl wrote:
> > Pan Mareczek pewnie nie wiedzial co mowi. Ale mam wrazenie ze
> > ty tez nie wiesz co piszesz. Jest pare sposobow zeby kod
> > Turbo Pascala przekompilowac na ARM-a.
>
> Niemo?liwe! A Brainfucka te? si? da? To czemu nie jest r?wniez brany pod
> uwag?? Tak on ?liczny, ameryka?ski!

OK, dziekuje za potwierdzenie: nie wiesz (albo cie nie obchodzi)
co piszesz.

> > A Pascal bywal preferowany
> > w stosunku do C systemach wbudowanych.
>
> Bywa?? Co najmniej od lat 80 nie pami?tam grama Pascala na systemach
> wbudowanych cho? oczywiscie nie widzia?em *wszystkich* system?w
> wbudowanych i niew?tpliwie z zachodnim Texasie na sterownikach automat?w
> do Coli m?g? taki faktycznie bangla?. Obecnie, jesli jest, to ma pewnie
> udzia? w rynku na poziomie szumu kwantowego.

To ze czegos nie widziales nie znaczy ze tego nie ma. Z tego
co mi wiadomo wiekszosc kodu wbudowango wytworcy traktuja jako
sekret. Ja kodu w Pascalu nie widzialem, ale dotarlo do mnie
pare w miare wiarygodnych informacji ze takowy byl rozwijany
po roku 2000. Udzial w rynku sam w sobie jest malo istotny.
Istotne jest czy rozwiazanie w konkretnym przypadu dziala
i co mozna dzieki niemu zyskac.

>
> > Dlaczego?
>
> No w?asnie, dlaczego?
>
> > Dosc powszechne
> > jest przekonanie ze Pascal jest mniej blednogenny niz C, czyli
> > po prostu ze latwej jest napisac _poprawny_ program w Pascalu
> > niz w C.
>
> No tak, to przeciez ZUPE?NIE inny j?zyk, jak si? napisze := zamiast =.
> Natychmiast poprawia to wszelakie bugi, generuje kod magicznie
> dzia?aj?cy i krowy daj? wi?cej mleka.
>
> Zawsze mnie zastanawia?o sk?d ten pogl?d o lepszo?ci sk?adni pascala nad
> c. W sumie to identyczne j?zyki, mo?e wi?c wchodzi w rachub? jaka? magia
> albo inna religia.


Dosc powazne studium bledow w programach w C stwierdzilo ze
ok 25% bledow wykrytych po oddaniu programu to bylo bledne uzycie
=, kiedy mialo byc == (przy tym studium dotyczylo starannie napisanych
programow, z w miare niska srednia iloscia bledow). W Pascalu
bardzo trudno zrobic taki blad. Ale skladnia to tylko kawalek,
semantyka C bazuje na operatorze adresu i arytmetyce wskaznikowej.
Prawie kazdy inny jezyk jawnie uzywa tablice. Jest tez sprawa
sprawdzania typow, Pascal to traktuje powazniej.

--
Waldek Hebisch

do góry

On 27/09/2019 15:49, a...@m...uni.wroc.pl wrote:
>>> Pan Mareczek pewnie nie wiedzial co mowi. Ale mam wrazenie ze
>>> ty tez nie wiesz co piszesz. Jest pare sposobow zeby kod
>>> Turbo Pascala przekompilowac na ARM-a.
>> Niemo?liwe! A Brainfucka te? si? da? To czemu nie jest r?wniez brany pod
>> uwag?? Tak on ?liczny, ameryka?ski!
> OK, dziekuje za potwierdzenie: nie wiesz (albo cie nie obchodzi)
> co piszesz.

Wręcz przeciwnie. Wiem doskonale. Z faktu że można skompilować pascala
na ARMa NIE WYNIKA że to jest sensowne i użyteczne. Nic z tego nie
wynika poza hobby.

>> Bywa?? Co najmniej od lat 80 nie pami?tam grama Pascala na systemach
>> wbudowanych cho? oczywiscie nie widzia?em *wszystkich* system?w
>> wbudowanych i niew?tpliwie z zachodnim Texasie na sterownikach automat?w
>> do Coli m?g? taki faktycznie bangla?. Obecnie, jesli jest, to ma pewnie
>> udzia? w rynku na poziomie szumu kwantowego.
> To ze czegos nie widziales nie znaczy ze tego nie ma.

Ależ oczywiście, akademicko patrząc masz rację.

> Z tego
> co mi wiadomo wiekszosc kodu wbudowango wytworcy traktuja jako
> sekret.

No, sam kiedyś widziałem jak jeden kontroler miał kłódkę a nowu w innym
komentarze były w bułgarskim. Fakt, traktują jak sekret. Nikt nie wie w
czym się pisze w embedded. Nikt. Strasznie patrzeć na tych wszystkich
programistów embedded których poznałem, albo lobotomia, albo
elektrowstrząsy. Nikt nie wie w czym pisał, albo bezczelnie kłamie że w
C/C++ albo czasem asm. Trafił sie nawet jeden fantasta że w Adzie, ale
wiadomo że w Pascalu pisali. Ale pssst, to sekret.

> Ja kodu w Pascalu nie widzialem, ale dotarlo do mnie
> pare w miare wiarygodnych informacji ze takowy byl rozwijany
> po roku 2000.

Z tego że nie widziałeś nie wynika że jest.

To że ktoś pisał miganie diodą po 2000 roku w Pascalu niewiele też
wynika. Niektórzy pisali miganie diodą w Pythonie na uC. Też nic z tego
nie wynika poza kilkoma religijnymi maniakami twierdzącymi że teraz to
juz z górki.

> Udzial w rynku sam w sobie jest malo istotny.
> Istotne jest czy rozwiazanie w konkretnym przypadu dziala
> i co mozna dzieki niemu zyskac.

No własnie. Skupmy się na tym. Co można zyskać z Pascala na uC czego nie
można zyskać z C/C++ na uC?

A na marginesie udziału w rynku: ja też uważam że brainfuck powinien być
brany pod uwagę, tym bardziej że ma 0 procent udziału w rynku embedded,
więc musi być dobry.

> Dosc powazne studium bledow w programach w C stwierdzilo ze
> ok 25% bledow wykrytych po oddaniu programu to bylo bledne uzycie
> =, kiedy mialo byc == (przy tym studium dotyczylo starannie napisanych
> programow, z w miare niska srednia iloscia bledow).

Serio? I to studium nie zauważyło metod zarządzania jakością w kodzie po
latach 60tych? Skupili się na nieistotnym elemencie języka który od
całej wieczności generuje ostrzeżenia w kompilatorach i który co
najmniej od 20 lat nie stanowi żadnego argumentu? Sprawdziłeś czy ta
książka jest po naszej erze? biory biblitek akademickich bywają czasem
mocno przykurzone.

> W Pascalu
> bardzo trudno zrobic taki blad.

Wiadomo. Dlatego lepszy. I dlatego nikt go nie stosuje. Spisek, Panie.

> Ale skladnia to tylko kawalek,
> semantyka C bazuje na operatorze adresu i arytmetyce wskaznikowej.

Zupełnie jak Pascal. Chyba że znasz w Pascalu jakieś magiczne sztuczki
operowania na rejestrach peryferiów, manipulowania pamięcia w sterowniku
LCD, wypełnianiu bufora dla DMA, czyli codzienność w uC.

> Prawie kazdy inny jezyk jawnie uzywa tablice.

Dawaj, zademonstruj jak wypełnić bufor w DMA pod konkretnym adresem w
pamiecu uC BEZ używania semantyki adresowej, najlepiej bez adresu. Żeby
magicznie było.

Ciekawe że mogę sobie napisać sementykę tablic w C++ działającą pod
spodem na raw memory. Ale wiadomo, C++ jest niekoszerny. Pascal ino
jest. Najlepiej Turbo.

> Jest tez sprawa
> sprawdzania typow, Pascal to traktuje powazniej.

Zabawne bo C++ też. To gdzie ta zaleta nad C/C++ która powoduje że mam
go traktować serio?

Podpowiem tylko na marginesie: jeśli chcesz język koszerny do embedded,
który ma co najmniej jakąs zaletę nad C/C++ to obecnie uważa się za taki
Adę. Nie żeby to była prawda bo już coś tam pierdykło spektakularnie z
powodu debilizmu programistów, ale mimo to koszerne to jest, ludzie
lubią jak porządne języki robią porządne fajerwerki. Plebs pisuje w C z
Misra-C a jak wie co robi to bez Misra. Troche się miga diodami w C/C++.
W Toyocie piszą zmiennymi globalnymi w języku ciężko rozpoznawalnym. Tyle.

do góry

On Friday, September 27, 2019 at 1:36:36 PM UTC-4, heby wrote:
> On 27/09/2019 15:49, a...@m...uni.wroc.pl wrote:
> >>> Pan Mareczek pewnie nie wiedzial co mowi. Ale mam wrazenie ze
> >>> ty tez nie wiesz co piszesz. Jest pare sposobow zeby kod
> >>> Turbo Pascala przekompilowac na ARM-a.
> >> Niemo?liwe! A Brainfucka te? si? da? To czemu nie jest r?wniez brany pod
> >> uwag?? Tak on ?liczny, ameryka?ski!
> > OK, dziekuje za potwierdzenie: nie wiesz (albo cie nie obchodzi)
> > co piszesz.
>
> Wręcz przeciwnie. Wiem doskonale. Z faktu że można skompilować pascala
> na ARMa NIE WYNIKA że to jest sensowne i użyteczne. Nic z tego nie
> wynika poza hobby.
>
> >> Bywa?? Co najmniej od lat 80 nie pami?tam grama Pascala na systemach
> >> wbudowanych cho? oczywiscie nie widzia?em *wszystkich* system?w
> >> wbudowanych i niew?tpliwie z zachodnim Texasie na sterownikach automat?w
> >> do Coli m?g? taki faktycznie bangla?. Obecnie, jesli jest, to ma pewnie
> >> udzia? w rynku na poziomie szumu kwantowego.
> > To ze czegos nie widziales nie znaczy ze tego nie ma.
>
> Ależ oczywiście, akademicko patrząc masz rację.
>
> > Z tego
> > co mi wiadomo wiekszosc kodu wbudowango wytworcy traktuja jako
> > sekret.
>
> No, sam kiedyś widziałem jak jeden kontroler miał kłódkę a nowu w innym
> komentarze były w bułgarskim. Fakt, traktują jak sekret. Nikt nie wie w
> czym się pisze w embedded. Nikt. Strasznie patrzeć na tych wszystkich
> programistów embedded których poznałem, albo lobotomia, albo
> elektrowstrząsy. Nikt nie wie w czym pisał, albo bezczelnie kłamie że w
> C/C++ albo czasem asm. Trafił sie nawet jeden fantasta że w Adzie, ale
> wiadomo że w Pascalu pisali. Ale pssst, to sekret.
>
> > Ja kodu w Pascalu nie widzialem, ale dotarlo do mnie
> > pare w miare wiarygodnych informacji ze takowy byl rozwijany
> > po roku 2000.
>
> Z tego że nie widziałeś nie wynika że jest.
>
> To że ktoś pisał miganie diodą po 2000 roku w Pascalu niewiele też
> wynika. Niektórzy pisali miganie diodą w Pythonie na uC. Też nic z tego
> nie wynika poza kilkoma religijnymi maniakami twierdzącymi że teraz to
> juz z górki.
>
> > Udzial w rynku sam w sobie jest malo istotny.
> > Istotne jest czy rozwiazanie w konkretnym przypadu dziala
> > i co mozna dzieki niemu zyskac.
>
> No własnie. Skupmy się na tym. Co można zyskać z Pascala na uC czego nie
> można zyskać z C/C++ na uC?
>
> A na marginesie udziału w rynku: ja też uważam że brainfuck powinien być
> brany pod uwagę, tym bardziej że ma 0 procent udziału w rynku embedded,
> więc musi być dobry.
>
> > Dosc powazne studium bledow w programach w C stwierdzilo ze
> > ok 25% bledow wykrytych po oddaniu programu to bylo bledne uzycie
> > =, kiedy mialo byc == (przy tym studium dotyczylo starannie napisanych
> > programow, z w miare niska srednia iloscia bledow).
>
> Serio? I to studium nie zauważyło metod zarządzania jakością w kodzie po
> latach 60tych? Skupili się na nieistotnym elemencie języka który od
> całej wieczności generuje ostrzeżenia w kompilatorach i który co
> najmniej od 20 lat nie stanowi żadnego argumentu? Sprawdziłeś czy ta
> książka jest po naszej erze? biory biblitek akademickich bywają czasem
> mocno przykurzone.
>
> > W Pascalu
> > bardzo trudno zrobic taki blad.
>
> Wiadomo. Dlatego lepszy. I dlatego nikt go nie stosuje. Spisek, Panie.
>
> > Ale skladnia to tylko kawalek,
> > semantyka C bazuje na operatorze adresu i arytmetyce wskaznikowej.
>
> Zupełnie jak Pascal. Chyba że znasz w Pascalu jakieś magiczne sztuczki
> operowania na rejestrach peryferiów, manipulowania pamięcia w sterowniku
> LCD, wypełnianiu bufora dla DMA, czyli codzienność w uC.
>
> > Prawie kazdy inny jezyk jawnie uzywa tablice.
>
> Dawaj, zademonstruj jak wypełnić bufor w DMA pod konkretnym adresem w
> pamiecu uC BEZ używania semantyki adresowej, najlepiej bez adresu. Żeby
> magicznie było.
>
> Ciekawe że mogę sobie napisać sementykę tablic w C++ działającą pod
> spodem na raw memory. Ale wiadomo, C++ jest niekoszerny. Pascal ino
> jest. Najlepiej Turbo.
>
> > Jest tez sprawa
> > sprawdzania typow, Pascal to traktuje powazniej.
>
> Zabawne bo C++ też. To gdzie ta zaleta nad C/C++ która powoduje że mam
> go traktować serio?
>
> Podpowiem tylko na marginesie: jeśli chcesz język koszerny do embedded,
> który ma co najmniej jakąs zaletę nad C/C++ to obecnie uważa się za taki
> Adę. Nie żeby to była prawda bo już coś tam pierdykło spektakularnie z
> powodu debilizmu programistów, ale mimo to koszerne to jest, ludzie
> lubią jak porządne języki robią porządne fajerwerki. Plebs pisuje w C z
> Misra-C a jak wie co robi to bez Misra. Troche się miga diodami w C/C++.
> W Toyocie piszą zmiennymi globalnymi w języku ciężko rozpoznawalnym. Tyle.

Tak się przglądam tej dyskusji i cos mi sie wydaje, że a...@m...uni.wroc.pl nie
widział żadnego oprogramowania przemysłowego poza uczelnią. Paru piszących tu
właczając w to szanownego kolegę stara mu się wytłumaczyc jak to robią "big boys and
girls" ale to nie trafia.
Njaśmieszniejsze jest to, że on ma trochę racji o nie pisaniu C/C++ tylko on o tym
nie wie. W przemyśle zajmującymi sie rzeczami jeżdzącymi masa nowego oprogramowania
krytycznego (nie mówie tu o systemach mutimedialnych ale a naprawdę krytycznym
oprogramowaniu np. kontroler ABS, ECU, DriveByWire) pisze sie w Mathlab/Simulink i to
jest transpilowane do C. Tak latwiej mozna udowodnic i przetestowac poprawnosc logiki
- jest masa oprogramowania automatatyzujaca to zadanie.
Natomiast jeśli kolegi dyskutant nadal chce używac Paskala do kontrolerow to polecam
Siemens SCL na sterowniki S7 - wyglada prawie jak Paskal - ma begin end i nawet
koszerny operator przypisania := ;-)

do góry