🚀 go-pugleaf

On 22/09/2019 21:34, J-23 wrote:
> A czy ja twierdze że Pascal jest wszędzie dobry?

Bo pytanie gdzie jest lepszy od czegokolwiek co obecnie jest w top 10.

> Ja znam kody które są utrzymywane od lat 90 w pascalu także przeszło juz 
> 30 lat i nadal jest na to zapotrzebowanie.

Nie, nie ma takich kodów napisanych w Pascalu w latach 90 których nie 
dało by się w sensownie ekonomicznym czasie przepisać na byleco. To nie 
COBOL. To tylko zabawka do pisania widoków na db.

> Nie wszystko można wrzucić do przeglądarki i wtedy "JS" i inne tego typu 
> cuda są psu na bude

To które db nie da się wrzucić do przeglądarki?

> Raczej od x wiadomosci tutaj pisze że szkoda ze został ten język tak 
> zaniedbany przy ciekawym projekcie jakim jest Lazarus

Ale własnie nie szkoda. Biore pierwszy z brzegu jezyk imperatywny i mam 
pascala o nieco innej składni + dodatki. Więc dlaczego szkoda? Gdzie 
jest tek killer ficzer że płaczesz po nim?

>> W obrebie systemu operacyjnego? Podaj choć jedną zaletę Delphi której 
>> nie znajdę byle gdzie, która wspomaga pisanie w OSie.
> Już mówiłem środowiska RAD są ciekawym rozwiązaniem szkoda że 
> Embarcadero je tak psuje

Sami wyprodukowali takie samo środowisko dla C++. Dodatkowo praktycznie 
każde IDE ma jakies elementy RAD. Dodatkowo RAD wygenerował całe 
pokolenie niepełnosprawnych programistów. W końcu jak się ma szybko to 
trudno narzekać że źle. Do dzisiaj sąsiednia firma pisząca w Delphi 
stosuje inżynierję programowania z lat 60. No, przesadzam, w latach 60 
już coś pobąkiwali o abstrakcji ...

>>> Pokaż mi soft na polskim rynku który robi coś więcej jak DB i się z 
>>> tego utrzymuje
>> Ale że sprzedają do PL czy nie?
> tak w polsce rzadko która firma wymaga czegoś więcej jak bazy danych a 
> tutaj dobre środowisko RAD robi robote. Problem w tym że go nie ma

Widocznie na jakimś innym rynku siedzimy, ja mam w okolicy firmy które 
db nie robią. Za to programują. Naprawdę. Nie w onklikach. Szok.

>> Zobacz DisplayLink, Mentor Graphics, ROckwell i bilion innych. Te trzy 
>> to zaledwie "druga strona ulicy" względem mnie. I nie trzepią softu 
>> db. Isnieje życie poza db, o czym wielu programistów Delphi własnie 
>> nie wie.
> I o czym ta informacja świadczy? Bo nie bardzo rozumiem że tego się nie 
> da napisać w Delphi?

Nie. Albo inaczej: "nie" biznesowo, choć "tak" akademicko.

>> Lepsze narzędzia wymuszają porządek.
> pokaż bo ja nie znam takiego narzędzia który by na mnie wymusił 
> prawidłowe kodowanie lub nawet porządek w plikach. No chyba że masz na 
> myśli jakieś Fremworki ale to inna kwestia.

Mam na myśli na przykład prawidłowy zestaw algorytmiki. Nie zliczę ile 
widziałem rozwiązań w Pascalu tego samego problemu: dynamicznego 
kontenera. W zasadzie każde własne, piękne i bez sensu, pomijając bugi. 
Uczelnie wypruwają sobie żyły (nadal) tłumacząć jak w pascalu zrobić 
listę dwukierunkową. Nastepne pokolenie studentów robi to samo w 
robocie. Dżizas...

Mam na myśli standaryzajcę podstawowych narzędzi programisty: wątki, 
korutyny, IPC itd.

Mam na myśli pisanie przenośne, czyli tam gdzie DWORD jest głupie z 
definicji.

>> Nie ma tam żadnego potencjału. Świat nie potrzebuje nastepnego 
>> żałosnego języka imperatywnego w dolnej półki o niejasnej przyszłości.
> Tak a to ciekawe? Czyli co już nie potrzeba nowych rozwiązań i 
> technologi bo już wszystko mamy?

Ale w Delphi/Pascalu nie ma nic dla nowych technologii. Jesli ktokolwiek 
chciały rozwijać nowe technologie to albo wybierze nowy język (jak 
wszelakie Kotliny i Go), albo wybierze bazę biblitek które już istnieją 
i doda swoje koncepcje (Clojure).

Pudrowanie trupa uważam za koncepcje przezabawną, wystarczy zobaczyć 
gdzie idzie rozwój C++. I żeby nie było: zawodowo akurat w nim piszę.

heby <heby@poczta.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

> 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

Maciej Sobczak <see.my.homepage@gmail.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

Maciej Sobczak <see.my.homepage@gmail.com> Wrote in message:
> 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

True.

Zwłaszcza że program w C można skompilować trzema lub więcej
 zupełnie różnymi kompilatorami - a w ten sposób sprawdzić, czy
 np. wyniki obliczeń nie zależą od kompilatora.

-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

Czym innym jest TDD, czym innym audyt kodu, a czym kontrola
 jakości. Niektóre rzeczy nie powinny być sztucznie rozdzielane od
 klepania kodu, inne wręcz przeciwnie.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On 2019-09-28 15:06, slawek wrote:
> Zwłaszcza że program w C można skompilować trzema lub więcej
>   zupełnie różnymi kompilatorami - a w ten sposób sprawdzić, czy
>   np. wyniki obliczeń nie zależą od kompilatora.

Hehe. To jest _kpina_ a nie weryfikacja poprawnosci.

AK

On 28/09/2019 20:10, AK wrote:
>> Zwłaszcza że program w C można skompilować trzema lub więcej
>>   zupełnie różnymi kompilatorami - a w ten sposób sprawdzić, czy
>>   np. wyniki obliczeń nie zależą od kompilatora.
> Hehe. To jest _kpina_ a nie weryfikacja poprawnosci.

Mała uwaga: w dużych firmach w których małą błąd kosztuje życie tysięcy 
ludzi (lotnictwo, energetyka itd itp) własnie taka kontrola ma miejsce. 
Kila kompilatorów i kilka symulatorów (HDL) testujących ten sam kod.

Niestety ale nie ma chwilowo zewryfikowanego formalnie kompilatora 
użytecznego języka, więc jeśli chcesz podnoscić bezpieczeństwo czasem i 
takie metody mają sens.

> Zwłaszcza że program w C można skompilować trzema lub więcej
>  zupełnie różnymi kompilatorami - a w ten sposób sprawdzić, czy
>  np. wyniki obliczeń nie zależą od kompilatora.

int multiply(int x, int y)
{
    return x + y;
}

Wyniki obliczeń tej funkcji nie będą zależeć od kompilatora i to niezależnie czy będzie tych kompilatorów 3 czy 33.
W Twoim rozumowaniu jest błąd.

Spróbuj rozwiązać ten problem i wtedy zobaczysz, że nie trzeba 3 kompilatorów. Dlatego tej metody się nie używa.

Inna sprawa, że jeżeli te kompilatory są naprawdę różne, to wygenerowany przez nie kod będzie się różnił rozmiarami sekcji, rozmieszczeniem obiektów, opóźnieniami w czasie wykonania - czyli z punktu widzenia systemów krytycznych wszystkim. Co z tego, że coś się policzy tak samo, skoro nie tam gdzie trzeba i nie wtedy kiedy trzeba. To też jest powód, dla którego tej metody się w praktyce nie używa.

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

> Mała uwaga: w dużych firmach w których małą błąd kosztuje życie tysięcy 
> ludzi (lotnictwo, energetyka itd itp) własnie taka kontrola ma miejsce. 
> Kila kompilatorów i kilka symulatorów (HDL) testujących ten sam kod.

Statystycznie nie, z powodów, które odpisałem Sławkowi.

> Niestety ale nie ma chwilowo zewryfikowanego formalnie kompilatora 
> użytecznego języka,

http://compcert.inria.fr/doc/index.html

Ale właściwie nikt tego nie używa. To jest bardzo ciekawe zjawisko, bo pokazuje, że jakości nie uzyskuje się kupując jakiś cudowny produkt.

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

On 2019-09-28 20:21, heby wrote:
> Niestety ale nie ma chwilowo zewryfikowanego formalnie kompilatora 
> użytecznego języka, więc jeśli chcesz podnoscić bezpieczeństwo czasem i 
> takie metody mają sens.

A Ada to pikuś?

AK

On 30/09/2019 10:40, AK wrote:
>> Niestety ale nie ma chwilowo zewryfikowanego formalnie kompilatora 
>> użytecznego języka, więc jeśli chcesz podnoscić bezpieczeństwo czasem 
>> i takie metody mają sens.
> A Ada to pikuś?

Pikuś. Nikt tego nie używa w większości projektów embedded. Tam gdzie 
się używa wiedzą co chcą osiągnąć. Ale to szum. Ada jest niespecjalnie 
uzyteczna masowo.

On 30/09/2019 09:27, Maciej Sobczak wrote:
>>   zupełnie różnymi kompilatorami - a w ten sposób sprawdzić, czy
>>   np. wyniki obliczeń nie zależą od kompilatora.
> int multiply(int x, int y)
> {
>      return x + y;
> }
> 
> Wyniki obliczeń tej funkcji nie będą zależeć od kompilatora i to niezależnie czy będzie tych kompilatorów 3 czy 33.
> W Twoim rozumowaniu jest błąd.

Zakładasz błędnie że testuej się w ten sposób kod. NIE. Testuje się w 
ten sposób kompilatory i symulatory w kontekście tego kodu.

> Spróbuj rozwiązać ten problem i wtedy zobaczysz, że nie trzeba 3 kompilatorów. Dlatego tej metody się nie używa.

Zabawne, bo w kilku krytycznych miejscach i za duże pieniądze się używa. 
Firmy kupują choelrnie drogi soft robiący to samo, ale od różnych 
producentów tylko po to aby się upewnić że działanie ich kodu jest 
zamierzone a nie tylko że to artefakt narzędzia.

On 2019-09-30 18:24, heby wrote:
> On 30/09/2019 10:40, AK wrote:
>>> Niestety ale nie ma chwilowo zewryfikowanego formalnie kompilatora 
>>> użytecznego języka, więc jeśli chcesz podnoscić bezpieczeństwo czasem 
>>> i takie metody mają sens.
>> A Ada to pikuś?
> 
> Pikuś. Nikt tego nie używa w większości projektów embedded.

To wlasnie ten co sie uzywa to jest "wibitny" pikus :)
Ada jest ok.

AK

> > A Ada to pikuś?
> 
> Pikuś. Nikt tego nie używa w większości projektów embedded. Tam gdzie 
> się używa wiedzą co chcą osiągnąć. Ale to szum. Ada jest niespecjalnie 
> uzyteczna masowo.

Świeżutki news:

https://www.adacore.com/press/european-space-agency-selects-adacores-qualified-multitasking-solution-for-spacecraft-software-development

Ferrari też nie jest użyteczny masowo. Ale to jednak fajna fura jest.

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

> > Spróbuj rozwiązać ten problem i wtedy zobaczysz, że nie trzeba 3 kompilatorów. Dlatego tej metody się nie używa.
> 
> Zabawne,

Zabawne jest to, że nie rozwiązałeś tego problemu, tylko cały czas machasz rękami, że "w krytycznych miejsca", "za duże pieniądze" albo "w dużych firmach", itp.

A ja proszę tylko, żebyś rozwiązał wskazany przeze mnie problem. Wtedy będziemy wiedzeli, ile kompilatorów do tego potrzeba.

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

Maciej Sobczak <see.my.homepage@gmail.com> Wrote in message:
> A ja proszę tylko, żebyś rozwiązał wskazany przeze mnie problem. Wtedy będziemy wiedzeli, ile kompilatorów do tego potrzeba.

No cóż, jak się jest studentem wystarczy jeden.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

> > A ja proszę tylko, żebyś rozwiązał wskazany przeze mnie problem. Wtedy będziemy wiedzeli, ile kompilatorów do tego potrzeba.
> 
> No cóż, jak się jest studentem wystarczy jeden.

Akurat najwięcej kompilatorów równocześnie miałem właśnie wtedy, gdy byłem studentem. :-D

Czyli w tej dyskusji mam już dwóch dyskutantów, którzy nie potrafią rozwiązać wskazanego przeze mnie problemu.

Może jednak ktoś podejmie wyzwanie? Przypomnę, że chodzi o funkcję, która coś liczy, ale zachodzi podejrzenie, że nie to co trzeba.

Zagadkę "ile kompilatorów potrzebuje programista, żeby napisać program" rozwiążemy przy okazji.

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

On 01/10/2019 09:18, Maciej Sobczak wrote:
>> Pikuś. Nikt tego nie używa w większości projektów embedded. Tam gdzie
>> się używa wiedzą co chcą osiągnąć. Ale to szum. Ada jest niespecjalnie
>> uzyteczna masowo.
> Świeżutki news:
> https://www.adacore.com/press/european-space-agency-selects-adacores-qualified-multitasking-solution-for-spacecraft-software-development
> Ferrari też nie jest użyteczny masowo. Ale to jednak fajna fura jest.

No. Clojure też jest fajna fura. Te z listy ezoterycznych też są fajne. 
Całe szczęście Pascal nie jest.

On 01/10/2019 09:22, Maciej Sobczak wrote:
> A ja proszę tylko, żebyś rozwiązał wskazany przeze mnie problem.

Proszę:


int multiply(int x, int y)
{
     return x + y;
}

"Wyniki obliczeń tej funkcji nie będą zależeć od kompilatora".

G. prawda. int nie jest zdefiniowany i wynik będzie zależał od 
kompilatora, architektury, flag kompilacji i bugów w kompilatorze.

Te ostatnie bywają kłopotliwe z definiowaniu w sposób pewny.

heby <heby@poczta.onet.pl> Wrote in message:
> On 01/10/2019 09:22, Maciej Sobczak wrote:> A ja proszę tylko, żebyś rozwiązał wskazany przeze mnie problem.Proszę:int multiply(int x, int y){     return x + y;}"Wyniki obliczeń tej funkcji nie będą zależeć od kompilatora".G. prawda. int nie jest zdefiniowany i wynik będzie zależał od kompilatora, architektury, flag kompilacji i bugów w kompilatorze.Te ostatnie bywają kłopotliwe z definiowaniu w sposób pewny.

Piękny przykład - Turbo Pascala na PC - każdy program (exe)
 kalibrował na starcie opóźnienie delay (jakby kiedyś była
 potrzebna). Robił to wykonując jakiegoś nop ileś tam razy. Potem
 sobie coś wyliczał. No i problem: prędkość procesorów wzrosła aż
 tak, że te nop-yBo zajmowały zero czasu (mierzonego z
 dokładnością 55ms czy jakoś tak). Efekt? Piękne dzielenie przez
 zero i crash w startu code... I to zwykle w programach które
 przez wiele lat były "całkiem dobre". Oczywiście - dotyczyło to
 tylko jednego konkretnego kompilatora, jednego producenta. Więc
 nie ma że działanie programu nie zależy od kompilatora. I że
 każdy kompilator jest taki sam - to piękny - ale
 sen.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On 2019-10-03 20:44, slawek wrote:
> heby <heby@poczta.onet.pl> Wrote in message:
>> On 01/10/2019 09:22, Maciej Sobczak wrote:> A ja proszę tylko, żebyś rozwiązał wskazany przeze mnie problem.Proszę:int multiply(int x, int y){     return x + y;}"Wyniki obliczeń tej funkcji nie będą zależeć od kompilatora".G. prawda. int nie jest zdefiniowany i wynik będzie zależał od kompilatora, architektury, flag kompilacji i bugów w kompilatorze.Te ostatnie bywają kłopotliwe z definiowaniu w sposób pewny.
> 
> Piękny przykład - Turbo Pascala na PC - każdy program (exe)
>   kalibrował na starcie opóźnienie delay (jakby kiedyś była
>   potrzebna). Robił to wykonując jakiegoś nop ileś tam razy. Potem
>   sobie coś wyliczał. No i problem: prędkość procesorów wzrosła aż
>   tak, że te nop-yBo zajmowały zero czasu (mierzonego z
>   dokładnością 55ms czy jakoś tak). Efekt? Piękne dzielenie przez
>   zero i crash w startu code... I to zwykle w programach które
>   przez wiele lat były "całkiem dobre". Oczywiście - dotyczyło to
>   tylko jednego konkretnego kompilatora, jednego producenta. Więc
>   nie ma że działanie programu nie zależy od kompilatora. I że
>   każdy kompilator jest taki sam - to piękny - ale
>   sen.

To prawda.
Tyle tylko, ze to nie wina Pascala, ale Borlanda (tyczy TurboPascala3.x 
a nie 4.x czy Delphii).
W owym czasie MC C/C++ praktycznie nie nadawal sie do uzycia (50+
powaznych bugow), dlatego pisalismy w.. Turbo C++ a pozniej w Borland
C++.
PS: Na tymze syfiastym Borlandzie stalo cale Asseco (wtedy COMP Rzeszow)
- vide defBank. Wiec spoko Slawciu. Nie podniecaj sie. Mozna...
Jeno trzeba sie _naprawde_ znac (bebechy kompilerow rowniez).

PS: Moge Ci latwo udowodnic _jak_ trzeba sie bylo znac.
No ale tego ex cathedra nie widac (tylko byle granty;)

AK

On Thursday, October 3, 2019 at 8:04:09 PM UTC+2, heby wrote:
> On 01/10/2019 09:18, Maciej Sobczak wrote:
> >> Pikuś. Nikt tego nie używa w większości projektów embedded. Tam gdzie
> >> się używa wiedzą co chcą osiągnąć. Ale to szum. Ada jest niespecjalnie
> >> uzyteczna masowo.
> > Świeżutki news:
> > https://www.adacore.com/press/european-space-agency-selects-adacores-qualified-multitasking-solution-for-spacecraft-software-development
> > Ferrari też nie jest użyteczny masowo. Ale to jednak fajna fura jest.
> 
> No. Clojure też jest fajna fura. Te z listy ezoterycznych też są fajne. 
> Całe szczęście Pascal nie jest.

Uwaga, teraz mówię ściśle o języku, ewentualnie o tak bliskich narzędziach 
jak preprocesor w C/C++. Do rzeczy, osobiście bardzo lubiłem pascala. Ale 
języki takie jak Java, C, C++, C# moim zdaniem są fajniejsze. Szkoda że 
język D ma małe wsparcie, możliwe że byłby moim ulubionym językiem. PHP
nie lubię, ale używam, ponieważ jest dedykowany do weba i ma pod ręką
masę wygodnych bibliotek przydatnych w aplikacjach webowych.

Pozdrawiam

> > Świeżutki news:
> > https://www.adacore.com/press/european-space-agency-selects-adacores-qualified-multitasking-solution-for-spacecraft-software-development
> > Ferrari też nie jest użyteczny masowo. Ale to jednak fajna fura jest.
> 
> No. Clojure też jest fajna fura. Te z listy ezoterycznych też są fajne.

Tak. I nawet każdy z nich ma swój fanclub. Ale do rakiety się nie nadają.
Dopiero co dyskutowaliśmy tu o tym, ale można jeszcze raz.

> Całe szczęście Pascal nie jest.

Czym nie jest? Fajną furą? Użyteczny masowo? Wybrany przez ESA do najnowszego projektu? Bo się pogubiłem.

Nie znam żadnego nowego projektu, gdzie zdecydowano by się użyć Pascala (oczywiście nie znaczy to, że takich nie ma). Znam natomiast nowy projekt z Adą, link powyżej.

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

> int multiply(int x, int y)
> {
>      return x + y;
> }
> 
> "Wyniki obliczeń tej funkcji nie będą zależeć od kompilatora".
> 
> G. prawda. int nie jest zdefiniowany i wynik będzie zależał od 
> kompilatora [...]

To w końcu jakie jest rozwiązanie tego problemu?
Wybrać kompilator, z którym wyniki tej funkcji mają najwięcej lajków?

Nadal nie rozwiązałeś tego problemu.

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

On 04/10/2019 07:48, Maciej Sobczak wrote:
>> No. Clojure też jest fajna fura. Te z listy ezoterycznych też są fajne.
> Tak. I nawet każdy z nich ma swój fanclub. Ale do rakiety się nie nadają.

Wątek wyrasta głównie z tezy ze Pascal się nadaje lepiej niż inne.

Natomiast Ada to tylko taka mała mina na którą co chwile wchodzisz i 
wybuchasz. Niezmiennie.

> Dopiero co dyskutowaliśmy tu o tym, ale można jeszcze raz.

Wiem, działa za każdym razem.

>> Całe szczęście Pascal nie jest.> 
> Czym nie jest? Fajną furą? Użyteczny masowo?

Nie jest ani jednym ani drugim.

> Wybrany przez ESA do najnowszego projektu?

Jeszcze by tego brakowało.

> Znam natomiast nowy projekt z Adą, link powyżej.

Ja znam milion nowych w Verilogu. Też krytycznych, często bardziej niż 
żelastwo w kosmosie. I wiesz co, wybrali tym razem język wyjątkowo 
gówniany. Co robić, taki świat.

On 04/10/2019 07:51, Maciej Sobczak wrote:
> Nadal nie rozwiązałeś tego problemu.

Ten problem (czyli pomyłka mnożenia z dodawaniem) rozwiazuje każda 
kolejna warstwa inżynierii programowania od co najmniej 50 lat. Od unit 
testów, przez code review po testy integracyjne, wszędzie zostanie 
wyłapana z dokładnością do asymptoty. Na 99% bug taki zostanie wyłapany 
już w unit testach, przynajmniej u mnie i zaryzykuje że w każdym 
poważniejszym programowaniu. Jeśli Ci się wydaje że o takie błedy chodzi 
wybierając kilka kompilatorów to naprawdę postaraj się zakładać że 
rozmówcy nie są idiotami i od razu będzie lepiej.

Kiedy już te i masę innych etapów weryfikacji przejdziezsz po drodze 
ktos zapyta czy dajesz wiarę w kompilator. Prawdłowa odpowiedź brzmi: 
zalezy od ryzyka. Istnieją ryzyka gdzie nie można zaufa kompilatorowi. 
Nie da się też go zweryfikować formalnie. Choć można mocno wierzyć, ale 
to raczej nie przejdzie podczas certyfikacji.

AK <nobody@nowhere.net> Wrote in message:
> Na tymze syfiastym Borlandzie stalo cale Asseco

No i?

Tyle że TERAZ nie ma sensu uczyć się Pascala (ew. Delphi). Nie ma
 też sensu - znając około 20 języków - do wszystkiego używać
 C++.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

heby <heby@poczta.onet.pl> Wrote in message:
> On 04/10/2019 07:51, Maciej Sobczak wrote:> Na 99% bug taki zostanie wyłapany już w unit testach, przynajmniej u mnie i zaryzykuje że w każdym poważniejszym programowaniu.


Coverage 99%? No, no. Tyle że są takie problemy że nie ma jak
 robić unit testów. Nie wiadomo ile powinno wyjść.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On 04/10/2019 21:10, slawek wrote:
>> On 04/10/2019 07:51, Maciej Sobczak wrote:> Na 99% bug taki zostanie wyłapany już w unit testach, przynajmniej u mnie i zaryzykuje że w każdym poważniejszym programowaniu.
> Coverage 99%?

W takiej funkcji? Poza przypadkiem f(2,2) wyłapie go każdy inny test.

> No, no.

Zadziwiające, nie?

> Tyle że są takie problemy że nie ma jak
>   robić unit testów.

Tylko że to nie ten problem.

> Nie wiadomo ile powinno wyjść.

To może nie warto pisać programów. Dobrze płacą ostatnio hodowcom 
pietruszki.

heby <heby@poczta.onet.pl>Dobrze płacą ostatnio hodowcom pietruszki.

Niestety nie. Uprawa roli się nie opłaca. Hodowla? Też nie.
 Powielasz mity, brak ci wiedzy.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On 04/10/2019 21:46, slawek wrote:
> Niestety nie. Uprawa roli się nie opłaca. Hodowla? Też nie.
>   Powielasz mity, brak ci wiedzy.

https://finanse.wp.pl/pietruszka-pozwoli-ci-zarobic-setki-tysiecy-zl-zobacz-jak-zostac-jej-krolem-6400705253349505a

Zastanów się jednak czy nie warto. Skoro pisanie unit testów dla 
jednolinijkowca okazało się byc jakimś przykładem kłopotów weryfikacji 
softu to możesz się sprawdzić w innej branży.

On 2019-10-04 21:04, slawek wrote:
> Tyle że TERAZ nie ma sensu uczyć się Pascala (ew. Delphi).

To 100% prawda.
Tyle tylko, ze kompletnie nie z powodu niby-wad samego Pascala
jako jezyka, ani nie z powodu niby-wad (chyba najlepszy RAD
jaki powstal) srodowiska Delphii/C++ Builder.
Powody byly _zupelnie_ inne.

AK

On 2019-10-04 20:21, heby wrote:
>> Znam natomiast nowy projekt z Adą, link powyżej.
> 
> Ja znam milion nowych w Verilogu. Też krytycznych, często bardziej niż 
> żelastwo w kosmosie. I wiesz co, wybrali tym razem język wyjątkowo 
 > gówniany.

No wlasnie. No a obok jest sobie o niebo lepszy (w sensie inzynierii
j.prog) VHDL?

> Co robić, taki świat.

Myslalem cale zycie, ze mlodosc to taki czas, ze chce sie ten swiat
zmieniac na lepszy (chocby ten malutki wokol siebie i chocby...
dla wlasnej przyjemnosci/satysfakcji nie godzenia sie z byle g...)
No a co my tu mamy? Młodziez mentalnie starsza ode mnie? ;)

AK

heby <heby@poczta.onet.pl> Wrote in message:
> On 04/10/2019 21:46, slawek wrote:> Niestety nie. Uprawa roli się nie opłaca. Hodowla? Też nie.>   Powielasz mity, brak ci wiedzy.https://finanse.wp.pl/pietruszka-pozwoli-ci-zarobic-setki-tysiecy-zl-zobacz-jak-zostac-jej-krolem-6400705253349505aZastanów się jednak czy nie warto. Skoro pisanie unit testów dla jednolinijkowca okazało się byc jakimś przykładem kłopotów weryfikacji softu to możesz się sprawdzić w innej branży.

Rzecz w tym że jesteś za głupi aby ogarnąć jak bardzo jesteś
 głupi. Podajesz przykład "jednolinijkowca" (mającego w istocie ze
 trzy linijki, ale to nieistotne) jako dowód tezy że testy
 jednostkowe wyłapią wszystko. No to popatrz miszczu na coś
 takiego:

function fun(int n): real;
var i: integer;
var s: real;
begin
    s := 0;
    for i := 1 to n do s := s + buz(1.0 / i);
    fun := s
end

No i co? Możesz - a jakże - sprawdzać co będzie gdy n <= 0. Możesz
 ewentualnie sprawdzić, że dla n = 1 powinno być fun(1) = buz(1.0)
 z dokładnością co do maszynowego epsilon. Możesz nawet sprawdzić,
 znając konkretną buz, np. że to logarytm naturalny sinusa,
 jeszcze parę wartości. I na tym koniec. Bo gdy buz będzie
 definiowana przez użytkownika (np. przez podanie kilkunastu liczb
 określających współczynniki, wykładniki itp.) - to zwyczajnie nie
 wiesz co z czym masz assertEqual. Naturalnie możesz radośnie 
 sprawdzać że wynik jest różny od pi - bo dla wielu funkcji buz
 tak przypadkiem będzie.

Przy tym taki drobiazg: testy według ciebie - chcesz 100% coverage
 - powinny objąć jakieś 2**63 czyli około 10**19 wartości...
 jeżeli integer jest 64 bitowy.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On 2019-10-05 07:40, slawek wrote:
> No to popatrz miszczu na coś
>   takiego:

Brawo :)

PS: Powinno utrzec nosa MWZWM... ale nie utrze.
     Oni wiedzą "lepiej"...

AK

On 2019-10-05 07:40, slawek wrote:
> Naturalnie możesz radośnie
>   sprawdzać że wynik jest różny od pi - bo dla wielu funkcji buz
>   tak przypadkiem będzie.

Hehehe

On 05/10/2019 07:02, AK wrote:
>>> Znam natomiast nowy projekt z Adą, link powyżej.
>> Ja znam milion nowych w Verilogu. Też krytycznych, często bardziej niż 
>> żelastwo w kosmosie. I wiesz co, wybrali tym razem język wyjątkowo 
>  > gówniany.
> No wlasnie. No a obok jest sobie o niebo lepszy (w sensie inzynierii
> j.prog) VHDL?

VHDL to Ada. Z domalowanymi duperelami.

I nie wybrali.

Co za chamy. Być może ma to związek z takim drobnym faktem że 
weryfikacja jest ważniejsza niż składnia.

A Verilog ma biliard razy więcej narzędzi do weryfikacji niż VHDL i 
jednocześnie najbardziej gównianą składnię jaką można sobie wyobrazić.

Ale to dalej chamy. Przecież Ada jest najlepsza.

>> Co robić, taki świat.
> Myslalem cale zycie, ze mlodosc to taki czas, ze chce sie ten swiat
> zmieniac na lepszy (chocby ten malutki wokol siebie i chocby...
> dla wlasnej przyjemnosci/satysfakcji nie godzenia sie z byle g...)
> No a co my tu mamy? Młodziez mentalnie starsza ode mnie? ;)

Świat sobie możesz zmieniać lokalnie. Do zmiany świata na lepsze w 
sensie globalnym znacznie lepiej sprawdzają się wojny choć one działają 
tylko w sensie statystycznym.

PS. W informatyce prawie nigdy nie wygrywa najlepsze. Wygrywa zawsze 
religijność wyznawców jakiejś rzeczy a efekt motyla jest widoczny 
bardziej niż gdziekolwiek.

On 05/10/2019 07:40, slawek wrote:
>   trzy linijki, ale to nieistotne) jako dowód tezy że testy
>   jednostkowe wyłapią wszystko. 

Nikt takiej tezy nie postawił. Pokazałeś przykład, wyjaśniłem Ci że 
żałosny a ty dorabiasz filozofię. Reszta to już wewnątrzne głosy.

> No i co? Możesz - a jakże - sprawdzać co będzie gdy n <= 0. Możesz
>   ewentualnie sprawdzić, że dla n = 1 powinno być fun(1) = buz(1.0)
>   z dokładnością co do maszynowego epsilon. Możesz nawet sprawdzić,
>   znając konkretną buz, np. że to logarytm naturalny sinusa,
>   jeszcze parę wartości. I na tym koniec. Bo gdy buz będzie
>   definiowana przez użytkownika (np. przez podanie kilkunastu liczb
>   określających współczynniki, wykładniki itp.)

Jeśli dowolny element badanego kodu nie jest znany na etapie jego 
unittestowania to mamy do czynienia z testami nie unit tylko *jakimiś*, 
najczęsciej integracyjnymi.

Tak że niestety, nie masz pojęcia o czym bredzisz.

> Przy tym taki drobiazg: testy według ciebie - chcesz 100% coverage

100% coverage mówisz? A jakiego coverage? Wszystkich stanów? Może 
wszystkich lini? Może triggera dla wszystkich bitów? Wszystkich gałęzi? 
Wszystkich asercji? Może jakiegoś innego z kilkunastu mierników coverage?

Planowanie testowania moze mieć wymóg pokrycia 100% stanów, może mieć 
wymóg pokrycia 90% lini itd itp. Zależy co masz w planie testowania. Bo 
masz, prawda?

>   - powinny objąć jakieś 2**63 czyli około 10**19 wartości...
>   jeżeli integer jest 64 bitowy.

Jesli ktoś tak zdefiniował coverage. Całe szczęście nie każdy tak 
definiuje. Można powiedzieć że tylko niejaki "sławek" tak defniniuje.

On 2019-10-05 09:57, heby wrote:
> VHDL to Ada. Z domalowanymi duperelami.

Bzdurzysz po raz kolejny.

> I nie wybrali.

Nie pierwszy i nie ostatni raz "pieniadz gorszy wyparl lepszy".
I co? Cieszysz sie z tego, ze wybrano C-podobne kolejne g..wno?

AK

On 2019-10-05 10:03, heby wrote:
> Jeśli dowolny element badanego kodu nie jest znany na etapie jego 
> unittestowania to mamy do czynienia z testami nie unit tylko *jakimiś*, 
> najczęsciej integracyjnymi.

Tu juz pojechales :)
Zwyczajnie pieprzysz.
PS: Moze bys wpierw przetestowal blech-a co?

AK

On 06/10/2019 08:54, AK wrote:
>> Jeśli dowolny element badanego kodu nie jest znany na etapie jego 
>> unittestowania to mamy do czynienia z testami nie unit tylko 
>> *jakimiś*, najczęsciej integracyjnymi.
> Tu juz pojechales :)

Wskaz bład w twierdzeniu że testowanie kodu którego nie znamy w całości 
za pomocą unit testów nie jest unit testowaniem.

> Zwyczajnie pieprzysz.

To wymaga podania argumentu inaczej to jest zwykłe pieprzenie.

> PS: Moze bys wpierw przetestowal blech-a co?

A co to jest blech?

On 06/10/2019 08:52, AK wrote:
>> VHDL to Ada. Z domalowanymi duperelami.
> Bzdurzysz po raz kolejny.

Otwórz dokumentacje do VHDLa i do Ady z tej samej wersji. Jest 
identyczna z dokładnością do przecinków + VHDL dodatkowo dodaje HDLowe 
konstrukcje.

https://en.wikipedia.org/wiki/VHDL

Due to the Department of Defense requiring as much of the syntax as 
possible to be based on Ada, in order to avoid re-inventing concepts 
that had already been thoroughly tested in the development of 
Ada,[citation needed] VHDL borrows heavily from the Ada programming 
language in both concepts and syntax.

To heavily okazalo się copy-paste.

Wnisek: świat nie ma racji, AK ma.

>> I nie wybrali.
> Nie pierwszy i nie ostatni raz "pieniadz gorszy wyparl lepszy".
> I co? Cieszysz sie z tego, ze wybrano C-podobne kolejne g..wno?

Odwrotnie. Pokazuje że sugerowanie lepszości Ady bo ją ktoś wybrał w ESA 
jest idiotyzmem. Cała reszta świata wybrała gorszy język. Róznica jest 
jednak taka że może i gorszy za to z przerośniętą weryfikacją.

On 2019-10-06 11:34, heby wrote:
> On 06/10/2019 08:52, AK wrote:
>>> VHDL to Ada. Z domalowanymi duperelami.
>> Bzdurzysz po raz kolejny.
> 
> Otwórz dokumentacje do VHDLa i do Ady z tej samej wersji. Jest 
> identyczna z dokładnością do przecinków + VHDL dodatkowo dodaje HDLowe 
> konstrukcje.

Chopie. Co ma skladnia do faktu, ze jezyki typu Verilog czy VHDL
sa _defaultowo_ "rownoległe" i w duzym stopniu "deklaratywne",
a Ada defaultowo jest jak najbardziej sekwencyjna.
Skladnia ma tu 0-rowe znaczenie.
PS: Java i C++ tez maja prawie identyczna skladnie, a przecie
roznia sie _zasadniczo_: C++ defaultowo jest "wartosciowy",
a Java wybitnie "referencyjna".

AK

On 06/10/2019 12:26, AK wrote:
>> Otwórz dokumentacje do VHDLa i do Ady z tej samej wersji. Jest 
>> identyczna z dokładnością do przecinków + VHDL dodatkowo dodaje HDLowe 
>> konstrukcje.
> Chopie. Co ma skladnia do faktu

Składnia ma bardzo dużo do powiedzenia kiedy pytamy o podobieństwo języków.

>, ze jezyki typu Verilog czy VHDL
> sa _defaultowo_ "rownoległe" i w duzym stopniu "deklaratywne",

Są takie same jak Ada + łatwe tworzenie "wątków" wprost z języka.

> a Ada defaultowo jest jak najbardziej sekwencyjna.

Podobnie jak każdy *process* VHDLa.

> Skladnia ma tu 0-rowe znaczenie.

Wiadomo, dlatego VHDL ma identyczną składnie z Atari Basic i BCPL bo też 
ma znaczki ascii ułożone w rózne wyrazy i liczby.

> PS: Java i C++ tez maja prawie identyczna skladnie, a przecie
> roznia sie _zasadniczo_: C++ defaultowo jest "wartosciowy",
> a Java wybitnie "referencyjna".

To faktycznie róznica. Kolesie od Ady zapewne wyłupili teraz oczy na 
samą myśl że ich fancy język zredukowano o takich problemów jak 
referencje. I całe to bezpieczeństwo Ady poc=szło w h... kiedy okazało 
się że VHDL to to samo co Verilog a nie Ada. Oj, biedny ten świat kiedy 
AK rozszarpuje na strzępy kolejne fakty.

On 2019-10-06 12:36, heby wrote:
> To faktycznie róznica.

A zebys wiedzial. _Zasadnicza_.
Dlatego C++-sowcy _musza sie dosc dlugo uczyc Javy_ (i odwrotnie).
PS: Cus mi sie wydaje, ze Jave i C++ "znasz" podobnie jak ASM.
PS1: Zeby nie bylo - Javowcem jestem slabym (ale no JNI czy reflection
Javy znam _na wylot_)>

AK

On 06/10/2019 13:00, AK wrote:
>> To faktycznie róznica.
> A zebys wiedzial. _Zasadnicza_.

Nie, detaliczna.

> Dlatego C++-sowcy _musza sie dosc dlugo uczyc Javy_ (i odwrotnie).

Nie, nie obserwuje długiego uczenia. Może tylko chwilowe zaskoczenie 
człowieka przychodzącego do C++. Istnieje znacząco więcej cieżkich 
problemów z którymi muszą się mierzyć niż referencje.

> PS: Cus mi sie wydaje, ze Jave i C++ "znasz" podobnie jak ASM.

Cuś mi się wydaje że wydajesz wyroki z powietrza. Jesteś szamanem?

> PS1: Zeby nie bylo - Javowcem jestem slabym (ale no JNI czy reflection
> Javy znam _na wylot_)>

No i ? Co z tego wynika jeśli chodzi o podobieństwo Ady vs VHDL?

heby <heby@poczta.onet.pl> Wrote in message:
> On 06/10/2019 08:54, AK wrote:>> Jeśli dowolny element badanego kodu nie jest znany na etapie jego >> unittestowania to mamy do czynienia z testami nie unit tylko >> *jakimiś*, najczęsciej integracyjnymi.> Tu juz pojechales :)Wskaz bład w twierdzeniu że testowanie kodu którego nie znamy w całości za pomocą unit testów nie jest unit testowaniem.> Zwyczajnie pieprzysz.To wymaga podania argumentu inaczej to jest zwykłe pieprzenie.> PS: Moze bys wpierw przetestowal blech-a co?A co to jest blech?

No cóż - z takim znawcą jak ty - znawcą cyt. "zwykłego
 pieprzenia" - trudno polemizować.

Więc taka mała prośba: funkcja muldiv(a, b, c) ma obliczać a*b/c
 tak aby unikać underflow i overflow, liczby są 64 bitowe, wynik
 też. Napisz wszystkie konieczne testy dla tego przypadku - tak
 abyś mógł zgodzić się że muldiv zostanie, cyt. "unittestowana".
 Chyba potrafisz, miszczu?!?


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On 06/10/2019 15:02, slawek wrote:
> No cóż - z takim znawcą jak ty - znawcą cyt. "zwykłego
>   pieprzenia" - trudno polemizować.
> Więc taka mała prośba: funkcja muldiv(a, b, c) ma obliczać a*b/c
>   tak aby unikać underflow i overflow, liczby są 64 bitowe, wynik
>   też. Napisz wszystkie konieczne testy dla tego przypadku - tak
>   abyś mógł zgodzić się że muldiv zostanie, cyt. "unittestowana".
>   Chyba potrafisz, miszczu?!?

Jasne, miszczu. Przy czym nie ja, tylko przemysł.

Oczywiśćie w pewnych warunkach szacuje się ryzyko więc odpowiedź nie 
będzie ścisła, tu masz przykłąd jednej z technologii w tym celu:

https://www.chipverify.com/systemverilog/systemverilog-randomization

Albo może ogólniej:

https://en.wikipedia.org/wiki/Random_testing

A więc, miszczu, twój problem jest częsciowo rozwiązywany w granicach 
zdrowego rozsądku mimo braku rozwiązania wprost.

Ale naprawde, podoba mi się Twoje podeście że jak ktoś wytnie Ci palcem 
że masz zbyt trywialny przykład to go podkręcasz i znowu machasz rękami.

Czy już wpsomnałem że w pewnych warunkacj twój problem da się rozwiązać 
formalnie? Tak, to też się robi tylko że tego nie można nazwać unit 
testowaniem.

No dawaj, podkręcaj tą dziecinadę.

On 2019-10-06 11:30, heby wrote:
> On 06/10/2019 08:54, AK wrote:
>>> Jeśli dowolny element badanego kodu nie jest znany na etapie jego 
>>> unittestowania to mamy do czynienia z testami nie unit tylko 
>>> *jakimiś*, najczęsciej integracyjnymi.
>> Tu juz pojechales :)
> 
> Wskaz bład w twierdzeniu że testowanie kodu którego nie znamy w całości 
> za pomocą unit testów nie jest unit testowaniem.
> 
>> Zwyczajnie pieprzysz.
> 
> To wymaga podania argumentu inaczej to jest zwykłe pieprzenie.
> 
>> PS: Moze bys wpierw przetestowal blech-a co?
> 
> A co to jest blech?

buz()

Pajacu, moze bys tak wpierw przetestowal (unitestowo jak najbardziej)
ten buz, zgdomadzil maksymalnie (bo wiadomo ze calej "dziedziny"
nie pokryjesz, a wazne, zeby to byly miejsca "charakterystyczne" np.
blisko koncow przedzialu, jakies inne punkty charakterystyczne)
miarodajne dane (czyli wyniki buz() z przykladowego zakresu/zakresow).

Te dane przyjmij jako input do faktycznych danych "expected" fun()a.
Oblicz wiec dla przetestowanych unitestowo w buz() przedzialow
(sprawdzona metoda realizujaca to co robi fun() /czyli np.
policz te sumy na kartce;) a co!:) odpowiednie sumy i uzyj ich
po prostu (jako wartosci oczekowane) w unitestach dla fun().

PS: Wiec zwyczajnie z tymi testami integracyjnymi pojechales.
Jesli tak (hm... nie mamy _na patelni_ wartosci oczekiwanych to..
olewamy unittesty.... a co ! przecie w "integracyjnych" wyjdzie)
to moge stwierdzic tylko jedno. Przedszkole, a nie testowanie :(

AK