W dniu wtorek, 20 listopada 2018 23:27:51 UTC+1 użytkownik g...@g...com
napisał:
> W dniu wtorek, 20 listopada 2018 10:58:08 UTC+1 użytkownik fir napisał:
>
> > fakt ze tego typu gnidy stanowia dolny odsetek 10% usenetu jest faktem i
probowani uczenia ich normalnosci (czego probuje godek) ma takie szanse powoedzenie
jak wpuszczanie czerwonopyskiego plujacego na podloge dresa (lub dresow) na wyklad z
filozofii
>
> Jakiś czas temu głośno było o rosyjskich trollach, którzy
> poruszali na forach temat szczepionek, po to tylko, żeby skłócać
> ze sobą ludzi.
> Czasem sobie myślę, że osoby, które tutaj wyjeżdżają z obraźliwymi
> tekstami, robią to celowo, żeby sprowadzić dyskusje do poziomu
> rynsztoku - żeby owocne dyskusje nie dochodziły do skutku.
>
> Nie jest to co prawda zbyt prawdopodobne, ale daje odmienną perspektywę,
> i uświadamia, że najlepsze, co możemy robić, to ignorować zaczepki
> takich osób.
>
> Z drugiej strony, oczernianie (w rodzaju snucia insynuacji
> o "spędzaniu czasu z nieletnimi dziewczynkami"), choć niewątpliwie
> świadczy o debilizmie oczerniającego, może mieć poważne konsekwencje
> dla osoby oczernianej (przychodzą na myśl samosądy, które miały
> miejsce w Indiach albo Ameryce Południowej na skutek propagacji
> fake newsów), i może nawet byłoby wskazane zgłaszanie takich
> incydentów do sądu.

nie chodzi o obrazanie, dla mnie obrazanie to chleb powszedni bo musze ogarniac sie
od baranow - wprost powiedzenie ze traca moj czas jest koniecznoscia

chodzi o tos zupelnie innego, np o tzw knajackie zachowania lub "odgrywanie ciezkiej
gnidy" ktora 'wyszukuje' choruch psychicznie i probuje sie z ich 'naigrywac' w necie,
proboje stalkowac i
inne tego typu chore zachowania - jego wlasny 'syndrom downa' nie pozwala mu zauwazyc
ze dla normalnych ludzi to nie jest normalne i takie cos to moze sie nadaje bardziej
na szpanowanie w wiezieniu w celi, do ktorych wlasnie downy z tego typu myslneiem na
ogol trafiaja, )

obrazanie to zupelnie cos innego, absolutnie nie o obrazanie tu chodzi -

do góry

On 2018-11-21 08:16, Maciej Sobczak wrote:
>> Ten prymitywizm przeklada sie na bardzo duze ulatwienia w stworzeniu
>> kompilatora, ktory "pojdzie" bez problemu rowniez na prymitywnym
>> sprzecie (embedded itp).
> Nie.

Tak.
Po prostu zadzialal mechanizm zdobycia popularnosci/masy krytycznej.
Nie tylo w informatyce byle g.. po zdobyciu popularnosci staje sie
"mainstreamem" (vive np.siostry Godlewskie...).

PS: Od lat piszę na usenecie, ze prawo Kopernika dziala idetycznie
w IT jak i w finansach.
PS0: Poza tym bylem "naocznym swiadkiem"/uczesnikiem (a nawet niestety
propagatorem) wypierania jezykow z duzych maszyn typu Algol, Simula,
Prolog, PL/I, Modula2 przez badziewie C/C++ sowe, wiec bede sie upieral,
ze to byla glowna przyczyna (bo XT 4.87 MHz 512kB nie uciagnelo nic
innego poza prymitywnym TurboC compiler (pozniej TurboC++).
Owszem. Czasowo uchowal sie Pascal (dzieki TurboPascalowi), ale w jego
przypadku jednak z przyczyn upadku bylo olanie standardu *.obj na rzecz
*.tpu, ale glowna idiotyczna polityka Borlanda (miast skupi sie na
rozwoju kompilatora/ow to zaczal kupowac a to AMI Pro a to dBase
itp.... W rezultacie MS C/C++- wtedy badziewny - go dogonil i
przegonil).

AK

do góry

On 2018-11-21 08:16, Maciej Sobczak wrote:
> Prymitywizm języka C jest natomiast przydatny (również dzisiaj) do tego, że w takim
języku związek między
> kodem źródłowym a obiektowym (tzn. tym skompilowanym) jest niemal 1:1 i każdy
średnio rozgarnięty inżynier
> jest w stanie wskazać linię ciągłą, w obie strony, pomiędzy tym co napisał a tym co
uruchomił.
> To jest absolutnie kluczowe w projektach krytycznych - tzn. jeśli tej
jednoznaczności nie ma, to projekt nie ma
> szans na sukces, przynajmniej nie przy dzisiejszych standardach procesowych.

Co? To niby na mainframes nie bylo projektow krytycznych/fault tolerant?
Nie bylo np. AS400 itp, a toto wcalenie bylo tworzone w C/C++.

> Innym językiem, który pozwala na takie jednoznaczne przełożenie, jest Ada (tzn.
jakiś rygorystycznie
> dobrany podzbiór).

W kwestii Ady nie do konca sie zgodze. To jednak o wiele wyzszy poziom
jezyka niz assemblerowate C/C++.
No a co np. z Modula2?. Kiedys przez lata de-facto standard w RealTime?
To byl jezyk wyzszego poziomu niz C++, a nie przeszkodzilo
mu to w zawladnieciu RT.

> Z C++ też się da, przy starannie wybranym podzbiorze języka.

PoMISRAny C czy C++ to juz wlasciwie nie jest C/C++ tylko calkiem inny
jezyk (tez oczywiscie potworek).

> Z tych trzech wygrywają... przyzwyczajenia.

Tu sie zgodze (a nawet wiecej).
Kiedysz krolowala sztuka, dzis kroluja przyzwyczajenia/lenistwo/
"brak ciekawosci swiata". Datego dzis tylu Ayatollahow C/C++.

AK

do góry

W dniu wtorek, 20 listopada 2018 14:38:53 UTC+1 użytkownik Maciej Sobczak napisał:
> > Warto przyjrzeć się językowi Idris i typom zależnym.
>
> Nie przekonują mnie. Jeśli je rozumiem, to typy zależne pozwalają związać warunki
między parametrami i wartością zwracaną z funkcji. Fajnie, ale to nie wyczerpuje
tematu, bo jest jeszcze stan (również globalny), który też mogę chcieć związać takimi
warunkami.

Nie wiem, czy to wyczerpuje temat, ale na pewno jest
przykładem czegoś, co zwiększa ilość rzeczy, które możemy
statycznie powiedzieć o naszym programie.

Tutaj jest prezentacja o tym, w jaki sposób typy zależne
umożliwiają wyrażanie błędów w programach (na przykładzie
Heartbleed, przy użyciu Liquid Haskell):
https://www.youtube.com/watch?v=YByOdE-YUwY

> Co więcej, takie warunki nie muszą mieć związku z typami - np. jedna metoda w
obiekcie może "obiecać" inne warunki końcowe, niż inna metoda, a przecież nie jest
tak, że typ obiektu jest różny w różnych metodach. Takie ograniczenie już na poziomie
terminologii wskazuje, że typy zależne to domena jakiejś niszy językowej (w
szczególności języków funkcjonalnych), więc od razu ma dla mnie ograniczoną
stosowalność.

Ja nie jestem co do tego przekonany. Tzn. mnie się to też
nie wydaje naturalne, ale często "naturalność" to po prostu
kwestia przyzwyczajenia.

> Potrzebny jest inny formalizm. Pre- i post-conditions wydają się być bardziej
niekonfliktowym mechanizmem, tzn. możliwym do zastosowania bez niepotrzebnych
ograniczeń.

Jest też język ATS (trochę protoplasta Rusta), który
ma system "typów liniowych" służących do wyrażania twierdzeń
o poprawności korzystania z zasobów. Ale wydaje się raczej
trudny do używania:
https://www.youtube.com/watch?v=zt0OQb1DBko

do góry

W dniu środa, 21 listopada 2018 11:12:50 UTC+1 użytkownik Queequeg napisał:

> > Z drugiej strony, oczernianie (w rodzaju snucia insynuacji
> > o "spędzaniu czasu z nieletnimi dziewczynkami"),
>
> Naprawdę myślisz że wyssałbym tego typu rzeczy z palca? Polecam zajrzeć do
> pokoju grungerap na Onecie.

Jeżeli "nie wysysasz tego typu rzeczy z palca", to znaczy, że albo
sam łazisz po takich pokojach, albo stalkujesz innych użytkowników.

do góry

g...@g...com wrote:

>> > Z drugiej strony, oczernianie (w rodzaju snucia insynuacji
>> > o "spędzaniu czasu z nieletnimi dziewczynkami"),
>>
>> Naprawdę myślisz że wyssałbym tego typu rzeczy z palca? Polecam zajrzeć do
>> pokoju grungerap na Onecie.
>
> Jeżeli "nie wysysasz tego typu rzeczy z palca", to znaczy, że albo
> sam łazisz po takich pokojach, albo stalkujesz innych użytkowników.

Ani jedno ani drugie. Wszystko, co wiem na temat fira, jest ogólnie
dostępne w Internecie (nie tylko na tej grupie). Wystarczy poczytać.

Stalking to bardzo mocne słowo, wyszukanie kogoś w Google pod to nie
podpada. Ciebie też wyszukałem po "panicz godek", gdy wrzuciłeś linka do
swojej Quory, przejrzałem twojego githuba i przeczytałem parę twoich
odpowiedzi na Quorze. Czujesz się stalkowany?

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

do góry

> Nie wiem, czy to wyczerpuje temat, ale na pewno jest
> przykładem czegoś, co zwiększa ilość rzeczy, które możemy
> statycznie powiedzieć o naszym programie.

Zwiększa względem czego?
Względem w ogóle braku takich mechizmów? Tak. Jest to postęp.
Względem pre- i post-conditions? Nie widzę tego.

Mam wrażenie, że języki funkcjonalne za bardzo fiksują się na pojęciu typu. O ile typ
nadaje się do opisania dozwolonych stanów, to nie za bardzo nadaje się do opisania
przejść między stanami.

> Jest też język ATS (trochę protoplasta Rusta), który
> ma system "typów liniowych" służących do wyrażania twierdzeń
> o poprawności korzystania z zasobów. Ale wydaje się raczej
> trudny do używania:

Skoro jest trudny, to tym bardziej nie ma szans na rynkową akceptację.

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

do góry

> Co? To niby na mainframes nie bylo projektow krytycznych/fault tolerant?
> Nie bylo np. AS400 itp, a toto wcalenie bylo tworzone w C/C++.

Nie wiem, ale tutaj:

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

jest:

"The AS/400 operating system was originally named OS/400"

a tutaj:

http://www.stroustrup.com/applications.html

OS/400 jest wymieniony jako zrobiony w C++.

Niemniej, pisząc "systemy krytyczne" miałem na myśli takie, które zabijają ludzi i z
racji tego podlegają certyfikacji. Obecne wymagania dla takich systemów są takie, że
kod obiektowy ma być w pełni pokryty testami oraz ma istnieć śladowanie
(traceability) pomiędzy kodem źródłowym a tym kodem obiektowym. Da się to spełnić
językami imperatywnymi, w których nie ma niejawnych operacji albo ukrytych ścieżek.
Mamy tu *podzbiory* C, C++, Ady oraz wspomnianych przez Ciebie Modula, Pascal i im
podobnych.

> W kwestii Ady nie do konca sie zgodze. To jednak o wiele wyzszy poziom
> jezyka niz assemblerowate C/C++.

Nie w tym kontekście. Wsparcie dla modułów czy kontrola dostępu albo typy z zakresami
to nie jest dla mnie wyższy poziom języka. Masz na myśli jakieś inne cechy?

> No a co np. z Modula2?. Kiedys przez lata de-facto standard w RealTime?

No i co nim? No był taki język. Najwyraźniej nic nie wnosił. W sumie - nie potrzeba
nam 10 podobnych do siebie języków.

> > Z C++ też się da, przy starannie wybranym podzbiorze języka.
>
> PoMISRAny C czy C++ to juz wlasciwie nie jest C/C++ tylko calkiem inny
> jezyk (tez oczywiscie potworek).

Żaden język nie może być użyty w całości. To zawsze jest starannie dobrany podzbiór -
tak, aby dało się spełnić wymogi procesów certyfikacyjnych.
A MISRA to nie jest poważne i kompleksowe rozwiązanie problemu. Jeśli większość
obowiązkowych reguł jest jednocześnie "undecidable" (!), to widać, że to jest tylko
wstęp do dalszych rozważań a nie jakaś broń ostateczna.

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

do góry

W dniu środa, 21 listopada 2018 22:28:05 UTC+1 użytkownik Maciej Sobczak napisał:
> > Nie wiem, czy to wyczerpuje temat, ale na pewno jest
> > przykładem czegoś, co zwiększa ilość rzeczy, które możemy
> > statycznie powiedzieć o naszym programie.
>
> Zwiększa względem czego?
> Względem w ogóle braku takich mechizmów? Tak. Jest to postęp.
> Względem pre- i post-conditions? Nie widzę tego.

Co masz na myśli mówiąc o pre- i post-conditions?
Jaki język?

> Mam wrażenie, że języki funkcjonalne za bardzo fiksują się na pojęciu typu. O ile
typ nadaje się do opisania dozwolonych stanów, to nie za bardzo nadaje się do
opisania przejść między stanami.

To trochę takie pisanie palcem na piasku.
Jak byś przedstawił konkretne przykłady, to może moglibyśmy
spróbować podyskutować.

> > Jest też język ATS (trochę protoplasta Rusta), który
> > ma system "typów liniowych" służących do wyrażania twierdzeń
> > o poprawności korzystania z zasobów. Ale wydaje się raczej
> > trudny do używania:
>
> Skoro jest trudny, to tym bardziej nie ma szans na rynkową akceptację.

Nie ma żadnych szans. To jest risercz, i wcale nie udaje, że
próbuje być czymś więcej. Ale może można stamtąd wydobyć jakieś
wartościowe pomysły.

do góry

> Co masz na myśli mówiąc o pre- i post-conditions?
> Jaki język?

No właśnie dowolny i to jest ich zaletą, bo koncepcję można dokleić do dowolnego
języka, również do rzeczy, które niekoniecznie byśmy od razu skojarzyli z językiem
programowania, np. opis maszyny stanów.

https://en.wikipedia.org/wiki/Precondition
https://en.wikipedia.org/wiki/Postcondition

Tu jest kilka przykładów w SPARKu, zobacz gdzie są i jaką rolę pełnią słowa Pre i
Post w tych przykładach.

Da się to nawet dokleić do języka C, patrz np. Frama-C.

> > Mam wrażenie, że języki funkcjonalne za bardzo fiksują się na pojęciu typu. O ile
typ nadaje się do opisania dozwolonych stanów, to nie za bardzo nadaje się do
opisania przejść między stanami.
>
> To trochę takie pisanie palcem na piasku.
> Jak byś przedstawił konkretne przykłady, to może moglibyśmy
> spróbować podyskutować.

Przykład jest taki, że światło na skrzyżowaniu może być czerwone, żółte, zielone,
żółto-czerwone albo migające. To jest zbiór wartości, daje się to opisać typem
wyliczeniowym.
Da się też napisać funkcję zmieniającą stan świateł albo zwracającą kolejny stan w
sekwencji, itp. Wiem, jak ładnie napisać system obsługujący np. szlaban na
przejeździe kolejowym przy użyciu takich pojęć jak pre- i post-conditions, po te
pojęcia nadają się do pracy z systemami, w których np. coś ma być spełnione żeby coś
mogło być po czymś. Tu pojęcia "przed" i "po" pojawiają się naturalnie i podobnie
jest w każdym innym systemie, dającym się opisać maszyną stanów (pralka, zmywarka,
skrzynia biegów, samolot, itd.).

Widziałem kilka teoretycznych przykładów z dependent types, ale żadnego praktycznego,
który mógłby pomóc w takich właśnie stanowo-sekwencyjnych systemach. A łaśnie takie
są w systemach krytycznych, bo przypadkiem ich krytyczność wynika z tego, że są
związane z procesami fizycznymi, w których jest czas a jak jest czas, to jest też
"pre" i "post".
Właśnie dlatego wsparcie dla "pre" i "post" w języku programowania jest czymś bardzo
cennym. Pytanie, czy dependent types cokolwiek tu jeszcze wnoszą, czego nie da się
pokryć samym "pre" i "post".

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

do góry