W dniu czwartek, 22 listopada 2018 11:31:21 UTC+1 użytkownik Maciej Sobczak napisał:
> > 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

mz to duzo teorii nie rokujacej na spektakularne efekty...

jesli zajmowac sie teoria to polecam jakas lepsza...np to co mowilem o obsludze
bledow w poprawionym c z ta klauzula on_error duzo lepsze

bo teoria trzeba sie zajmowac albo porzadna albo lepiej wcale i lepiej
pisac jakis konkretny kod

zaluje ze nie rozmawia sie tu o konkretnych problemach z kodu...

np godek jesli by naswietlil jakie ma problemy z tymi figurkami w 3d i co konkretnie
chce zrobic moze po zastanowieniu sie ozna by cos obgadac..
sam jak pisalem sam troche chcialbym sie zajmowac czyms podobnym (miedzy innymi()
tyle ze u mie to nie tyle wzgledby ruch/mechanika czesci w jakiejs figurce 3d tylko
raczej fajne dobrze wygladajace
ruchy/mechanika tych obiektow w przestrzeni - bo dzis ruchy obiektow w 3d
nawet w grach AAA wygladaja mi na predefiniowane i toporne...fajnie by bylo zrobic
cos co naprawde by sie dobrze ruszalo ;c

z tym ze w sumie nie wiem czy mam na to czas

do góry

On 2018-11-21 22:48, Maciej Sobczak wrote:
> a tutaj:
>
> http://www.stroustrup.com/applications.html
>
> OS/400 jest wymieniony jako zrobiony w C++.

Ot chorendalna manipulacja.
C/C++ do OS/400 dodano znaaaacznie pozniej jako jeszcze jeden
jezyk aplikacyjny.
Jest wierutna bzdura, ze w nim napisano OS/400.

PS: Dla "znawcow" co to nie lubia bytecode(s) (bo wolne itp.):
Caly OS/400 jest oparty na bytecode.
Wszystkie kompilatory w nim produkuja _wlasnie_ bytecode.

AK

do góry

On 19/11/2018 17:15, g...@g...com wrote:
> W gcc masz feature o nazwie 'statement expressions'

Piszę multiplatformowo.

do góry

On 19/11/2018 08:14, Maciej Sobczak wrote:
> assert(dowolnyfragmentkodu, wynik_bool);
> I użyć tego tak:
> assert(
> int i; // albo inne definicje

Coverage i lint to widzą. Asercje przy statycznej analizie bywają
niespełnialne a przy dynamicznej generują fałszywe wyniki pokrycia.
Dlatego to musi by ficzer języka. Wiec nie tylko poszerzamy składnię ale
musielibyśmy upoewnić się że takie narzędzia jak gcov i podobne nie
zobaczą tego kodu nawet w debugu. Tak więc to troche złożony problem.
Nie liczę że się kiedykolwiek doczekam.

do góry

On Tuesday, November 20, 2018 at 12:00:50 AM UTC+1, AK wrote:
> On 2018-11-19 21:18, s...@g...com wrote:
> >> Warto przyjrzeć się językowi Idris i typom zależnym. Twórca Idris, Edwin Brady,
> >> opowiada tutaj o nim z humorem:
> >> https://www.youtube.com/watch?v=zSsCLnLS1hg
> >
> > Po po pierwsze, primo:
> > 1. C++ jest zupełnie wystarczający do wszystkiego.
>
> Boze jedyny... to juz nie jest odlot.
> To niczym nie skazone wstecznictwo i betoniarstwo - wlasciwie
> eliminujace z zawodu zwanego programostą.

Niestety, w tym zdaniu szyka jest dużo prawdy, zastąpiłbym tylko słowo "wszystkiego"
zwrotem "wszystkiego za co płacą całkiem nieźle". C++ mimo swojej wielopoziomowej
koślawości wygrywa, m.in. dlatego, że stoją za nim duże firmy, które inwestują w
rozwój i promocję. Jest takie ładne określenie cubic dollars.

To prawda, że C++ jest technologicznie zapóźniony o jakieś 10-20 lat, ale powoli
nadrabia (i nawet wygląda na to, że komitet sobie z tego zdaje sprawę). To prawda, że
można w C++ pisać w popieprzony sposób, ale na szczęście nikt nie zmusza.

Alternatywy się nie przebiły, mimo teoretycznej lepszości i często wielkiego szumu.
Np. taki D chyba już zdechł odkąd Facebook przestał go promować. Go był pomyślany
jako zastępstwo dla C++ - moduły, współbieżność, odśmiecanie pamięci. Czyli niby
bolączki C++, ale fakty są takie, że do Go poszli phppwcy, pythoniarze,
javascriptowcy. Bo język prosty, ale kompilowany więc szybszy. Ada? No jest gdzieś
tam[1]. Rust? Nie powala i poza Mozillą i podjaranymi studentami nikt tego poważnie
nie używa.

Niestety, jesteśmy skazani na C++. I być może w wersji C++27 będzie już całkiem
dobry. ;)

w.

[1] taka historyjka: pewna zachodnia firma chciała przenieść do Polski utrzymanie
adowego projektu, ale... nie było u nas wystarczającej liczby programistów.

do góry

On 2018-11-22 22:53, Wojciech Muła wrote:
> Go poszli phppwcy, pythoniarze, javascriptowcy. Bo język prosty, ale kompilowany
więc szybszy.

Nie. Nie dlatego.
Glownie dlatego, ze sedno go to b.dobre asychro (goroutines).
(z tego powodu sam pobawie sie jeszcze w Go przed emerytura).

PS: Powrot do "przyszlosci" - pomyslec, ze asynchro/multitasking oparte
na korutynach bylo "immanentna" ustandaryzowana czescia Simuli67.
No tak.. ale przyszly XT i zabily nie tylko Simule67 ale i ine porzadne
j.prog.

AK

do góry

On 2018-11-22 22:53, Wojciech Muła wrote:
> Niestety, jesteśmy skazani na C++. I być może w wersji C++27 będzie już całkiem
dobry.;)

Tu sie zgodzę (lubię żyć nadzieją:)
PS: Na szczęście wtedy już będę w krainie wiecznych kompilatorów...

AK

do góry

On 2018-11-23 00:41, AK wrote:
> Niestety, jesteśmy skazani na C++.
Poprawka.
1. Siebie wykluczam
2. Wcale nie jestesmy skazani (jest .NET, jest Java).

AK

do góry

W dniu piątek, 23 listopada 2018 00:43:51 UTC+1 użytkownik AK napisał:
> On 2018-11-23 00:41, AK wrote:
> > Niestety, jesteśmy skazani na C++.
> 2. Wcale nie jestesmy skazani (jest .NET, jest Java).

Przecież to syf w porównaniu do C++ z Qt...

do góry

On Friday, November 23, 2018 at 12:43:51 AM UTC+1, AK wrote:
> On 2018-11-23 00:41, AK wrote:
> > Niestety, jesteśmy skazani na C++.
> Poprawka.
> 1. Siebie wykluczam
> 2. Wcale nie jestesmy skazani (jest .NET, jest Java).

Ja dla zachowania równowagi psychicznej piszę w Pythonie. :)
Tam (prawie) wszystko jest jak powinno. Największy błąd
Pythona to dopuszczenie do powstania dwóch obozów py2 i py3.

Java to chyba teraz słaby pomysł po zmianach licencyjnych.

w.

do góry