Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #31990 > unrolled thread
| Started by | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| First post | 2018-11-16 00:27 -0800 |
| Last post | 2018-11-29 00:08 -0800 |
| Articles | 20 on this page of 91 — 10 participants |
Back to article view | Back to pl.comp.programming
Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-16 00:27 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-16 15:22 +0000
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-16 17:18 +0100
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-16 07:48 -0800
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-16 07:50 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-16 19:14 +0000
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-16 11:40 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-16 20:05 +0000
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-17 07:59 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-18 00:02 +0000
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-16 14:51 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-19 09:37 +0000
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-18 01:10 -0800
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-18 01:28 -0800
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-16 11:51 -0800
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-16 14:55 -0800
Re: Niezmienniki pętli Sebastian Biały <heby@poczta.onet.pl> - 2018-11-17 14:58 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-17 15:10 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-18 09:58 +0100
Re: Niezmienniki pętli Sebastian Biały <heby@poczta.onet.pl> - 2018-11-18 17:35 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-18 23:14 -0800
Re: Niezmienniki pętli Roman Tyczka <noemail@because.no> - 2018-11-19 09:22 +0100
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-19 08:15 -0800
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-19 10:45 -0800
Re: Niezmienniki pętli Sebastian Biały <heby@poczta.onet.pl> - 2018-11-22 18:50 +0100
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-19 10:49 -0800
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-19 12:18 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-19 20:44 +0000
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-19 13:10 -0800
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-19 13:16 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-20 09:43 +0000
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-20 01:58 -0800
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-20 14:27 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-21 10:12 +0000
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-21 11:35 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-21 21:10 +0000
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-21 02:36 -0800
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-19 14:12 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-20 00:20 +0100
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-20 09:35 +0000
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-20 12:00 +0100
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-19 20:37 -0800
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-20 13:46 -0800
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-20 01:46 -0800
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-20 12:52 -0800
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-20 13:16 -0800
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-20 06:07 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-20 17:54 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-20 23:16 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-21 15:54 +0100
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-21 16:07 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-21 13:48 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-22 16:08 +0100
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-20 00:00 +0100
Re: Niezmienniki pętli Wojciech Muła <wojtek.mula@gmail.com> - 2018-11-22 13:53 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-22 23:25 +0100
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 00:41 +0100
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 00:43 +0100
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-22 22:33 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 10:34 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-23 05:46 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 15:39 +0100
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 15:42 +0100
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 15:47 +0100
Re: Niezmienniki pętli Wojciech Muła <wojtek.mula@gmail.com> - 2018-11-23 10:54 -0800
Re: Niezmienniki pętli Borneq <borneq@antyspam.hidden.pl> - 2018-12-01 15:15 +0100
Re: Niezmienniki pętli Wojciech Muła <wojtek.mula@gmail.com> - 2018-12-01 11:50 -0800
Re: Niezmienniki pętli Borneq <borneq@antyspam.hidden.pl> - 2018-12-02 13:52 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-24 12:20 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 15:53 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-24 12:05 -0800
Re: Niezmienniki pętli Wojciech Muła <wojtek.mula@gmail.com> - 2018-11-26 02:01 -0800
Re: Niezmienniki pętli szykcech@gmail.com - 2018-11-23 08:42 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 19:42 +0100
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 19:43 +0100
Re: Niezmienniki pętli Wojciech Muła <wojtek.mula@gmail.com> - 2018-11-22 23:00 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 10:38 +0100
Re: Niezmienniki pętli Wojciech Muła <wojtek.mula@gmail.com> - 2018-11-23 04:08 -0800
Re: Niezmienniki pętli Wojciech Muła <wojtek.mula@gmail.com> - 2018-11-23 04:10 -0800
Re: Niezmienniki pętli AK <nobody@nowhere.net> - 2018-11-23 15:33 +0100
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-20 05:38 -0800
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-21 11:32 -0800
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-21 13:28 -0800
Re: Niezmienniki pętli godek.maciek@gmail.com - 2018-11-21 14:04 -0800
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-22 02:31 -0800
Re: Niezmienniki pętli fir <profesor.fir@gmail.com> - 2018-11-22 06:22 -0800
Re: Niezmienniki pętli Sebastian Biały <heby@poczta.onet.pl> - 2018-11-22 18:53 +0100
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-19 09:45 +0000
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-20 05:29 -0800
Re: Niezmienniki pętli queequeg@trust.no1 (Queequeg) - 2018-11-20 22:26 +0000
Re: Niezmienniki pętli Maciej Sobczak <see.my.homepage@gmail.com> - 2018-11-29 00:08 -0800
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-11-16 00:27 -0800 |
| Subject | Niezmienniki pętli |
| Message-ID | <8a836d02-2281-4fe5-9192-ab1f127a163d@googlegroups.com> |
Zastanawiam się, czy to jest pojęcie wyłącznie akademickie. W tzw. "normalnym" programowaniu, które praktykuje większość programistów, nigdy nie widziałem odwołania się do takiej koncepcji w sensie wykorzystania niezmienników w projektowaniu kodu. Jak programista ma do napisania pętlę, to w praktyce: - albo już pisał podobną i napisze jeszcze raz (to jest najczęstszy przypadek), - albo nie pisał, ale rozumie i napisze posługując się głównie intuicją (wtedy mamy frajdę, bo coś nowego), - albo nie rozumie i nie napisze. Niezmienniki pozwalają jednak pętlę zaprojektować albo przeanalizować i np. dojść do wniosku, że jest poprawna. Nie pytam o metody formalne, tylko o powiedzmy nieco bardziej świadomą praktykę programistyczną. Nazwijmy to ładnie "attentive engineering". Albo "mindful engineering". Pytanie jest takie: czy ktoś z Was spotkał się z tym pojęciem (poza szkołą) a nawet z niego skorzystał w praktyce? Czy to jest praktyka, do której staracie się sięgać w tym trzecim przypadku? A może bardziej regularnie? Czy może po prostu w ogóle temat jest oderwany od tzw. rzeczywistości? Ciekawi mnie Wasze spojrzenie na tą sprawę również wtedy, gdy piszecie w językach nie-imperatywnych, gdzie takich klasycznych pętli jest mniej albo w ogóle ich nie ma. Czy w związku z tym zagadnienie niezmienników jest niepotrzebne? A może nadal jest potrzebne i coś innego je zastępuje? Wersja dla quizowiczów: - wiem i używam albo pamiętam, że mogę, - słyszałem i ignoruję, - nie rozumiem pytania[*]. [*] https://en.wikipedia.org/wiki/Loop_invariant -- Maciej Sobczak * http://www.inspirel.com
[toc] | [next] | [standalone]
| From | queequeg@trust.no1 (Queequeg) |
|---|---|
| Date | 2018-11-16 15:22 +0000 |
| Message-ID | <2e7589ed-bbb3-4ee4-b687-a5aaa4c90902@trust.no1> |
| In reply to | #31990 |
Maciej Sobczak <see.my.homepage@gmail.com> wrote: > - wiem i używam albo pamiętam, że mogę, > - słyszałem i ignoruję, > - nie rozumiem pytania[*]. > > [*] https://en.wikipedia.org/wiki/Loop_invariant Nie słyszałem, teraz się dowiedziałem. Nigdy nie używałem. -- https://www.youtube.com/watch?v=9lSzL1DqQn0
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2018-11-16 17:18 +0100 |
| Message-ID | <psmql7$fct$1@gioia.aioe.org> |
| In reply to | #31991 |
On 2018-11-16 16:22, Queequeg wrote: > Maciej Sobczak <see.my.homepage@gmail.com> wrote: > >> - wiem i używam albo pamiętam, że mogę, >> - słyszałem i ignoruję, >> - nie rozumiem pytania[*]. >> >> [*] https://en.wikipedia.org/wiki/Loop_invariant > > Nie słyszałem, teraz się dowiedziałem. Nigdy nie używałem. Identycznie. No... prawie. "Widzialem" invariaty w Eifflu, ale w tym kontekscie nie/nie mialem pojecia, ze tak mozna i ze to cos daje. AK
[toc] | [prev] | [next] | [standalone]
| From | szykcech@gmail.com |
|---|---|
| Date | 2018-11-16 07:48 -0800 |
| Message-ID | <e3fc524a-21cf-4480-a62b-1eb5cffb0d9f@googlegroups.com> |
| In reply to | #31990 |
> Czy w związku z tym zagadnienie niezmienników jest niepotrzebne? A może nadal jest potrzebne i coś innego je zastępuje?
1. Wiedziałem co to jest.
2. Stosuję
3. Sam też stosujesz
Najprostrze zastosowanie:
QList<int> lList = {0, 1, 2, 3, 4, 5};
for(int i(0); i < lList.size(); ++i)
// tu robisz coś z lList
W tej pętli niezmiennikiem sprawdzanym przed wejściem w pętlę i po kazdej iteracji jest:
i < lList.size()
Nieco bardziej ogólne jest:
QList<int> lList = {0, 1, 2, 3, 4, 5};
for(int& lItem : lList)
// tu robisz coś z lItem
W tym przypadku niezmiennikiem (ukrytym) jest fakt iteracji po wszystkich elementach listy.
4. Zazwyczaj dalszych niezmienników w pętli nie sprawdzam. Głównie ze względu na 2 wady:
4.1. Puchnięcie i zaciemnianie kodu.
4.2. Spowolnienie programu.
5. Bardzo często sprawdzam parametry wejściowe funkcji (wierzę i stosuję coś w rodzaju programowania kontraktowego).
5.1. Wierzę w try, throw, catch (wyjątki obowiązkowo dziedziczone po std::exception z opisem i kodem błędu).
5.2. Nie wierzę w i nie cierpię Assert (to tak jak by bez ostrzeżenia uderzyć kogoś w twarz bez dalszego komentarza).
5.3. Toleruję wartości zwracane (jako informacje o błędach) i brak standaryzacji w dostępie do opisów błędów w Qt.
[toc] | [prev] | [next] | [standalone]
| From | szykcech@gmail.com |
|---|---|
| Date | 2018-11-16 07:50 -0800 |
| Message-ID | <03fd4d27-c126-484a-973b-60353fdc1bff@googlegroups.com> |
| In reply to | #31992 |
> wierzę i stosuję coś w rodzaju programowania kontraktowego https://pl.wikipedia.org/wiki/Programowanie_kontraktowe
[toc] | [prev] | [next] | [standalone]
| From | queequeg@trust.no1 (Queequeg) |
|---|---|
| Date | 2018-11-16 19:14 +0000 |
| Message-ID | <37f14fe1-4023-4ed6-90d8-e3f4be3990ba@trust.no1> |
| In reply to | #31992 |
szykcech@gmail.com wrote:
> Najprostrze zastosowanie:
^^
sz
> for(int i(0); i < lList.size(); ++i)
> // tu robisz coś z lList
> W tej pętli niezmiennikiem sprawdzanym przed wejściem w pętlę i po kazdej iteracji jest:
> i < lList.size()
"In computer science, a loop invariant is a property of a program loop
that is true before (and after) each iteration."
Twierdzisz, że po ostatniej iteracji pętli i < lList.size() będzie dalej
true?
Nie myl niezmiennika z warunkiem kontynuowania pętli.
> 5.2. Nie wierzę w i nie cierpię Assert (to tak jak by bez ostrzeżenia
> uderzyć kogoś w twarz bez dalszego komentarza).
Czyli twoim zdaniem lepiej, gdy program działa dalej na błędnych danych i
w sposób, którego nie przewidział programista, niż gdy wypisze komunikat
o błędzie wraz z lokalizacją, niespełnionym warunkiem i np. innymi
informacjami diagnostycznymi i zakończy się, nie robiąc szkód?
Bo wiesz, oprogramowanie się testuje, takie błędy wychodzą i takie błędy
się poprawia, zamiast ignorować.
--
https://www.youtube.com/watch?v=9lSzL1DqQn0
[toc] | [prev] | [next] | [standalone]
| From | szykcech@gmail.com |
|---|---|
| Date | 2018-11-16 11:40 -0800 |
| Message-ID | <ffd7e8da-43ff-4f50-af4d-f8f4aa3fe7a8@googlegroups.com> |
| In reply to | #31995 |
W dniu piątek, 16 listopada 2018 20:14:23 UTC+1 użytkownik Queequeg napisał: > szykcech@gmail.com wrote: > > > Najprostrze zastosowanie: > ^^ > sz > > > for(int i(0); i < lList.size(); ++i) > > // tu robisz coś z lList > > W tej pętli niezmiennikiem sprawdzanym przed wejściem w pętlę i po kazdej iteracji jest: > > i < lList.size() > > "In computer science, a loop invariant is a property of a program loop > that is true before (and after) each iteration." > > Twierdzisz, że po ostatniej iteracji pętli i < lList.size() będzie dalej > true? > > Nie myl niezmiennika z warunkiem kontynuowania pętli. Ok! W takim razie nie używam niezmienników pętli ani niezmienników klas. Za wolne to jest na wersję release. Może warto by było to pisać w blokach kompilowanych warunkowo. > > 5.2. Nie wierzę w i nie cierpię Assert (to tak jak by bez ostrzeżenia > > uderzyć kogoś w twarz bez dalszego komentarza). > > Czyli twoim zdaniem lepiej, gdy program działa dalej na błędnych danych i > w sposób, którego nie przewidział programista, niż gdy wypisze komunikat > o błędzie wraz z lokalizacją, niespełnionym warunkiem i np. innymi > informacjami diagnostycznymi i zakończy się, nie robiąc szkód? > > Bo wiesz, oprogramowanie się testuje, takie błędy wychodzą i takie błędy > się poprawia, zamiast ignorować. Czytaj ze zrozumieniem: > 5.1. Wierzę w try, throw, catch (wyjątki obowiązkowo dziedziczone po std::exception z opisem i kodem błędu).
[toc] | [prev] | [next] | [standalone]
| From | queequeg@trust.no1 (Queequeg) |
|---|---|
| Date | 2018-11-16 20:05 +0000 |
| Message-ID | <983e5c75-36ab-47ae-bce5-aeaa5092a748@trust.no1> |
| In reply to | #31997 |
szykcech@gmail.com wrote: >> Nie myl niezmiennika z warunkiem kontynuowania pętli. > > Ok! W takim razie nie używam niezmienników pętli ani niezmienników klas. > Za wolne to jest na wersję release. Może warto by było to pisać w > blokach kompilowanych warunkowo. Pytanie czy w danym zastosowaniu prędkość wykonania jest krytyczna, czy może poprawność jest ważniejsza... >> Czyli twoim zdaniem lepiej, gdy program działa dalej na błędnych danych i >> w sposób, którego nie przewidział programista, niż gdy wypisze komunikat >> o błędzie wraz z lokalizacją, niespełnionym warunkiem i np. innymi >> informacjami diagnostycznymi i zakończy się, nie robiąc szkód? >> >> Bo wiesz, oprogramowanie się testuje, takie błędy wychodzą i takie błędy >> się poprawia, zamiast ignorować. > > Czytaj ze zrozumieniem: >> 5.1. Wierzę w try, throw, catch (wyjątki obowiązkowo dziedziczone po std::exception z opisem i kodem błędu). Ok, to spytam inaczej: czym, wg ciebie, jest asercja? (dla uproszczenia: mówię o asercji sprawdzanej w czasie wykonania, nie o statycznej, sprawdzanej w czasie kompilacji) -- https://www.youtube.com/watch?v=9lSzL1DqQn0
[toc] | [prev] | [next] | [standalone]
| From | szykcech@gmail.com |
|---|---|
| Date | 2018-11-17 07:59 -0800 |
| Message-ID | <700d89a8-25cd-414d-be05-d9d8a692df3a@googlegroups.com> |
| In reply to | #31999 |
> >> Czyli twoim zdaniem lepiej, gdy program działa dalej na błędnych danych i > >> w sposób, którego nie przewidział programista, niż gdy wypisze komunikat > >> o błędzie wraz z lokalizacją, niespełnionym warunkiem i np. innymi > >> informacjami diagnostycznymi i zakończy się, nie robiąc szkód? > >> > >> Bo wiesz, oprogramowanie się testuje, takie błędy wychodzą i takie błędy > >> się poprawia, zamiast ignorować. > > > > Czytaj ze zrozumieniem: > >> 5.1. Wierzę w try, throw, catch (wyjątki obowiązkowo dziedziczone po std::exception z opisem i kodem błędu). > > Ok, to spytam inaczej: czym, wg ciebie, jest asercja? > > (dla uproszczenia: mówię o asercji sprawdzanej w czasie wykonania, nie o > statycznej, sprawdzanej w czasie kompilacji) Czytaj ze zrozumieniem: > 5.2. Nie wierzę w i nie cierpię Assert (to tak jak by bez ostrzeżenia uderzyć kogoś w twarz bez dalszego komentarza).
[toc] | [prev] | [next] | [standalone]
| From | queequeg@trust.no1 (Queequeg) |
|---|---|
| Date | 2018-11-18 00:02 +0000 |
| Message-ID | <18a8f5d1-2f3e-4ee9-843f-8a9cf67d69a1@trust.no1> |
| In reply to | #32007 |
szykcech@gmail.com wrote: >> Ok, to spytam inaczej: czym, wg ciebie, jest asercja? >> >> (dla uproszczenia: mówię o asercji sprawdzanej w czasie wykonania, nie o >> statycznej, sprawdzanej w czasie kompilacji) > > Czytaj ze zrozumieniem: >> 5.2. Nie wierzę w i nie cierpię Assert (to tak jak by bez ostrzeżenia uderzyć kogoś w twarz bez dalszego komentarza). Dopytuję bo mam wrażenie, że masz bardzo mgliste pojęcie o tym, czym jest asercja. O static assert słyszałeś? -- https://www.youtube.com/watch?v=9lSzL1DqQn0
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-11-16 14:51 -0800 |
| Message-ID | <7ed2c66d-6aeb-481f-8352-d8d72ce9b64f@googlegroups.com> |
| In reply to | #31992 |
> Najprostrze zastosowanie:
> QList<int> lList = {0, 1, 2, 3, 4, 5};
> for(int i(0); i < lList.size(); ++i)
> // tu robisz coś z lList
> W tej pętli niezmiennikiem sprawdzanym przed wejściem w pętlę i po kazdej iteracji jest:
> i < lList.size()
Tak jak już zauważył Queequeg, to nie jest niezmiennik. W ogóle we wzorcu projektowym o nazwie "jadę po kontenerze" nie ma niezmienników, chyba że weźmiemy pod uwagę następujący:
- elementy o indeksach większych od i nie zostały jeszcze odwiedzone
Ale taki niezmiennik (chociaż prawdziwy) jest sztuczny i nic nie wnosi.
Ciekawsze są niezmienniki w tych pętlach, które swoim działaniem budują jakiś wynik i ten wynik ma jakąś ważną stałą cechę. Np. zewnętrzna pętla w algorytmie sortowania przez wybieranie ma taki niezmiennik:
- elementy o indeksach mniejszych od i są już posortowane
I taki niezmiennik jest już ciekawszy, bo bez patrzenia na algorytm jako całość pozwala uzasadnić, że ta całość faktycznie coś sortuje.
Ale jak rozumiem z sondażu, nikt tego nie stosuje. Pewnie ma to związek z faktem, że algorytm sortowania przez wybieranie już został wymyślony. :-)
> 5.2. Nie wierzę w i nie cierpię Assert (to tak jak by bez ostrzeżenia uderzyć kogoś w twarz bez dalszego komentarza).
To też jest ciekawe. Zwłaszcza, że assert statyczny i dynamiczny to nie to samo.
--
Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | queequeg@trust.no1 (Queequeg) |
|---|---|
| Date | 2018-11-19 09:37 +0000 |
| Message-ID | <a626b38c-af85-4185-abca-c065465abb1d@trust.no1> |
| In reply to | #32003 |
Maciej Sobczak <see.my.homepage@gmail.com> wrote: > Ale jak rozumiem z sondażu, nikt tego nie stosuje. Pewnie ma to związek > z faktem, że algorytm sortowania przez wybieranie już został wymyślony. > :-) Jedyne co stosuję bliskiego takim niezmiennikom to asercje :) >> 5.2. Nie wierzę w i nie cierpię Assert (to tak jak by bez ostrzeżenia uderzyć kogoś w twarz bez dalszego komentarza). > > To też jest ciekawe. Zwłaszcza, że assert statyczny i dynamiczny to nie to samo. Dowodzi jedynie tego, że szyk ma błędne pojęcie o tym, czym jest assert dynamiczny (a statycznego nigdy nie stosował). -- https://www.youtube.com/watch?v=9lSzL1DqQn0
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-11-18 01:10 -0800 |
| Message-ID | <10a90cdd-3227-4a62-95e2-1097e0e4e28a@googlegroups.com> |
| In reply to | #31992 |
W dniu piątek, 16 listopada 2018 16:48:18 UTC+1 użytkownik szyk...@gmail.com napisał:
> > Czy w związku z tym zagadnienie niezmienników jest niepotrzebne? A może nadal jest potrzebne i coś innego je zastępuje?
>
> 1. Wiedziałem co to jest.
>
> 2. Stosuję
>
> 3. Sam też stosujesz
>
> Najprostrze zastosowanie:
> QList<int> lList = {0, 1, 2, 3, 4, 5};
> for(int i(0); i < lList.size(); ++i)
> // tu robisz coś z lList
> W tej pętli niezmiennikiem sprawdzanym przed wejściem w pętlę i po kazdej iteracji jest:
> i < lList.size()
>
> Nieco bardziej ogólne jest:
> QList<int> lList = {0, 1, 2, 3, 4, 5};
> for(int& lItem : lList)
> // tu robisz coś z lItem
> W tym przypadku niezmiennikiem (ukrytym) jest fakt iteracji po wszystkich elementach listy.
>
> 4. Zazwyczaj dalszych niezmienników w pętli nie sprawdzam. Głównie ze względu na 2 wady:
> 4.1. Puchnięcie i zaciemnianie kodu.
> 4.2. Spowolnienie programu.
>
> 5. Bardzo często sprawdzam parametry wejściowe funkcji (wierzę i stosuję coś w rodzaju programowania kontraktowego).
> 5.1. Wierzę w try, throw, catch (wyjątki obowiązkowo dziedziczone po std::exception z opisem i kodem błędu).
> 5.2. Nie wierzę w i nie cierpię Assert (to tak jak by bez ostrzeżenia uderzyć kogoś w twarz bez dalszego komentarza).
> 5.3. Toleruję wartości zwracane (jako informacje o błędach) i brak standaryzacji w dostępie do opisów błędów w Qt.
ostatnio odkrylem dosyc odkrywczy sposob
dilowania (tj forme kodowanie obslugi bledow) z bledami w jezykach podobnych
do c
wymaga on pewnej poprawki do jezyka,
(i jest opisany na clc, troche nie che mi sie tu opisywac bo nie lubie sie powtarzac)
jest on ogolnie ciekawy bo mz pokazuje co to jest normalne dilowanie z bledami i na czym to normalne dilowanie z bledami normalnie polega (ma polegac)
nawiasem mowiac w swietle tego asercje
albo bledy przypadkowe (jak np zmienienie sie jakiejs komorki w rami i wyjatek typu nielegalna instrukcja) nie sa normalnymi sposobami dilowania z bledami tylko pewnymi case'ami nadspecjalnymi
NORMALNY i najbardziej typowy sposob z
handlowaniem z bledami w programie to zwykle zwrocenie informacji o bledzie do funkcji w tyl - tylko ze nie powinno to byc mieszane ze zwracaniem poprawnej wartosci w tym kanale w ktorym zwraca sie wartosci w sytuacjach niebledowych..
dzis jesli ktos zwraca blad w tyl (jak rozne api robia) to ogolnie robi dobrze,
tylko ze jesli wtyka kody bledow w wartosci zwracane to zarazem robi zle ;c
https://groups.google.com/forum/#!topic/comp.lang.c/p1CcmgZKkV4
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-11-18 01:28 -0800 |
| Message-ID | <dfa01153-cb6f-4479-b360-b229b5efcfb6@googlegroups.com> |
| In reply to | #32011 |
W dniu niedziela, 18 listopada 2018 10:10:22 UTC+1 użytkownik fir napisał:
> W dniu piątek, 16 listopada 2018 16:48:18 UTC+1 użytkownik szyk...@gmail.com napisał:
> > > Czy w związku z tym zagadnienie niezmienników jest niepotrzebne? A może nadal jest potrzebne i coś innego je zastępuje?
> >
> > 1. Wiedziałem co to jest.
> >
> > 2. Stosuję
> >
> > 3. Sam też stosujesz
> >
> > Najprostrze zastosowanie:
> > QList<int> lList = {0, 1, 2, 3, 4, 5};
> > for(int i(0); i < lList.size(); ++i)
> > // tu robisz coś z lList
> > W tej pętli niezmiennikiem sprawdzanym przed wejściem w pętlę i po kazdej iteracji jest:
> > i < lList.size()
> >
> > Nieco bardziej ogólne jest:
> > QList<int> lList = {0, 1, 2, 3, 4, 5};
> > for(int& lItem : lList)
> > // tu robisz coś z lItem
> > W tym przypadku niezmiennikiem (ukrytym) jest fakt iteracji po wszystkich elementach listy.
> >
> > 4. Zazwyczaj dalszych niezmienników w pętli nie sprawdzam. Głównie ze względu na 2 wady:
> > 4.1. Puchnięcie i zaciemnianie kodu.
> > 4.2. Spowolnienie programu.
> >
> > 5. Bardzo często sprawdzam parametry wejściowe funkcji (wierzę i stosuję coś w rodzaju programowania kontraktowego).
> > 5.1. Wierzę w try, throw, catch (wyjątki obowiązkowo dziedziczone po std::exception z opisem i kodem błędu).
> > 5.2. Nie wierzę w i nie cierpię Assert (to tak jak by bez ostrzeżenia uderzyć kogoś w twarz bez dalszego komentarza).
> > 5.3. Toleruję wartości zwracane (jako informacje o błędach) i brak standaryzacji w dostępie do opisów błędów w Qt.
>
> ostatnio odkrylem dosyc odkrywczy sposob
> dilowania (tj forme kodowanie obslugi bledow) z bledami w jezykach podobnych
> do c
>
> wymaga on pewnej poprawki do jezyka,
>
> (i jest opisany na clc, troche nie che mi sie tu opisywac bo nie lubie sie powtarzac)
>
> jest on ogolnie ciekawy bo mz pokazuje co to jest normalne dilowanie z bledami i na czym to normalne dilowanie z bledami normalnie polega (ma polegac)
>
> nawiasem mowiac w swietle tego asercje
> albo bledy przypadkowe (jak np zmienienie sie jakiejs komorki w rami i wyjatek typu nielegalna instrukcja) nie sa normalnymi sposobami dilowania z bledami tylko pewnymi case'ami nadspecjalnymi
>
> NORMALNY i najbardziej typowy sposob z
> handlowaniem z bledami w programie to zwykle zwrocenie informacji o bledzie do funkcji w tyl - tylko ze nie powinno to byc mieszane ze zwracaniem poprawnej wartosci w tym kanale w ktorym zwraca sie wartosci w sytuacjach niebledowych..
>
> dzis jesli ktos zwraca blad w tyl (jak rozne api robia) to ogolnie robi dobrze,
> tylko ze jesli wtyka kody bledow w wartosci zwracane to zarazem robi zle ;c
>
> https://groups.google.com/forum/#!topic/comp.lang.c/p1CcmgZKkV4
albo ok niech, bedzie opisze po polsku
sposob polage on na tym
int x = foo(20,10) on error { printf("error"); }
polaga on na tym ze wywolanie kazdej funkcja ktora moze zwrocic error powinno
obsluzyc branch tj wstawic tam dowolny kod do obslugi bledu
po stronie ciala funkcji wyglada to tak ze, wychodzisz z funkcji nie przez return ale inne slowo kluczowe np error
int foo(int a, int b)
{
if(a<b) error;
return a-b;
}
implementacja, ustawiasz po wyjsciu z funkcji jakas flage, np carry, zero czy cos w tym stylu
niektore zalety
1. musisz jawnie napisac klauzule obslugi bledu (zacheca do klarownej obslugi)
2. w ciele wolanej funkcji obsluga bledow jest dosyc jasna i klarowna (zacheca do klarownej obslugi)
obie strony zachecaja do klarownej obslugi, po prostu kodowanie bledow jako normalnych stanow programu do czego obecne c jakos nie zacheca
jest to wielka zaleta ... kody sa bardziej kompletne, moga byc 'zamniete na bledy'
3. nie mieszasz wartosci zwracanej i kodu bledu (to mieszanie to syf)
jest to wielka zaleta ... kody sa czystsze
4. skladania jest wzglednie ladna (moze poprobuje poprawic to wyzej to draft)
(napewno sprobuje poprawic bo to zarys, nie wiem np co z tymi domyslnymi sygnalami, tj ze skladnia do tego o czym troche nizej)
5.jest szybkie w runtime (chyba szybciej nie mozna, nie jestem pewien, kiedys mozna pomyslec)
6, rozwiazuje duzo abstrakcyjnego chaosu, bo ludzi zastaawiaja sie jak dilowac z bledami to jest tak naprawde poprawny sposob
to jest tez duza zaleta boludzi emaja sporo problemow ze zrozumieniem co robic z bledami - to co ja tutaj proponuje jest tak naprawde dosyc poprawneym rozwiazaniem - zwracasz bald wyzej, kod wywolywacza podejmie decyzje
dopuszczam lub rozwazam jeszcze opcje dla super leniwych, opcje opuszczania tych klauzul (ew jakiegos zaznaczania ze sa opuszczane, nie ejestem pewien) w takim wypadku, na kazdy zwrocony a nie zbranczowany blad lecialby sygnal do zarejsetrowanego handlera eventow - co tez jest wygodne jak ktos jest superleniwy
pytaniem jest troche 1) czy dopuszczac opuszczanie tych branczy czy raczej to poprostu zawsze wymuszac (do tego zdanie moga byc podzielone, ale raczej wydaje sie ze na specjalna prosbe autora kodu przynajmniej (jakas opcja kompilaci czy cos nalezy na o dozwolic)) 2) drygie pytanie czy na takie opuszczenie kompletnie ignorowac te brancze czy zmuszac do oznaczania jakims prostym slowem , chocby "SIG" zeby bylo wiadome
ze blad teoretycznie moez poleciec 3)
trzecie pytanie co robic w wypadku gdy taki nieobsluzony blad poleci, najrozsadzniejsza opcja chyba wydaje sie wywalanie signal handlera z jakims domyslnym kodem w tym handlerze (typu wywalenie message boxa z informacja
"error taki a taki w funkcji takiej a takiej zwrocony przez funkcje taka a taka, nacisnij ok by zamknac program (ignoruj by zignorowac?"
lekko otwarta kwestia jest tez w jakis sporob te polecenie arror powinny zwracac info o bledzie oraz co robic z wartoscia zwracana w tym wypadku (w duchu starego c znaczyloby chyba ze jest undefined, ale ew mozna wymyslec cos innego)
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2018-11-16 11:51 -0800 |
| Message-ID | <7b5d82e1-72bb-4d42-96cb-0091385d7ef6@googlegroups.com> |
| In reply to | #31990 |
W dniu piątek, 16 listopada 2018 09:27:41 UTC+1 użytkownik Maciej Sobczak napisał: > Zastanawiam się, czy to jest pojęcie wyłącznie akademickie. > > W tzw. "normalnym" programowaniu, które praktykuje większość programistów, nigdy nie widziałem odwołania się do takiej koncepcji w sensie wykorzystania niezmienników w projektowaniu kodu. > Jak programista ma do napisania pętlę, to w praktyce: > - albo już pisał podobną i napisze jeszcze raz (to jest najczęstszy przypadek), > - albo nie pisał, ale rozumie i napisze posługując się głównie intuicją (wtedy mamy frajdę, bo coś nowego), > - albo nie rozumie i nie napisze. > > Niezmienniki pozwalają jednak pętlę zaprojektować albo przeanalizować i np. dojść do wniosku, że jest poprawna. > Nie pytam o metody formalne, tylko o powiedzmy nieco bardziej świadomą praktykę programistyczną. Nazwijmy to ładnie "attentive engineering". Albo "mindful engineering". > > Pytanie jest takie: czy ktoś z Was spotkał się z tym pojęciem (poza szkołą) a nawet z niego skorzystał w praktyce? Czy to jest praktyka, do której staracie się sięgać w tym trzecim przypadku? A może bardziej regularnie? > > Czy może po prostu w ogóle temat jest oderwany od tzw. rzeczywistości? > > Ciekawi mnie Wasze spojrzenie na tą sprawę również wtedy, gdy piszecie w językach nie-imperatywnych, gdzie takich klasycznych pętli jest mniej albo w ogóle ich nie ma. Czy w związku z tym zagadnienie niezmienników jest niepotrzebne? A może nadal jest potrzebne i coś innego je zastępuje? > > Wersja dla quizowiczów: > - wiem i używam albo pamiętam, że mogę, > - słyszałem i ignoruję, > - nie rozumiem pytania[*]. > > [*] https://en.wikipedia.org/wiki/Loop_invariant > > -- > Maciej Sobczak * http://www.inspirel.com Kevlin Henney poruszył ten temat w jednej z prezentacji, pokazując związek logiki Hoare'a z "metodyką" "given-when-then" stosowaną przy pisaniu testów: https://www.youtube.com/watch?v=JiQct3QixMo Jeżeli idzie o mnie, to zastanawianie się nad "warunkami początkowymi" i "warunkami końcowymi" wydaje mi się dziwne. I o ile wyrażanie własności programów wydaje mi się ważnym skillem (np. w połączeniu z model-checkerami albo property-based testing), i dostrzegam pewną wartość w akademickich narzędziach pokroju ATS i liniowych systemach typów, o tyle pytanie o niezmienniki pętli jest dla mnie po prostu nienaturalną formą rozumowania. (Ale też jeśli mam wybór, wolę myśleć w oparciu o równania rekurencyjne, niż imperatywne pętle)
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-11-16 14:55 -0800 |
| Message-ID | <d35b9c0f-333e-4cb8-9d83-e32eddcac124@googlegroups.com> |
| In reply to | #31998 |
> (Ale też jeśli mam wybór, wolę myśleć w oparciu o równania rekurencyjne, > niż imperatywne pętle) Spotkałem się z opinią (i się z nią zgadzam), że wtedy rolę niezmienników pełnią pre- i post-conditions w tych rekurencyjnych funkcjach. Pytanie, któro z nich jest łatwiej wyrazić. I nadal, czy się to stosuje. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2018-11-17 14:58 +0100 |
| Message-ID | <psp6q7$97o$1@node2.news.atman.pl> |
| In reply to | #32004 |
On 16/11/2018 23:55, Maciej Sobczak wrote: > Spotkałem się z opinią (i się z nią zgadzam), że wtedy rolę niezmienników pełnią pre- i post-conditions w tych rekurencyjnych funkcjach. Pytanie, któro z nich jest łatwiej wyrazić. I nadal, czy się to stosuje. Ja stosuje asercje i to raczej proste acz często sprawdzam stany z gatunku "kontener musi być wypełniony" czy "indeks nie przekracza max element", "liczba musi być ujemna" itd. Zasada jest taka że jeśli kod kontrolujący stan miałbym mieć więcej linijek niż goły algorytm to *zaciemnia* kod, dodatkowo niektóre checkery powodują wzrost złożoności co może doprowadzić w końcowym efekcie do wzrostu czasu wykonania poza rosądek (np. uniemożliwić debug). Po jakiś 20 latach stukania w klawisze widziałem kod opakowany DbC po brzegi i wymagał on niesłychanie dużo czasu aby zorientować się gdzie jest algorytm a gdzie checkery. Znacznie bardziej ufam unit testom i coverage niż ręcznie pisanym DbC. Być może to jednak efekt języka, czyi w moim przypadku C++, nie wykluczam że można to czytelniej zapisać gdzie indziej.
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-11-17 15:10 -0800 |
| Message-ID | <6bea513b-1794-4d99-9380-931550599e51@googlegroups.com> |
| In reply to | #32006 |
> Zasada jest taka że jeśli kod > kontrolujący stan miałbym mieć więcej linijek niż goły algorytm to > *zaciemnia* kod Tak, to ważna obserwacja. Może da się te rzeczy rozdzielić? Tak jak rozdziela się interfejs od implementacji? Zwłaszcza wtedy, gdy jakieś warunki faktycznie należą do interfejsu? Akurat niezmienniki pętli należą do implementacji (i potrafią pięknie zaciemnić kod), ale takie rzeczy jak "parametr powinien być między 0 a 20" albo "wartość zwracana powinna być w zakresie indeksów tablicy" to intefejs. I może da się to wtedy zapisać gdzieś w okolicy deklaracji tak, żeby użytkownik to widział (i mógł się pod to sprawdzić)? Tak działa SPARK i przyznam, że podoba mi się. > Po jakiś 20 latach stukania w klawisze > widziałem kod opakowany DbC po brzegi i wymagał on niesłychanie dużo > czasu aby zorientować się gdzie jest algorytm a gdzie checkery. Czy czytelność kodu nie jest też kwestią umiejętności piszącego? Nie zawsze sama koncepcja programistyczna musi ją przekreślać. Tzn. to nie musi być wina DbC, że kod jest nieczytelny. > Znacznie > bardziej ufam unit testom i coverage niż ręcznie pisanym DbC. W porządku. Testy też są potrzebne. A co jeśli część DbC można sprawdzić statycznie? Wtedy ich wartość jest inna, niż testów. A co jeśli wtedy można by niektórych testów w ogóle nie mieć? Unit testy to też koszt. Jeśli można tego kosztu nie mieć, to jest to wartość dodana. > Być może > to jednak efekt języka, czyi w moim przypadku C++, nie wykluczam że > można to czytelniej zapisać gdzie indziej. A może wtedy należy odwrócić kolejność i zamiast szukać języka, gdzie to jest czytelne (albo zamiast doklejać DbC do używanego języka), można taki język zrobić? W sensie - zamiast rezygnować z DbC, bo jest nieczytelny, zróbmy język tak, żeby to było czytelne. To nie są zupełnie teoretyczne pytania. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2018-11-18 09:58 +0100 |
| Message-ID | <psr9kf$16l1$1@gioia.aioe.org> |
| In reply to | #32008 |
On 2018-11-18 00:10, Maciej Sobczak wrote: >> Zasada jest taka że jeśli kod >> kontrolujący stan miałbym mieć więcej linijek niż goły algorytm to >> *zaciemnia* kod > > Tak, to ważna obserwacja. Może da się te rzeczy rozdzielić? Tak jak rozdziela się interfejs > od implementacji? Zwłaszcza wtedy, gdy jakieś warunki faktycznie należą do interfejsu? Akurat > niezmienniki pętli należą do implementacji (i potrafią pięknie zaciemnić kod), ale takie rzeczy > jak "parametr powinien być między 0 a 20" albo "wartość zwracana powinna być w zakresie indeksów > tablicy" to intefejs. I może da się to wtedy zapisać gdzieś w okolicy deklaracji tak, żeby > użytkownik to widział (i mógł się pod to sprawdzić)? Tak działa SPARK i przyznam, że podoba > mi się. Np. w Pythonie do takich rzeczy (DBC) dobrze nadają sie dekoratory funkcji/metod/klas (ich dzialanie jes o wiele szersze/bardziej dynamiczne niz dekoratory/annotacje z innych jezykow programowania np.Javy). >> Po jakiś 20 latach stukania w klawisze >> widziałem kod opakowany DbC po brzegi i wymagał on niesłychanie dużo >> czasu aby zorientować się gdzie jest algorytm a gdzie checkery. > > Nie zawsze sama koncepcja programistyczna musi ją przekreślać. > Tzn. to nie musi być wina DbC, że kod jest nieczytelny. Racja. > A może wtedy należy odwrócić kolejność i zamiast szukać języka, gdzie to jest > czytelne (albo zamiast doklejać DbC do używanego języka), można taki język zrobić? > W sensie - zamiast rezygnować z DbC, bo jest nieczytelny, zróbmy język tak, > żeby to było czytelne. To nie są zupełnie teoretyczne pytania. ..czasem wystarczy w danym jezyku dobrze to zaiplementowac. Np. w Pythonie "od lat" stosuję zope.interface i bardzo sobie chwalę https://pypi.org/project/zope.interface/ https://zopeinterface.readthedocs.io/en/latest/ np. https://zopeinterface.readthedocs.io/en/latest/README.html#invariants AK
[toc] | [prev] | [next] | [standalone]
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2018-11-18 17:35 +0100 |
| Message-ID | <pss4d0$14n$1@node2.news.atman.pl> |
| In reply to | #32008 |
On 18/11/2018 00:10, Maciej Sobczak wrote:
>> Zasada jest taka że jeśli kod
>> kontrolujący stan miałbym mieć więcej linijek niż goły algorytm to
>> *zaciemnia* kod
> Tak, to ważna obserwacja. Może da się te rzeczy rozdzielić?
To następna obserwacja: jeśl wpływa to na runtime release należy to
odrzucić. Wszelakie checkery asercyjne, za wyjątkiem programowania
defensywanego, nie mogą istnieć w kodzie produkcyjnym. Z marginesem
dyskusji o językach w których jest kłopot z warunkową kompilacją.
>> Po jakiś 20 latach stukania w klawisze
>> widziałem kod opakowany DbC po brzegi i wymagał on niesłychanie dużo
>> czasu aby zorientować się gdzie jest algorytm a gdzie checkery.
> Czy czytelność kodu nie jest też kwestią umiejętności piszącego?
Jest, ale w przypadku nadmiaru checkerów nie da się pisać czytelnie.
Nazjwyczajniej nie widać gdzie jest algorytm w morzu makr, asercji czy
fake funkcji. Widziałem kiedyś IDE które klapsowało asercje. Niestety
tylko asercje.
> Nie zawsze sama koncepcja programistyczna musi ją przekreślać. Tzn. to nie musi być wina DbC, że kod jest nieczytelny.
Tak, ale nadmiar DbC generuje zaciemnienie kodu. Taki smutny praktyczny
wniosek. Biorę jednak pod uwagę że pracuje z toksyczym językiem.
>> Znacznie
>> bardziej ufam unit testom i coverage niż ręcznie pisanym DbC.
> W porządku. Testy też są potrzebne. A co jeśli część DbC można sprawdzić statycznie?
Potrzebujemy kompilator który to by potrafił :) Jakiś porządny lint. Mój
język, C++, ma wyjątkowo popieprzony problem z side effects i kiesko
widzę kontrole DbC na poziomie statycznej analizy kodu. Może dla
prostych przypadków, ale takich za dużo nie ma.
> A co jeśli wtedy można by niektórych testów w ogóle nie mieć?
Dlatego używam np metaprogramowania do kontrolownia różych obliczeń.
Jednak dalej brakuje mi czegoś takiego jak int a<4-200> i kontroli
komilatora w debug kiedy a zmieni się poza zakres. Contraints by się
przydało i już powoduje to zniknięcie kilku lini DbC.
>> Być może
>> to jednak efekt języka, czyi w moim przypadku C++, nie wykluczam że
>> można to czytelniej zapisać gdzie indziej.
> A może wtedy należy odwrócić kolejność i zamiast szukać języka, gdzie to jest czytelne (albo zamiast doklejać DbC do używanego języka), można taki język zrobić?
Nie. Poza przypadkami jak clojure nie znam w zasadzie nic co mogło by
być uznane za projekt języka do potrzeb. Języki które są popularne mają
bibliteki, języki wymyślane nie. Na sam koniec wyjądujesz projektując
jeszcze jeden niszowy język na bytecode javy i z nią kompatybilny
którego nikt nie użyje poza helloworld.
Obserwuje że ludzie nie chcą języków bezpiecznych. Potrzebują zabawek
typu python albo stosu kupy typu perl i są zadowoleni.
> W sensie - zamiast rezygnować z DbC, bo jest nieczytelny, zróbmy język tak, żeby to było czytelne.
> To nie są zupełnie teoretyczne pytania.
Język ten nie zdobedzie popularnosci. Wolałbym dodanie czegoś do
istniejących języków.
Na początek chciabym w C++ takie coś:
debug {
// O(N^2) checker
}
I ide kolapsujący te sekcje.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | pl.comp.programming
csiph-web