Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #32142 > unrolled thread
| Started by | szykcech@gmail.com |
|---|---|
| First post | 2018-12-23 11:29 -0800 |
| Last post | 2018-12-30 16:46 +0100 |
| Articles | 20 on this page of 160 — 11 participants |
Back to article view | Back to pl.comp.programming
Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 szykcech@gmail.com - 2018-12-23 11:29 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2018-12-25 03:13 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2018-12-25 16:27 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2018-12-25 19:07 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 szykcech@gmail.com - 2018-12-26 04:35 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2018-12-26 09:10 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2018-12-26 11:42 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 szykcech@gmail.com - 2018-12-26 12:40 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2018-12-26 12:53 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2018-12-26 13:35 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2018-12-26 14:39 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Adam M <amorawski@magna-power.com> - 2018-12-26 13:39 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2018-12-27 09:33 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2018-12-26 14:31 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2018-12-26 14:52 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2018-12-26 15:07 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2018-12-26 15:37 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2018-12-26 15:58 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2018-12-27 10:20 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2018-12-27 14:53 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2018-12-27 17:06 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2018-12-28 14:07 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 szykcech@gmail.com - 2018-12-28 22:13 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2018-12-29 03:51 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Borneq <borneq@antyspam.hidden.pl> - 2018-12-29 14:01 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2018-12-29 10:42 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 szykcech@gmail.com - 2018-12-29 05:24 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2018-12-29 11:23 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 szykcech@gmail.com - 2018-12-30 09:08 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2018-12-30 10:17 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-02 00:48 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-02 04:23 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-03 00:37 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2018-12-31 08:18 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2018-12-31 01:14 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-02 00:41 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-02 05:00 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-03 00:44 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-03 05:19 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-02 01:53 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2018-12-29 03:27 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2018-12-29 15:21 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2018-12-30 04:06 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-02 01:17 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-02 04:42 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-03 00:57 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-03 05:34 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Roman Tyczka <noemail@because.no> - 2019-01-03 17:15 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-03 08:30 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-03 17:44 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Roman Tyczka <noemail@because.no> - 2019-01-04 17:48 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-04 09:44 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Roman Tyczka <noemail@because.no> - 2019-01-04 22:14 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-04 13:25 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-03 17:24 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-03 09:20 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2019-01-03 12:51 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-03 13:21 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2019-01-03 16:13 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-04 00:40 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2019-01-04 04:34 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-04 05:12 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2019-01-04 05:26 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-04 06:42 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2019-01-04 07:33 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2019-01-04 07:35 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2019-01-04 05:33 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-04 14:50 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2019-01-04 05:54 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2019-01-04 06:10 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-04 02:00 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-04 10:25 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-04 12:50 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-04 04:29 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2019-01-04 04:47 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-04 04:52 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2019-01-04 05:01 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 fir <profesor.fir@gmail.com> - 2019-01-04 05:16 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-04 14:15 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-04 14:31 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-03 10:37 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-04 00:20 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-04 02:15 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-06 23:47 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-07 02:23 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-08 00:08 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-08 00:31 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-09 00:08 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-09 14:21 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-10 02:16 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-08 09:42 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-08 08:21 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-08 22:48 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-09 14:22 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-10 02:32 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-10 00:29 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-10 10:14 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-10 01:54 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-10 11:17 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-08 22:51 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-09 13:32 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-08 01:42 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-08 14:24 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-09 00:18 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-08 23:46 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-09 14:11 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-10 02:31 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-10 02:39 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-10 02:49 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-10 03:52 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-10 02:56 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-10 03:30 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-10 12:55 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-10 04:00 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-10 14:02 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-10 14:11 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-10 05:22 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-10 15:47 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-11 10:14 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-11 21:31 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-11 13:42 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-14 00:36 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-14 00:47 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-14 23:03 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-14 23:46 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-16 03:28 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-16 09:29 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-16 11:56 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-17 00:58 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-15 12:28 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-16 02:13 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-16 03:01 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-16 13:08 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-16 13:13 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-16 04:15 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-16 04:37 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-16 15:12 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-16 15:23 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 godek.maciek@gmail.com - 2019-01-16 11:58 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-16 13:06 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-16 04:27 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-16 14:57 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-16 15:06 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-17 00:45 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-17 10:23 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-17 22:46 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-18 10:40 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-14 10:12 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-14 23:12 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-15 12:32 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-14 10:29 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-14 23:16 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-15 12:44 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-17 00:35 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-10 22:57 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 AK <nobody@nowhere.net> - 2019-01-10 12:42 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-10 23:05 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Roman Tyczka <noemail@because.no> - 2018-12-29 13:44 +0100
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Maciej Sobczak <see.my.homepage@gmail.com> - 2018-12-27 10:49 -0800
Re: Jaki język polecić początkującemu? - komentarz do artykułu w Programista 9/2018 Mateusz Bogusz <mabakay@o2.pl> - 2018-12-30 16:46 +0100
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Wojciech Muła <wojtek.mula@gmail.com> |
|---|---|
| Date | 2019-01-09 13:32 -0800 |
| Message-ID | <c5379112-e27a-4fbb-81ae-8f644262afd6@googlegroups.com> |
| In reply to | #32295 |
On Tuesday, January 8, 2019 at 10:51:30 PM UTC+1, AK wrote: > On 2019-01-08 17:21, Wojciech Muła wrote: > > On Tuesday, January 8, 2019 at 9:42:25 AM UTC+1, AK wrote: > >> 1. W tym watku _nie dyskutuje sie_ o sumowaniu kwadratow > >> poczatkowych liczb perwszych. To klasyczny "learning by example". > > > > Jest to problem skrajnie niepraktyczny, w przeciwieństwie do MD5. > > Fajnie, że można zabawkowe rzeczy napisać szybko, ale to tylko > > zabawki. > > Ze niby generatory/wyrazenia generatorowe/iteratorowe sa zabawka? Tak, to tylko lukier składniowy, który nie wnosi nic do semantyki. O wiele istotniejsze, jeśli jesteśmy przy pythonie, jest context management protocol. Co do wyrażeń generatorowych to owszem, używam na co dzień w pythonie, ale mógłbym żyć bez tego. Nie boli mnie pisanie pętli, ja się nawet goto nie boję. :) Bardziej skomplikowane wyrażenia i tak zamykam w funkcji/metodzie, bo mi etyka zawodowa nie pozwala pisać jednolinijkowców na 150 znaków. > Ze lazy jest zabawka? Nie, leniwe liczenie to wyłącznie środek do celu (który ma swój ukryty koszt, o czym lepiej nie pamiętać). Okazało się np., że genialne w swojej prostocie parsowanie za pomocą pochodnych wyrażeń regularnych dużo zyskuje dzięki temu podejściu, jeśli nawet nie staje możliwe dzięki niemu. No i to w sumie jedyne praktyczne zastosowanie leniwego wartościowania o jakim słyszałem. > No to pokaz jak uzywac generatorow/wyrazen generatorowych w C++ Przecież nie ma czegoś takiego w C++, po co na siłę udawać? Generator w języku imperatywnym to będzie stan + funkcja która liczy następną wartość ze stanu (tak jest zresztą fizycznie w pythonie robione). I przypominam sobie dokładnie jeden przypadek, kiedy musiałem coś takiego napisać. To była implementacja interfejsu generatora w rozszerzeniu do Pythona napisanym w C. :) w.
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-01-08 01:42 -0800 |
| Message-ID | <c2ea17a7-92df-4c4e-ab44-2ff5268057a7@googlegroups.com> |
| In reply to | #32277 |
> > Rozumiem. Mamy więc (niezaskakujący) wniosek, że różne języki są właściwe do różnych problemów.
>
> Pytanie, jaki dalszy wniosek możemy wyciągnąć z tego wniosku.
> Może na przykład taki, że rozsądnie byłoby eksplorować języki,
> które ułatwiają projektowanie języków.
Zgadzam się. Dlatego, jak już wspomniałem, podoba mi się język Wolfram, bo dzięki swojej umiarkowanej lispowatości świetnie nadaje się do tworzenia tzw. Domain-Specific Languages. Zastanawiam się nad możliwością użycia tego do opisu wymagań, które można weryfikować albo z których można generować właściwy kod (albo testy).
Sam LISP jest przez swój minimalizm zbyt sztywny, żeby był użyteczny dla końcowego odbiorcy.
> Możesz zerknąć w przykłady programów liczących sumę kwadratów
> początkowych siedmiu liczb pierwszych, które przewinęły się
> przez ten wątek (to było w odpowiedzi na post AK).
> Tam dokładnie pokazałem przykład rozumowania podstawieniowego.
Ależ ja go rozumiem i od początku staram się tu zrobić konfrontację tych koncepcji. "Przykład rozumowania podstawieniowego" nie pokazuje żadnej przewagi nad tym imperatywnym oryginałem, z dwóch powodów:
1. Nie widać w nim długoterminowych zalet w aspekcie utrzymania kodu. Wyobraź sobie, że klient dostał ten program i jest zadowolony, ale przecież jesteśmy agile, więc klient od razu wpada na nowy pomysł: "a jeszcze tak sobie pomyślałem, że te liczby, które nie są pierwsze, też by można do siebie dodać".
Z punktu widzenia klienta to nie jest zmiana wymagań, tylko *nowe*, *dodatkowe* wymaganie (bo logicznie tak właśnie jest). A skoro tak, to klient będzie oczekiwał, że ten drobny dodatek będzie zrealizowany przez drobny dodatek w kodzie. W wersji imperatywnej (tej syfiastej, brzydkiej i naiwnej) *faktycznie* wystarczy coś dodać, bez modyfikacji istniejącego kodu. W wersji funkcjonalnej trzeba wywalić cały program i napisać go od nowa (pokażesz?). To jest potencjalnie poważny problem i nie tylko dlatego, że klient nie zrozumie, dlaczego tak ma się stać.
Ten przykład w całości jest sztuczny (serio: nikt nie rozwiązuje takich problemów), ale nie wynika z niego, że powyższy problem nie wystąpi w większej (ilościowo albo czasowo) skali. Ciekawym aspektem do rozważenia jest to, że to, co Ty traktujesz jako wymagania ("dodaj ... itd.") to nie są jedyne wymagania, z jakimi musi się zmierzyć inżynier. Niejawnymi wymaganiami są też kwestie wydajności (sam widziałeś) i utrzymanie projektu w długim terminie. "Paradygmat podstawieniowy" tych problemów sam z siebie nie adresuje a przez to jest rozwiązaniem nie tylko niekompletnym ale może być wręcz ograniczającym.
2. Programowanie imperatywne w żaden sposób nie wyklucza analizy podstawieniowej. Analizatory kodu (np. takie, które sprawdzają statycznie, czy ktoś nie wyjeżdża poza tablicę albo nie dzieli przez zero) wykonują weryfikację właśnie przez podstawienia i przez rozwiązywanie równań.
> Większość programistów, jakich znam, nie implementuje swojego MD5.
To samo mogę powiedzieć o każdym zaproponowanym przez Ciebie przykładzie.
A jednak ktoś coś immplementuje, inaczej nie mielibyśmy roboty. Pytanie, w którym momencie trafię na taki (lub należący do tej klasy) problem.
> Być może z dydaktycznego punktu widzenia lepiej jest, żeby
> programiści najpierw uczyli się języków, które realizują prostsze
> modele obliczeń, a dopiero później (jeśli zajdzie taka potrzeba)
> takich, które pozwalają na ścisłą kontrolę sprzętu.
> (Wiele wskazuje na to, że tak właśnie jest)
Ja bym się nawet z tym zgodził. I tu możemy wrócić do Twojej tezy, że początkujący programiści powielają nawyki z prostych przykładów w większej skali. A może warto ich uczyć na językach, których nie da się zastosować w większej skali? Wtedy nie będą niczego powielać. Scratch, Logomocja, itp. - a potem, jak już się wyszaleją na piramidkach i ciuchciach, pokazać im prawdziwy język, od razu w dużej skali. Np. C++. :-D
> Czasem się spotykam z takim sformułowaniem, że dobry
> język powinien robić tak, żeby łatwe rzeczy były w nim
> łatwe, a trudne przynajmniej możliwe.
Zgadzam się. Ale to może być też kwestią ekspozycji - tzn. można pokazywać język kawałkami, zaczynając od tych łatwych.
> > > Operator przypisania w językach takich jak C czy Python jest
> > > łatwo dostępny, i sprawia wrażenie, że jest prostą operacją.
> >
> > Bo jest. To jest podstawowa operacja.
>
> Podstawowa dla jakiego problemu?
Jak niewiasta chce przemalować włosy to je maluje a nie robi swojego klona z innymi włosami. Jak mam kapcia w samochodzie to pompuję oponę a nie kupuję nowe napompowane koło (przepraszam: nowy samochód, bo przecież do starego nie da się nowego koła założyć). Jak mam gorzką kawę, to ją dosładzam a nie robię nową słodką. A jak chcę zmienić kolor ściany, to ją maluję a nie buduję nowy dom. I nie zakładam nowego konta (w nowym banku), żeby móc dostać wypłatę.
Tak ma moje oko, operacja przypisania jest podstawowa w sensie uniwersalnym. To właśnie udawanie, że tej operacji nie ma, jest dla mnie kosztem.
> Załóżmy, że zmienimy linijkę
>
> if(++dodano==ilu) return suma;
>
> na
>
> if(dodano++==ilu) return suma;
>
> Już mamy błąd.
To jest problem kolejności operacji a nie samego przypisania (w tym przypadku modyfikacji). Funkcje też można zaaplikować w złej kolejności.
> > > i właśnie z tego powodu w pierwszych dwóch rozdziałach SICP
> >
> > A z jakiego powodu teraz używają Pythona do nauki?
>
> Wyjaśniają w tekście, który podlinkowałeś wcześniej.
Czyli jednak można pokazywać uczniom operację przypisania od samego początku nauki?
> Polecam ten wykład:
> https://www.youtube.com/watch?v=uEFrE6cgVNY
Jak to się ma do ludzi, którzy uczyli się matematyki i nie rozumieją, że x=x+1 to nie musi być równanie?
Ludzie, którzy zawodowo zajmują się matematyką biegle posługują się narzędziami takimi jak Mathematica, Matlab, Octave, itp. (zależność kulturowa) i zdumiewająco wszystkie te trzy są imperatywne i korzystają z pojedynczego znaku "=" jako operacji przypisania, czyli:
x=5;
x=x+1;
we wszystkich tych narzędziach oznacza to samo.
Czyli najwyraźniej ludzie zajmujący się matematyką nie mają z tym problemu.
--
Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-08 14:24 -0800 |
| Message-ID | <60e7a596-5b5e-487c-8b81-b389dfc3663f@googlegroups.com> |
| In reply to | #32285 |
W dniu wtorek, 8 stycznia 2019 10:42:29 UTC+1 użytkownik Maciej Sobczak napisał:
> > > Rozumiem. Mamy więc (niezaskakujący) wniosek, że różne języki są właściwe do różnych problemów.
> >
> > Pytanie, jaki dalszy wniosek możemy wyciągnąć z tego wniosku.
> > Może na przykład taki, że rozsądnie byłoby eksplorować języki,
> > które ułatwiają projektowanie języków.
>
> Zgadzam się. Dlatego, jak już wspomniałem, podoba mi się język Wolfram, bo dzięki swojej umiarkowanej lispowatości świetnie nadaje się do tworzenia tzw. Domain-Specific Languages. Zastanawiam się nad możliwością użycia tego do opisu wymagań, które można weryfikować albo z których można generować właściwy kod (albo testy).
> Sam LISP jest przez swój minimalizm zbyt sztywny, żeby był użyteczny dla końcowego odbiorcy.
Mógłbyś wyjaśnić, co masz na myśli, mówiąc 'zbyt sztywny'?
Dyskutowałem kiedyś z jednym gościem na Quorze. Gość pracował kiedyś dla Wolframa i był chyba w jakimś stopniu entuzjastą Mathematiki (nazywa się Jon Harrop, jeśli to coś mówi)
Zadałem mu małe wyzwanie związane z tematem, którym się akurat zajmowałem w ramach pracy magisterskiej.
Temat był raczej niszowy, bo dotyczył konwersji programów z rekurencją do takich, w których rekurencja się nie pojawiała (zamiast tego używa się tzw. kombinatora punktu stałego).
Konwersję mam przedstawioną w dodatku do swojej pracy magisterskiej:
https://github.com/panicz/master-thesis/blob/master/chapters/B.tex
Jon napisał swój odpowiednik w języku Wolframa, i choć nie zdołałem go przekonać do Lispa, sam określił swoje rozwiązanie mianem bełkotu
https://www.quora.com/Why-is-Haskell-not-homoiconic/answer/Jon-Harrop-2/comment/31109783
> > Możesz zerknąć w przykłady programów liczących sumę kwadratów
> > początkowych siedmiu liczb pierwszych, które przewinęły się
> > przez ten wątek (to było w odpowiedzi na post AK).
> > Tam dokładnie pokazałem przykład rozumowania podstawieniowego.
>
> Ależ ja go rozumiem i od początku staram się tu zrobić konfrontację tych koncepcji. "Przykład rozumowania podstawieniowego" nie pokazuje żadnej przewagi nad tym imperatywnym oryginałem, z dwóch powodów:
>
> 1. Nie widać w nim długoterminowych zalet w aspekcie utrzymania kodu. Wyobraź sobie, że klient dostał ten program i jest zadowolony, ale przecież jesteśmy agile, więc klient od razu wpada na nowy pomysł: "a jeszcze tak sobie pomyślałem, że te liczby, które nie są pierwsze, też by można do siebie dodać".
> Z punktu widzenia klienta to nie jest zmiana wymagań, tylko *nowe*, *dodatkowe* wymaganie (bo logicznie tak właśnie jest). A skoro tak, to klient będzie oczekiwał, że ten drobny dodatek będzie zrealizowany przez drobny dodatek w kodzie. W wersji imperatywnej (tej syfiastej, brzydkiej i naiwnej) *faktycznie* wystarczy coś dodać, bez modyfikacji istniejącego kodu. W wersji funkcjonalnej trzeba wywalić cały program i napisać go od nowa (pokażesz?).
Nie rozumiem przykładu i nie wiem, skąd bierze się Twój wniosek. Ja mam w tej kwestii zupełnie inne doświadczenia.
Programowanie funkcyjne polega przede wszystkim na definiowaniu pojęć, przy pomocy których wyrażasz rozwiązanie problemu.
Pojęcia reprezentują nasze rozumienie składników rozwiązania. Jeżeli do wymagań klienta dochodzi coś nowego, co nie jest wyrażalne przy pomocy dotychczasowego aparatu pojęciowego, to wówczas trzeba ten aparat rozszerzyć, tzn. podefiniować nowe pojęcia. Ale nic nie trzeba wyrzucać.
> To jest potencjalnie poważny problem i nie tylko dlatego, że klient nie zrozumie, dlaczego tak ma się stać.
> Ten przykład w całości jest sztuczny (serio: nikt nie rozwiązuje takich problemów), ale nie wynika z niego, że powyższy problem nie wystąpi w większej (ilościowo albo czasowo) skali.
Tzn. jaki przykład?
> Ciekawym aspektem do rozważenia jest to, że to, co Ty traktujesz jako wymagania ("dodaj ... itd.") to nie są jedyne wymagania, z jakimi musi się zmierzyć inżynier. Niejawnymi wymaganiami są też kwestie wydajności (sam widziałeś) i utrzymanie projektu w długim terminie. "Paradygmat podstawieniowy" tych problemów sam z siebie nie adresuje a przez to jest rozwiązaniem nie tylko niekompletnym ale może być wręcz ograniczającym.
Ja nie twierdzę, że programowanie funkcyjne to panaceum na wszystkie problemy. Sam dużo programuję imperatywnie, i jakoś sobie z tym radzę.
Ja mówię przede wszystkim o uczeniu się programowania: o dostrzeżeniu, że niemożność analizy programu w terminach podstawień też jest pewnym kosztem (który może czasem można zamortyzować, a czasem warto ponieść).
> 2. Programowanie imperatywne w żaden sposób nie wyklucza analizy podstawieniowej. Analizatory kodu (np. takie, które sprawdzają statycznie, czy ktoś nie wyjeżdża poza tablicę albo nie dzieli przez zero) wykonują weryfikację właśnie przez podstawienia i przez rozwiązywanie równań.
Ok, w takim razie weź kod fira, który przekleiłem do swojej odpowiedzi, i pokaż nam, jak by dla niego taka analiza podstawieniowa wyglądała.
> > Większość programistów, jakich znam, nie implementuje swojego MD5.
>
> To samo mogę powiedzieć o każdym zaproponowanym przez Ciebie przykładzie.
> A jednak ktoś coś immplementuje, inaczej nie mielibyśmy roboty. Pytanie, w którym momencie trafię na taki (lub należący do tej klasy) problem.
Weź dowolną finansową aplikację. Tam tego typu prostych przekształceń będziesz miał na pęczki.
Może niekoniecznie sumowanie kwadratów liczb pierwszych, ale na przykład liczenie bilansu zysków i strat albo kwoty wolnej od podatku.
> > Być może z dydaktycznego punktu widzenia lepiej jest, żeby
> > programiści najpierw uczyli się języków, które realizują prostsze
> > modele obliczeń, a dopiero później (jeśli zajdzie taka potrzeba)
> > takich, które pozwalają na ścisłą kontrolę sprzętu.
> > (Wiele wskazuje na to, że tak właśnie jest)
>
> Ja bym się nawet z tym zgodził. I tu możemy wrócić do Twojej tezy, że początkujący programiści powielają nawyki z prostych przykładów w większej skali. A może warto ich uczyć na językach, których nie da się zastosować w większej skali? Wtedy nie będą niczego powielać. Scratch, Logomocja, itp. - a potem, jak już się wyszaleją na piramidkach i ciuchciach, pokazać im prawdziwy język, od razu w dużej skali. Np. C++. :-D
Tylko wtedy mamy dydaktyczny problem zmiany skali.
> > Czasem się spotykam z takim sformułowaniem, że dobry
> > język powinien robić tak, żeby łatwe rzeczy były w nim
> > łatwe, a trudne przynajmniej możliwe.
>
> Zgadzam się. Ale to może być też kwestią ekspozycji - tzn. można pokazywać język kawałkami, zaczynając od tych łatwych.
Moim zdaniem pokazywanie języka to zachowanie na poziomie przedszkolnym.
Dlatego cenię książki Lispowe, o których wspominałem, że w nich język w ogóle nie jest kwestią, i zamiast na nim i na "językowych ficzerach" można się skupić po prostu na przykładach użycia języka, czyli na wypowiedziach.
C++ przyzwyczaja pokolenia programistów do "językowych ficzerów".
Natomiast książki pokroju SICP czy PAIP uczą się, że możemy najpierw próbować wyrazić problem w dogodny dla nas sposób, a dopiero później wykombinować, co z owym wyrażeniem ma robić komputer.
> > > > Operator przypisania w językach takich jak C czy Python jest
> > > > łatwo dostępny, i sprawia wrażenie, że jest prostą operacją.
> > >
> > > Bo jest. To jest podstawowa operacja.
> >
> > Podstawowa dla jakiego problemu?
>
> Jak niewiasta chce przemalować włosy to je maluje a nie robi swojego klona z innymi włosami. Jak mam kapcia w samochodzie to pompuję oponę a nie kupuję nowe napompowane koło (przepraszam: nowy samochód, bo przecież do starego nie da się nowego koła założyć). Jak mam gorzką kawę, to ją dosładzam a nie robię nową słodką. A jak chcę zmienić kolor ściany, to ją maluję a nie buduję nowy dom. I nie zakładam nowego konta (w nowym banku), żeby móc dostać wypłatę.
> Tak ma moje oko, operacja przypisania jest podstawowa w sensie uniwersalnym. To właśnie udawanie, że tej operacji nie ma, jest dla mnie kosztem.
Wydaje mi się, że nie rozumiesz jednej rzeczy.
Ta rzecz jest może trudna do wyjaśnienia, bo jest bardzo abstrakcyjna, wszędobylska, a przez to trudna do uchwycenia.
Jak ja Ci przedstawiam jakąś nową informację, to ja jej nie tracę, a stare informacje nie znikają.
Jak piszę nowego posta na usenecie, to nie kasuję poprzedniego.
To, że William Szekspir umarł, nie sprawia, że nie mogę o nim mówić, nie dostając błędu segmentacji pamięci.
Jeżeli od jakiegoś momentu postanowimy, żeby słowem "jabłko" określać konia, nie sprawi to, że nagle wszystkie jabłka staną się końmi, ani że wszystkie dotychczasowe użycia słowa "jabłko" będą dla wszystkich oznaczać konie.
Nawet w szkole, jak nauczyciel zmazuje tablicę, to Ty nie bierzesz korektora, i nie zamazujesz wszystkich swoich notatek.
Trudno to sobie uświadomić, bo to są rzeczy, które się nie dzieją. Jesteśmy przyzwyczajeni do tego, że się nie dzieją.
Operator przypisania nie ma swojego odpowiednika w świecie językowym czy pojęciowym, w którym żyjemy na co dzień.
Unikanie go sprawia, że programowanie staje się równie proste i naturalne, co mówienie.
Właśnie dlatego nie kupuję Twojego argumentu: kiedy ja mówię o niemutowalności, to Ty mówisz "świat taki nie jest". Ale my nie mówimy teraz o świecie, tylko o języku, i ja odpowiadam na Twój obraz świata: "język taki nie jest".
Wprowadzenie operatora przypisania rodzi bardzo wiele nieoczywistości w różnych sytuacjach.
Choćby w Pythonie mamy coś takiego: możemy być przyzwyczajeni traktować zapis "x += y" jako skrót dla "x := x + y".
Jest tak na przykład wtedy, kiedy x i y odnoszą się do liczb całkowitych:
>>> x = 5
>>> y = x
>>> y += 2
>>> y
7
>>> x
5
ale jeśli napisalibyśmy
>>> x = [1,2,3]
>>> y = x
>>> y += [4,5]
to oczywiście
>>> y
[1,2,3,4,5]
ale - co już mniej oczywiste
>>> x
[1,2,3,4,5]
Jedni mogą twierdzić, że to jest dobre zachowanie, inni że złe, ale dla mnie to jest jeden z tych problemów, które wolę obejść, niż rozwiązywać, bo którego nie można dobrze rozwiązać a priori.
I owszem, jeżeli jesteśmy przyzwyczajeni do tego, że programowanie to "mówienie komputerowi, co ma robić", to takie programowanie, o którym ja tutaj mówię, można uznać za iluzję - często trudniej sprawić, żeby efekt działał wydajnie, co - w zgodzie z tym, co piszesz, można widzieć jako pewien koszt. Prostota, o której ja piszę, nie jest prostotą implementacyjną, ale prostotą pojęciową, bądź też prostotą mentalnego modelu programowania.
> > > > i właśnie z tego powodu w pierwszych dwóch rozdziałach SICP
> > >
> > > A z jakiego powodu teraz używają Pythona do nauki?
> >
> > Wyjaśniają w tekście, który podlinkowałeś wcześniej.
>
> Czyli jednak można pokazywać uczniom operację przypisania od samego początku nauki?
Nie wiem, w jaki oni sposób uczą Pythona, ale podejrzewam, że nadal są pod tym względem ostrożni.
> > Polecam ten wykład:
> > https://www.youtube.com/watch?v=uEFrE6cgVNY
>
> Jak to się ma do ludzi, którzy uczyli się matematyki i nie rozumieją, że x=x+1 to nie musi być równanie?
Właśnie w taki sposób, że na podstawie badań empirycznych wyszło im, że wyjmując operator przypisania z języka unikają bardzo wielu nieporozumień.
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-01-09 00:18 +0100 |
| Message-ID | <q13b4r$18gn$1@gioia.aioe.org> |
| In reply to | #32296 |
On 2019-01-08 23:24, godek.maciek@gmail.com wrote:
> Jak to się ma do ludzi, którzy uczyli się matematyki i nie rozumieją, że x=x+1 to nie musi być równanie?
W "moich czasach" bylo jednak normalniej :).
= to bylo: rowna sie
← to bylo: podstawienie
Pozniej jednak jakis debil usunal ← z klawiatury :(
ICL1900 Algol:
integer procedure silnia(n):
integer n;
begin
silnia ← if n = 1 then 1 else silnia(n - 1) * n;
end
AK
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-01-08 23:46 -0800 |
| Message-ID | <3bc25947-11ec-4e03-ae46-e84b9e17c4f5@googlegroups.com> |
| In reply to | #32296 |
> > Sam LISP jest przez swój minimalizm zbyt sztywny, żeby był użyteczny dla końcowego odbiorcy. > > Mógłbyś wyjaśnić, co masz na myśli, mówiąc 'zbyt sztywny'? Np. to, że jego składnia jest ukłonem w stronę parserów a nie w stronę użytkowników. Ja naprawdę wolę napisać a*b+c, niż (+ (* a b) c), i nie cieszy mnie kończenie wyrażeń serią nawiasów tak długą, że nie sposób ich policzyć. Wolfram jest o tyle ciekawy, że ma dwie albo trzy wewnętrznie równoważne składnie i pozwala posłużyć się taką, jaka jest w danym miejscu odpowiednia. Jest to ważne zwłaszcza wtedy, gdy chcemy w języku wyrazić coś nowego, np. wymagania albo zbiór danych. [o przykładzie z dodawaniem kwadratów liczb pierwszych] > > Z punktu widzenia klienta to nie jest zmiana wymagań, tylko *nowe*, *dodatkowe* wymaganie (bo logicznie tak właśnie jest). A skoro tak, to klient będzie oczekiwał, że ten drobny dodatek będzie zrealizowany przez drobny dodatek w kodzie. W wersji imperatywnej (tej syfiastej, brzydkiej i naiwnej) *faktycznie* wystarczy coś dodać, bez modyfikacji istniejącego kodu. W wersji funkcjonalnej trzeba wywalić cały program i napisać go od nowa (pokażesz?). > > Nie rozumiem przykładu Przykład pokazuje, że Twoja metoda funkcyjno-podstawieniowa tworzy zamknięty ciąg, którego nie da się rozwijać. Poprosiłem o implementację nowego wymagania w tym samym "projekcie". Pokażesz? Przecież stwierdziliśmy, że kod jest lepszy od słów. > Ja mam w tej kwestii zupełnie inne doświadczenia. Poproszę o implementację nowego wymagania w istniejącym projekcie. W wersji imperatywnej jest to oczywiste - dodatkowa zmienna, być może gałąź else. Jak to będzie w Twojej wersji? > Pojęcia reprezentują nasze rozumienie składników rozwiązania. Jeżeli do wymagań klienta dochodzi coś nowego, co nie jest wyrażalne przy pomocy dotychczasowego aparatu pojęciowego Ale właśnie jest. "Te liczby, które nie są pierwsze, też można by do siebie dodać". Co tu jest pojęciowo nowego? Liczby pierwsze, dodawanie - te pojęcia już masz, bo już ich używałeś w programie. Teraz odwołując się do tych istniejących pojęć ja chcę mieć też dodane do siebie te liczby, które nie były pierwsze. > Ale nic nie trzeba wyrzucać. Pokaż. > > 2. Programowanie imperatywne w żaden sposób nie wyklucza analizy podstawieniowej. > > Ok, w takim razie weź kod fira, który przekleiłem do swojej odpowiedzi, i pokaż nam, jak by dla niego taka analiza podstawieniowa wyglądała. A na jakie pytanie chciałbyś taką analizą odpowiedzieć? > Weź dowolną finansową aplikację. Tam tego typu prostych przekształceń będziesz miał na pęczki. Weź dowolny system, który czegoś pilnuje albo czymś steruje. Jeszcze nie mówiliśmy o wymaganiach czasowych. Np. "woda w kranie w toalecie ma przestać lecieć po 5s od ostatniej aktywacji czujnika zbliżeniowego". To wymaganie jest pojęciowo bardzo proste. > Może niekoniecznie sumowanie kwadratów liczb pierwszych, ale na przykład liczenie bilansu zysków i strat albo kwoty wolnej od podatku. Ale nawet w takim systemie wyobrażam sobie nowe wymaganie typu "a to coś co nie spełniało warunku, to coś tam". I mam ten sam problem co z sumowaniem kwadratów. > A może warto ich uczyć na językach, których nie da się zastosować w większej skali? > > Tylko wtedy mamy dydaktyczny problem zmiany skali. A może to nie jest problem nauki języka, tylko nauki inżynierii programowania? Może właśnie tego brakuje adeptom powielającym złe nawyki z prostych przykładów? Ale język jest wtedy drugorzędny. Przecież ten sam problem wystąpi w każdej innej dziedzinie - nie można oczekiwać, że się nauczy kogoś architektury albo budownictwa na klockach. Tymczasem tak właśnie ludzie podchodzą do nauki programowania - biorą książkę "Python w 24h" i jazda. > Wydaje mi się, że nie rozumiesz jednej rzeczy. > Jak ja Ci przedstawiam jakąś nową informację, to ja jej nie tracę, a stare informacje nie znikają. A jeśli są wyświetlane na ekranie smartfona? Stare muszą zniknąć, bo rozmiar ekranu jest ograniczony. > Jak piszę nowego posta na usenecie, to nie kasuję poprzedniego. Ale możesz edytować tego nowego, gdy się pomylisz. > To, że William Szekspir umarł, nie sprawia, że nie mogę o nim mówić, nie dostając błędu segmentacji pamięci. Ale żółwika z nim nie przybijesz. > Jeżeli od jakiegoś momentu postanowimy, żeby słowem "jabłko" określać konia, nie sprawi to, że nagle wszystkie jabłka staną się końmi, ani że wszystkie dotychczasowe użycia słowa "jabłko" będą dla wszystkich oznaczać konie. Ten przykład jest dla mnie za trudny. > Nawet w szkole, jak nauczyciel zmazuje tablicę, to Ty nie bierzesz korektora, i nie zamazujesz wszystkich swoich notatek. A jeśli piszę na tablecie? > Trudno to sobie uświadomić, Znowu mnie nie przekonałeś? > Choćby w Pythonie mamy coś takiego: [...] Tak, Python jest źle zaprojektowany. Ale to nie jest przykład na problem z operacją przypisania. Są języki, gdzie ten sam przykład zadziała prawidłowo i zgodnie z intuicją. Np. Wolfram. W C++ analogiczny przykład na kontenerach też zadziała poprawnie. > Prostota, o której ja piszę, nie jest prostotą implementacyjną, ale prostotą pojęciową I to jest dobre określenie. Podoba mi się i zgadzam się z nim. Za wyjątkiem oczywiście tego, że pomijanie aspektów implementacyjnych jest zwykle krótkowzroczne i sprawdza się tylko w prostych albo jednorazowych (często te cechy są razem) przykładach. Zgodzę się jednak, że prostota pojęciowa to dobry cel w wielu zastosowaniach. Myślę jednak, że proponowane przez Ciebie rozwiązania zostaną kiedyś zastąpione przez coś w rodzaju asystentów AI, jak Wolfram Alpha: https://www.wolframalpha.com/input/?i=sum+of+first+seven+prime+numbers Jest prostota pojęciowa? Jest. Właściwie prościej się nie da. Pozostaje zastosować to w większej skali, np. systemu finansowego. Nie mam wątpliwości, że taki jest właśnie kierunek rozwoju. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-09 14:11 -0800 |
| Message-ID | <a6f38469-4e2f-4cc6-92d3-ed2ab3990801@googlegroups.com> |
| In reply to | #32298 |
W dniu środa, 9 stycznia 2019 08:46:07 UTC+1 użytkownik Maciej Sobczak napisał: > > > Sam LISP jest przez swój minimalizm zbyt sztywny, żeby był użyteczny dla końcowego odbiorcy. > > > > Mógłbyś wyjaśnić, co masz na myśli, mówiąc 'zbyt sztywny'? > > Np. to, że jego składnia jest ukłonem w stronę parserów a nie w stronę użytkowników. Ja naprawdę wolę napisać a*b+c, niż (+ (* a b) c), i nie cieszy mnie kończenie wyrażeń serią nawiasów tak długą, że nie sposób ich policzyć. Programiści Lispa często wpadają na świetny pomysł dodania infiksowej składni dla operatorów arytmetycznych do Lispa. To jest proste zadanie. Później uświadamiają sobie, że mogą z łatwością dodać do Lispa taką składnię, jaką sobie tylko wymarzą. (Trudno sobie wymyślić bardziej elastyczny język programowania) Później - niektórzy - uświadamiają sobie, że inni też mogą łatwo wymyślać, i że tak naprawdę żaden z tych pomysłów nie dodaje niczego, co by miało obiektywną wartość, i że ich pomysły wyrażają tylko ich przesądy i dodają do języka przypadkową złożoność (która np. jest trudna do objaśnienia 7-letnim dziewczynkom). Richard Gabriel i Guy Steele nazwali ten proces "rytuałem przejścia". > Wolfram jest o tyle ciekawy, że ma dwie albo trzy wewnętrznie równoważne składnie i pozwala posłużyć się taką, jaka jest w danym miejscu odpowiednia. Stephen Wolfram też ma za sobą rytuał przejścia. > Jest to ważne zwłaszcza wtedy, gdy chcemy w języku wyrazić coś nowego, np. wymagania albo zbiór danych. Potrzebowałbym przykładu. Ale według moich doświadczeń jest niepotrzebne. Tutaj mam np. "język dziedzinowy", w którym opisuję zasady gry w szachy: https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad9d34a98a636d771e3875496f2d69/demos/schess/rules/chess.ss?at=default&fileviewer=file-view-default a tutaj używam tego samego języka do opisania zasad wariantu wikingowskiej gry planszowej "Hnevatafl": https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad9d34a98a636d771e3875496f2d69/demos/schess/rules/ard-ri.ss?at=default&fileviewer=file-view-default Tutaj mam plik w swoim formacie do reprezentowania obiektów 3d: https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad9d34a98a636d771e3875496f2d69/demos/art/3d/cube.3d?at=default&fileviewer=file-view-default a tutaj plik w formacie do opisywania układów fizycznych połączonych więzami, reprezentujący robota humanoidalnego: https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad9d34a98a636d771e3875496f2d69/demos/art/rigs/rob.rig?at=default&fileviewer=file-view-default Wszystkie te języki są oparte na Lispowych s-wyrażeniach. Sprawia to, że parsowanie wszystkich tych formatów jest trywialne (wystarczy do tego funkcja "read"), i do ich przetwarzania mogę korzystać ze standardowych narzędzi, których używam też do swojego języka programowania. > > > Z punktu widzenia klienta to nie jest zmiana wymagań, tylko *nowe*, *dodatkowe* wymaganie (bo logicznie tak właśnie jest). A skoro tak, to klient będzie oczekiwał, że ten drobny dodatek będzie zrealizowany przez drobny dodatek w kodzie. W wersji imperatywnej (tej syfiastej, brzydkiej i naiwnej) *faktycznie* wystarczy coś dodać, bez modyfikacji istniejącego kodu. W wersji funkcjonalnej trzeba wywalić cały program i napisać go od nowa (pokażesz?). > > > > Nie rozumiem przykładu > > Przykład pokazuje, że Twoja metoda funkcyjno-podstawieniowa tworzy zamknięty ciąg, którego nie da się rozwijać. Poprosiłem o implementację nowego wymagania w tym samym "projekcie". Pokażesz? Przecież stwierdziliśmy, że kod jest lepszy od słów. Nie jestem pewien, czy rozumiem, ale jak dla mnie to "prawdziwość" tego stwierdzenia mocno zależy od tego, jakie to konkretne będą wymagania. Toteż chyba zamiast kodu będziesz się musiał zadowolić śmiesznym obrazkiem: https://xkcd.com/1425/ > > Ja mam w tej kwestii zupełnie inne doświadczenia. > > Poproszę o implementację nowego wymagania w istniejącym projekcie. > W wersji imperatywnej jest to oczywiste - dodatkowa zmienna, być może gałąź else. Jak to będzie w Twojej wersji? Bynajmniej nie jest oczywiste. To wszystko zależy od wymagania. Czasem może trochę tak jest, że można wprowadzić zmiany w programie, bez aktualizacji naszego aparatu pojęciowego. Niektórzy nazywają to "wzorcem projektowym" "big ball of mud", a inni "długiem technologicznym". > > Pojęcia reprezentują nasze rozumienie składników rozwiązania. Jeżeli do wymagań klienta dochodzi coś nowego, co nie jest wyrażalne przy pomocy dotychczasowego aparatu pojęciowego > > Ale właśnie jest. "Te liczby, które nie są pierwsze, też można by do siebie dodać". Co tu jest pojęciowo nowego? Liczby pierwsze, dodawanie - te pojęcia już masz, bo już ich używałeś w programie. Teraz odwołując się do tych istniejących pojęć ja chcę mieć też dodane do siebie te liczby, które nie były pierwsze. To nie jest "zmiana wymagania". To jest inny program (ale części zdefiniowanych na potrzeby poprzedniego programu pojęć będzie można użyć ponownie) > > > 2. Programowanie imperatywne w żaden sposób nie wyklucza analizy podstawieniowej. > > > > Ok, w takim razie weź kod fira, który przekleiłem do swojej odpowiedzi, i pokaż nam, jak by dla niego taka analiza podstawieniowa wyglądała. > > A na jakie pytanie chciałbyś taką analizą odpowiedzieć? Na przykład, jaki ten program da wynik dla argumentu "7". > > Weź dowolną finansową aplikację. Tam tego typu prostych przekształceń będziesz miał na pęczki. > > Weź dowolny system, który czegoś pilnuje albo czymś steruje. > Jeszcze nie mówiliśmy o wymaganiach czasowych. Np. "woda w kranie w toalecie ma przestać lecieć po 5s od ostatniej aktywacji czujnika zbliżeniowego". To wymaganie jest pojęciowo bardzo proste. Nie wydaje mi się, żeby było bardzo proste pojęciowo. Ale zgodzę się, że sformułowanie jest bliskie naszemu codziennemu doświadczeniu. I zgodzę się, że można znaleźć odpowiedni język do rozwiązania tego problemu, i że niekoniecznie będzie to programowanie funkcyjne. > > Może niekoniecznie sumowanie kwadratów liczb pierwszych, ale na przykład liczenie bilansu zysków i strat albo kwoty wolnej od podatku. > > Ale nawet w takim systemie wyobrażam sobie nowe wymaganie typu "a to coś co nie spełniało warunku, to coś tam". I mam ten sam problem co z sumowaniem kwadratów. Nie wiem. Nie bardzo rozumiem sformułowanie "a to coś nie spełniało warunku, to cośtam". Ale wydaje mi się, że z tego samego rodzaju problemami zmagają się prawnicy - oni też nieraz próbują ująć złożoną rzeczywistość w prostych słowach, i też im to nie zawsze wychodzi. Cała afera z "dopalaczami" opierała się właśnie na tym, że dla każdego sformułowania sprzedawcy tych substancji wyszukiwali wyjątki z list substancji zakazanych. > > A może warto ich uczyć na językach, których nie da się zastosować w większej skali? > > > > Tylko wtedy mamy dydaktyczny problem zmiany skali. > > A może to nie jest problem nauki języka, tylko nauki inżynierii programowania? Może właśnie tego brakuje adeptom powielającym złe nawyki z prostych przykładów? Ale język jest wtedy drugorzędny. > Przecież ten sam problem wystąpi w każdej innej dziedzinie - nie można oczekiwać, że się nauczy kogoś architektury albo budownictwa na klockach. Tymczasem tak właśnie ludzie podchodzą do nauki programowania - biorą książkę "Python w 24h" i jazda. Wydaje mi się, że SICP wychodzi właśnie z takiego założenia, że ich celem jest właśnie nauka "zarządzaniem złożonością". Właśnie dlatego pierwsze dwa rozdziały poświęcone są w całości zasadom abstrakcji, bo to abstrakcja - a nie algorytmy czy struktury danych - są najbardziej podstawowym narzędziem do radzenia sobie ze złożonością. > > Wydaje mi się, że nie rozumiesz jednej rzeczy. > > > Jak ja Ci przedstawiam jakąś nową informację, to ja jej nie tracę, a stare informacje nie znikają. > > A jeśli są wyświetlane na ekranie smartfona? Stare muszą zniknąć, bo rozmiar ekranu jest ograniczony. To i tak możesz do nich wrócić. > > Jak piszę nowego posta na usenecie, to nie kasuję poprzedniego. > > Ale możesz edytować tego nowego, gdy się pomylisz. Sądzę, że to kwestia definicji. "Post" jest czymś, co zostało "zapostowane". > > To, że William Szekspir umarł, nie sprawia, że nie mogę o nim mówić, nie dostając błędu segmentacji pamięci. > > Ale żółwika z nim nie przybijesz. > > > Jeżeli od jakiegoś momentu postanowimy, żeby słowem "jabłko" określać konia, nie sprawi to, że nagle wszystkie jabłka staną się końmi, ani że wszystkie dotychczasowe użycia słowa "jabłko" będą dla wszystkich oznaczać konie. > > Ten przykład jest dla mnie za trudny. Właśnie ten jest najbardziej esencjonalny. > > Nawet w szkole, jak nauczyciel zmazuje tablicę, to Ty nie bierzesz korektora, i nie zamazujesz wszystkich swoich notatek. > > A jeśli piszę na tablecie? To chyba też nie kasujesz swoich notatek? > > Trudno to sobie uświadomić, > > Znowu mnie nie przekonałeś? Jak mówię, nie spodziewałem się, że ten przekaz zostanie zrozumiany. Nie wiem, jak to lepiej wyjaśnić. > > Choćby w Pythonie mamy coś takiego: > [...] > > Tak, Python jest źle zaprojektowany. Ale to nie jest przykład na problem z operacją przypisania. Są języki, gdzie ten sam przykład zadziała prawidłowo i zgodnie z intuicją. Zgodnie z czyją intuicją? Bo spotkałem osoby, które uznawały własnie takie zachowanie za pożądane. > Np. Wolfram. W C++ analogiczny przykład na kontenerach też zadziała poprawnie. "Poprawnie", czyli tak, jak Ty uważasz, że jest poprawnie? > > Prostota, o której ja piszę, nie jest prostotą implementacyjną, ale prostotą pojęciową > > I to jest dobre określenie. Podoba mi się i zgadzam się z nim. Za wyjątkiem oczywiście tego, że pomijanie aspektów implementacyjnych jest zwykle krótkowzroczne i sprawdza się tylko w prostych albo jednorazowych (często te cechy są razem) przykładach. Ja bym raczej powiedział, że jest to pewien model, który jest prosty do nauki i pozwala na unikniecie wielu błędów, ale który jest też ograniczony funkcjonalnie. > Zgodzę się jednak, że prostota pojęciowa to dobry cel w wielu zastosowaniach. Myślę jednak, że proponowane przez Ciebie rozwiązania zostaną kiedyś zastąpione przez coś w rodzaju asystentów AI, jak Wolfram Alpha: > > https://www.wolframalpha.com/input/?i=sum+of+first+seven+prime+numbers > > Jest prostota pojęciowa? Jest. Właściwie prościej się nie da. > Pozostaje zastosować to w większej skali, np. systemu finansowego. Nie mam wątpliwości, że taki jest właśnie kierunek rozwoju. Ja też nie mam. Ale składnia języka naturalnego moim zdaniem niezbyt dobrze nadaje się do programowania. Formalne notacje są dużo precyzyjniejsze (i właściwie po to zostały wymyślone)
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-01-10 02:31 -0800 |
| Message-ID | <50623263-8001-4a14-b2c4-4c9564c6c32e@googlegroups.com> |
| In reply to | #32301 |
[Dzielę odpowiedzi na kawałki, bo nie lubię wielowątkowych wypracowań.] > Programiści Lispa często wpadają na świetny pomysł dodania infiksowej składni dla operatorów arytmetycznych do Lispa. Nie chodziło konkretnie o operatory. Chodziło również o takie rzeczy jak możliwość zapisania macierzy w czytelnej postaci, logikę, operacje na zbiorach, itd., użycie bogatej symboliki operatorów (strzałki i takie tam), żeby nie wspomnieć o bezpośrednim użyciu obiektów multimedialnych typu obrazek albo dźwięk. > Później - niektórzy - uświadamiają sobie, że inni też mogą łatwo wymyślać, i że tak naprawdę żaden z tych pomysłów nie dodaje niczego, co by miało obiektywną wartość, Czytelność zapisu ma dla mnie subiektywną wartość, którą cenię. Już o tym pisałem. > > Wolfram jest o tyle ciekawy, że ma dwie albo trzy wewnętrznie równoważne składnie i pozwala posłużyć się taką, jaka jest w danym miejscu odpowiednia. > > Stephen Wolfram też ma za sobą rytuał przejścia. ? W ogóle nie rozumiem tego zdania. Ani tym bardziej, czy to dobrze, czy źle. A to ważne, bo nie wiem, czy mam się z tym zgodzić, czy nie zgodzić. > Tutaj mam np. "język dziedzinowy", [...] > > Wszystkie te języki są oparte na Lispowych s-wyrażeniach. Fajne. Nieczytelne. Trudno namówić klienta albo inną osobę spoza projektu do współpracy nad takimi plikami. > Sprawia to, że parsowanie wszystkich tych formatów jest trywialne Nie obchodzi mnie, czy jest trywialne. Jak to było? Po co rozwiązywać problem, skoro można go ominąć? To nie ja to parsuję. > (wystarczy do tego funkcja "read"), i do ich przetwarzania mogę > korzystać ze standardowych narzędzi, których używam też do swojego > języka programowania. Dokładnie to samo można powiedzieć o Wolframie (dlatego piszę, że parsowanie to nie mój problem), ale efekt końcowy jest czytelniejszy, jeśli mam do dyspozycji coś więcej, niż tylko okrągłe nawiasy. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-01-10 02:39 -0800 |
| Message-ID | <06c7553a-a0ca-4803-9e97-fb64e3bd17df@googlegroups.com> |
| In reply to | #32301 |
> > Przykład pokazuje, że Twoja metoda funkcyjno-podstawieniowa tworzy zamknięty ciąg, którego nie da się rozwijać. Poprosiłem o implementację nowego wymagania w tym samym "projekcie". Pokażesz? Przecież stwierdziliśmy, że kod jest lepszy od słów. > > Toteż chyba zamiast kodu będziesz się musiał zadowolić śmiesznym obrazkiem: > https://xkcd.com/1425/ Nie, jednak poproszę o kod. Napisałeś program, który dodaje kwadraty pierwszych siedmiu liczb pierwszych. Ja proszę o implementację dodatkowego wymagania: "a te liczby, które nie są pierwsze, też można do siebie dodać" W czym problem? > To nie jest "zmiana wymagania". > To jest inny program W Twoim języku. I to jest właśnie jego ograniczenie. Ale w imperatywnym przykładzie Fira to nie byłby inny program, tylko ten sam program, z dodatkowym kodem implementującym to dodatkowe wymaganie. I dlatego to jest przykład na ukryty koszt (do zapłacenia w przyszłości, czyli normalny dług techniczny) rozwiązań, które promujesz. Dlatego dziękuję, ale nie, dziękuję. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-01-10 02:49 -0800 |
| Message-ID | <9f27bf03-d9c5-411f-8cad-0a1f32e1c5b7@googlegroups.com> |
| In reply to | #32301 |
> > > > 2. Programowanie imperatywne w żaden sposób nie wyklucza analizy podstawieniowej. > > > > > > Ok, w takim razie weź kod fira, który przekleiłem do swojej odpowiedzi, i pokaż nam, jak by dla niego taka analiza podstawieniowa wyglądała. > > > > A na jakie pytanie chciałbyś taką analizą odpowiedzieć? > > Na przykład, jaki ten program da wynik dla argumentu "7". Uruchamiamy program i mamy wynik. Co ciekawe, są programy, których wykonania nie da się pominąć. I nie całkiem to miałem na myśli pisząc o analizie - bardziej mnie interesuje np. czy program nie wykona niewłaściwej operacji (jak dzielenie przez zero). Tutaj metody analizy mają podobną moc. https://www.hillelwayne.com/post/theorem-prover-showdown/ "I keep hearing that it’s easier to analyze pure functional code than mutable imperative code. But nobody gives rigorous arguments for this and nobody provides concrete examples. Nobody actually digs into why assignments and transitions are so much harder to reason about than pure functions ..." Ciekawe? to czytaj dalej. Człowiek zrobił konkurs i zaprosił do niego zwolenników obu obozów, żeby pokazali siłę swoich rozwiązań. Wiesz, kto wygrał? Nikt nie wygrał. Wszyscy robili tak samo źle (!). Z "Final thoughts": "the claim “it’s easier to reason about FP than imperative” is wrong" Ale polecam całość, bo oczywiście problem jest wielowymiarowy. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-10 03:52 -0800 |
| Message-ID | <50978c3d-3712-4204-93c8-8af43f0d020c@googlegroups.com> |
| In reply to | #32312 |
W dniu czwartek, 10 stycznia 2019 11:49:03 UTC+1 użytkownik Maciej Sobczak napisał: > > > > > 2. Programowanie imperatywne w żaden sposób nie wyklucza analizy podstawieniowej. > > > > > > > > Ok, w takim razie weź kod fira, który przekleiłem do swojej odpowiedzi, i pokaż nam, jak by dla niego taka analiza podstawieniowa wyglądała. > > > > > > A na jakie pytanie chciałbyś taką analizą odpowiedzieć? > > > > Na przykład, jaki ten program da wynik dla argumentu "7". > > Uruchamiamy program i mamy wynik. Co ciekawe, są programy, których wykonania nie da się pominąć. No właśnie tu jest sedno problemu. Program funkcyjny mogę wyjaśnić w terminach podstawiania wartości za wyrażenia, a programu imperatywnego nie mogę. Mogę w najlepszym razie przesymulować przebieg jakiejś maszyny. Jest to możliwe, ale jest trudniejsze (ma większy narzut kognitywny) > I nie całkiem to miałem na myśli pisząc o analizie - bardziej mnie interesuje np. czy program nie wykona niewłaściwej operacji (jak dzielenie przez zero). Tutaj metody analizy mają podobną moc. > > https://www.hillelwayne.com/post/theorem-prover-showdown/ > > "I keep hearing that it’s easier to analyze pure functional code than mutable imperative code. But nobody gives rigorous arguments for this and nobody provides concrete examples. Nobody actually digs into why assignments and transitions are so much harder to reason about than pure functions ..." > > Ciekawe? to czytaj dalej. Człowiek zrobił konkurs i zaprosił do niego zwolenników obu obozów, żeby pokazali siłę swoich rozwiązań. > > Wiesz, kto wygrał? > > Nikt nie wygrał. Wszyscy robili tak samo źle (!). > > Z "Final thoughts": > > "the claim “it’s easier to reason about FP than imperative” is wrong" > > Ale polecam całość, bo oczywiście problem jest wielowymiarowy. Tak, jest. I ja też się zgadzam z wieloma obserwacjami Hillela. Uważam że on i ten jego kolega, Ron Pressler, prezentują bardzo wyważone podejście do tego zagadnienia. Też spotykam się z osobami, które twierdzą, że programowanie funkcyjne jest lepsze, bo tak, albo że używanie monady IO to programowanie funkcyjne. Programowanie funkcyjne ma tę zaletę, że takie programy można sobie analizować, podstawiając wartości za wyrażenia. I na tym, być może, kończy się lista zalet. (Może nie. Może też systemy typów pozwalają wyrażać jakieś własności, co ma pewną dodatkową wartość w niektórych przypadkach. Może też niektóre problemy znajdują elegantszy wyraz w językach funkcyjnych. No ale inne pewnie nie). Ja nie mówię - i to od początku tego nie mówię - że nie należy stosować operatora przypisania. Mówię, że tam, gdzie nie jest to konieczne, lepiej tego unikać.
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-01-10 02:56 -0800 |
| Message-ID | <ac203613-5405-4dbd-bedb-4edc6f8e81cc@googlegroups.com> |
| In reply to | #32301 |
> > Tak, Python jest źle zaprojektowany. Ale to nie jest przykład na problem z operacją przypisania. Są języki, gdzie ten sam przykład zadziała prawidłowo i zgodnie z intuicją.
>
> Zgodnie z czyją intuicją?
Z Twoją. Przecież to Ty podałeś ten przykład jako prezentację problemu. Więc zakładam, że to Ty uważasz, że w tym przykładzie jest jakiś problem.
> Bo spotkałem osoby, które uznawały własnie takie zachowanie za pożądane.
"Każda potwora znajdzie swego amatora." :-)
> > Np. Wolfram. W C++ analogiczny przykład na kontenerach też zadziała poprawnie.
>
> "Poprawnie", czyli tak, jak Ty uważasz, że jest poprawnie?
To Ty pokazałeś ten przykład, pamiętasz? Czy może jest Was więcej?
Ale ja też mogę pokazać przykład w Pythonie:
x = 0
def fun1():
y = x
def fun2():
x = x
print("calling fun1")
fun1()
print("calling fun2")
fun2()
Jedna funkcja działa a druga nie działa. I ta druga robi błąd, którego nie da się wyjaśnić na podstawie specyfikacji języka. Tak było od zawsze, zarówno w 2.x jak i w 3.x. Zabawka, nie język.
[Wolfram Alpha]
> Ale składnia języka naturalnego moim zdaniem niezbyt dobrze nadaje się do programowania.
Bo tu chodziło o to, żeby nie trzeba było programować. Sam to napisałeś - lepiej problem ominąć, niż go rozwiązywać.
> Formalne notacje są dużo precyzyjniejsze
Pytanie teraz, które. Bo właśnie o to się od początku kłócimy. :-)
--
Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-10 03:30 -0800 |
| Message-ID | <59907852-4d61-49da-aed5-632de5bf8886@googlegroups.com> |
| In reply to | #32313 |
W dniu czwartek, 10 stycznia 2019 11:56:03 UTC+1 użytkownik Maciej Sobczak napisał:
> > > Tak, Python jest źle zaprojektowany. Ale to nie jest przykład na problem z operacją przypisania. Są języki, gdzie ten sam przykład zadziała prawidłowo i zgodnie z intuicją.
> >
> > Zgodnie z czyją intuicją?
>
> Z Twoją. Przecież to Ty podałeś ten przykład jako prezentację problemu. Więc zakładam, że to Ty uważasz, że w tym przykładzie jest jakiś problem.
Tak, uważam że jest.
Ale nie uważam, że tym problemem jest to, że Python to robi w taki
a nie inny sposób. Uważam, że problemem jest to, że masz dwie dopuszczalne
interpretacje, i żadna nie jest bezwzględnie lepsza od innej, tzn.
można sensownie bronić każdej z nich.
> > Bo spotkałem osoby, które uznawały własnie takie zachowanie za pożądane.
>
> "Każda potwora znajdzie swego amatora." :-)
>
> > > Np. Wolfram. W C++ analogiczny przykład na kontenerach też zadziała poprawnie.
> >
> > "Poprawnie", czyli tak, jak Ty uważasz, że jest poprawnie?
>
> To Ty pokazałeś ten przykład, pamiętasz?
Pamiętam. I pamiętam też, że od razu zwróciłem uwagę, że możliwe są
(przynajmniej) dwa zachowania, których można bronić.
> Ale ja też mogę pokazać przykład w Pythonie:
No ja jeszcze lubię np. takie coś:
>>> def f(x={}):
... return x
>>> a = f()
>>> a
{}
>>> a['x'] = 5
>>> a
{'x':5}
>>> b = f()
>>> b
{'x':5}
### W T F
> > Ale składnia języka naturalnego moim zdaniem niezbyt dobrze nadaje się do programowania.
>
> Bo tu chodziło o to, żeby nie trzeba było programować. Sam to napisałeś - lepiej problem ominąć, niż go rozwiązywać.
>
> > Formalne notacje są dużo precyzyjniejsze
>
> Pytanie teraz, które. Bo właśnie o to się od początku kłócimy. :-)
Chyba Ty się kłócisz ;P
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-01-10 12:55 +0100 |
| Message-ID | <q17bsf$1157$1@gioia.aioe.org> |
| In reply to | #32314 |
On 2019-01-10 12:30, godek.maciek@gmail.com wrote:
>
>> Ale ja też mogę pokazać przykład w Pythonie:
>
> No ja jeszcze lubię np. takie coś:
>
>>>> def f(x={}):
> .... return x
Przeciez pisza wyraznie w _kazdej ksiazce do Pythona_,
ze takie uzycie to jest to blad, gdy "metkowanie"
argumentow domyslych jest wykonywane w momencie _definicji_,
a nie wywolania funkcji.
To standardowe pytanie przy wlasciwie kazdej rozmowie o prace
w Py, a kazdy byle Pythonista zna idiom w rodzaju.
def f(x=None):
x = x or {}
return x
AK
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-10 04:00 -0800 |
| Message-ID | <c7c40d94-efb6-4609-b1d3-9e591381a1f8@googlegroups.com> |
| In reply to | #32317 |
W dniu czwartek, 10 stycznia 2019 12:56:02 UTC+1 użytkownik AK napisał:
> >> Ale ja też mogę pokazać przykład w Pythonie:
> >
> > No ja jeszcze lubię np. takie coś:
> >
> >>>> def f(x={}):
> > .... return x
>
> Przeciez pisza wyraznie w _kazdej ksiazce do Pythona_,
> ze takie uzycie to jest to blad, gdy "metkowanie"
> argumentow domyslych jest wykonywane w momencie _definicji_,
> a nie wywolania funkcji.
Nie czytałem każdej książki do Pythona, to się nie mogę
zgodzić ani nie zgodzić (ale wystarczy znaleźć jedną, w której
o tym nie piszą, żeby sfalsyfikować to stwierdzenie,
a żeby je zweryfikować, trzeba przeczytać wszystkie)
> To standardowe pytanie przy wlasciwie kazdej rozmowie o prace
> w Py, a kazdy byle Pythonista zna idiom w rodzaju.
>
> def f(x=None):
> x = x or {}
> return x
Czyli zamiast rozwiązać problem dobrze, rozwiązuje się go źle,
a potem wymyśla się idiomy na obejście tego złego rozwiązania.
No, można i tak.
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-01-10 14:02 +0100 |
| Message-ID | <q17fpf$1j06$1@gioia.aioe.org> |
| In reply to | #32318 |
On 2019-01-10 13:00, godek.maciek@gmail.com wrote:
> Nie czytałem każdej książki do Pythona, to się nie mogę
> zgodzić ani nie zgodzić (ale wystarczy znaleźć jedną, w której
Wiesz co?
Nie wymyslaj. To wiedza na poziomie np w C: "co to jest pointer"
> o tym nie piszą, żeby sfalsyfikować to stwierdzenie,
> a żeby je zweryfikować, trzeba przeczytać wszystkie)
>
>> To standardowe pytanie przy wlasciwie kazdej rozmowie o prace
>> w Py, a kazdy byle Pythonista zna idiom w rodzaju.
>>
>> def f(x=None):
>> x = x or {}
>> return x
>
> Czyli zamiast rozwiązać problem dobrze, rozwiązuje się go źle,
> a potem wymyśla się idiomy na obejście tego złego rozwiązania.
>
> No, można i tak.
Ano mozna.
Zwlaszcza, ze jest to zgodne ze z podstawowa logika i
specyfika Pythona (metkowanie).
Kwestia czy zle (przylaczam sie do twierdzenia ze jest to mylace,
- choc wylacznie dla poczatkujacych), czy dobrze (przy rekurencji
przydatne czesto) jest dyskusyjna.
PS: Innym podejsciam jest zastosowanie czegos w rodzaju:
def f(x=on_the_call(None)):
return x
AK
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-01-10 14:11 +0100 |
| Message-ID | <q17g9j$1kqb$1@gioia.aioe.org> |
| In reply to | #32319 |
On 2019-01-10 14:02, AK wrote:
> def f(x=on_the_call(None)):
> return x
def f(x=on_the_call({})):
return x
AK
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-10 05:22 -0800 |
| Message-ID | <4241c028-206b-49cf-8f0c-cd5b70f9683e@googlegroups.com> |
| In reply to | #32319 |
W dniu czwartek, 10 stycznia 2019 14:02:42 UTC+1 użytkownik AK napisał: > > No, można i tak. > > Ano mozna. > Zwlaszcza, ze jest to zgodne ze z podstawowa logika i > specyfika Pythona (metkowanie). A jaka jest "podstawowa logika i specyfika Pythona", z której by ta zgodność wynikała? > Kwestia czy zle (przylaczam sie do twierdzenia ze jest to mylace, > - choc wylacznie dla poczatkujacych), czy dobrze (przy rekurencji > przydatne czesto) jest dyskusyjna. To może podaj kilka argumentów na rzecz takiego rozwiązania (bo ja serio nie widzę żadnego) > PS: Innym podejsciam jest zastosowanie czegos w rodzaju: > > def f(x=on_the_call(None)): > return x Czyli mamy co najmniej dwa złe idiomy zamiast jednego dobrego rozwiązania.
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-01-10 15:47 +0100 |
| Message-ID | <q17ltn$fmv$1@gioia.aioe.org> |
| In reply to | #32321 |
On 2019-01-10 14:22, godek.maciek@gmail.com wrote:
> W dniu czwartek, 10 stycznia 2019 14:02:42 UTC+1 użytkownik AK napisał:
>
>>> No, można i tak.
>>
>> Ano mozna.
>> Zwlaszcza, ze jest to zgodne ze z podstawowa logika i
>> specyfika Pythona (metkowanie).
>
> A jaka jest "podstawowa logika i specyfika Pythona",
> z której by ta zgodność wynikała?
Metkowanie.
1. Obiekty w Pythonie sa wylacznie "metkowane".
Kopiowane sa wylacznie prymitywy (int , float, bool i.. i chyba tyle).
2. definicja funkcji to jest _statement_ wiec wszystko co podlega
ewaluacji, jest _wlasnie wtedy_ ewaluowane.
Stad wartosci domyslne sa ewaluowane w momencie wykonania
_statementu_ def function().
>> Kwestia czy zle (przylaczam sie do twierdzenia ze jest to mylace,
>> - choc wylacznie dla poczatkujacych), czy dobrze (przy rekurencji
>> przydatne czesto) jest dyskusyjna.
>
> To może podaj kilka argumentów na rzecz takiego rozwiązania
> (bo ja serio nie widzę żadnego)
W rekurencji latwo zapamietac jakas "sciezke" wlasnie w takim
parametrze.
No ale przyklad z tej dyskusji.
pierwsze = [2]
def jest_pierwsza(liczba, pierwsze=pierwsze):
erasto = int(sqrt(liczba) + 0.5)
czy_pierwsza = all(liczba % pierwsza for pierwsza in pierwsze
if pierwsza <= erasto)
if czy_pierwsza: pierwsze.append(liczba)
return czy_pierwsza
Mozna zapisac tak:
def jest_pierwsza(liczba, pierwsze=[2]):
erasto = int(sqrt(liczba) + 0.5)
czy_pierwsza = all(liczba % pierwsza for pierwsza in pierwsze
if pierwsza <= erasto)
if czy_pierwsza: pierwsze.append(liczba)
return czy_pierwsza
Po co tworzyc niepotrzebnie globala/statica jesli jest on potrzebny
tylko wewnetrznie?
Jak wiadomo Python nie posiada takiej konstrukcji zmiennych/obiektow
statycznych funkcji w takim sensie jak C
int fun()
{
static int = 3;
}
wiec w ten sposob tworzy sie w Pythonie wlasnie zmienne statyczne
nie zasmiecajac wyzszego namespace.
>> PS: Innym podejsciam jest zastosowanie czegos w rodzaju:
>>
>> def f(x=on_the_call(None)):
>> return x
>
> Czyli mamy co najmniej dwa złe idiomy zamiast jednego dobrego rozwiązania.
Dlaczego zle ?
Nie widze w nich nic zlego.
Zwlaszcza w stosunku do expr w takim Lisp gdzie nawet priorytet
opeatorow poszedl do kosza wiec trzeba go wymuszac odpowiednia
kolejnoscia ewaluacji i/lub nawiasami (a nawet trzeba wymuszac/okreslac
tymiz lewo-prawo-lacznosc operatorow).
Np: (* A (* B (* C D))) to co innego niz (* (* (* C D) B) A)
Przecie to nieskonczone zrodlo pomylek.
PS: Tylko mi nie probuj mowic, ze jest inaczej bo drzewiej
pisywalem (fakt ze rzadko, nie umialem sie przekonac:) w AutoLispie
makra do AutoCADa "cus tam" liczace i... to dla numeryka byl
istny koszmar :(
W porzadnych jezykach programowania kolejnosc obliczania expr. byla
zawsze od lewa do prawa, a priorytet operatorow jest scisle okreslony
i dla arytmetycznych zgodny z normalna matematyka.
Oczywiscie C/C++ to popsul bo w nim stwierdzono (z wydumanych wzgledow
wydajnosciowych oczywscie:) ze kolejnosc ewaluacji czesci wyrazen jest
.. dowolna co rowniez jest zrodlem niekiedy koszmarow (gdy
funckcje maja efekty uboczne - a miewaja czesciej niz sie wydaje:).
PS: Nawiasy nie pomoga. Nawiasy w C/C++ wymuszaja priorytety, ale nie
kolejnosc ewaluacji wyrazen.
Np takie cus w Algolu, Pascalu, Fortranie, PL/I, Javie, C# czy innym
Pythonie:
double y = 3;
double fun(double x)
{
y += x;
return y;
}
z = 2 * fun(3) + fun(7);
byloby jednoznaczne (wynik 25), ale juz w C/C++ moze to byc
albo 25 albo 36 (zaleznie od kierunku wiatru, kompilatora,
gestosci Slonca, % w nalewce Szwagra itp).
AK
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-11 10:14 -0800 |
| Message-ID | <f943575a-0378-403c-822d-5dd69bfdc2ff@googlegroups.com> |
| In reply to | #32322 |
W dniu czwartek, 10 stycznia 2019 15:47:22 UTC+1 użytkownik AK napisał:
> >>> No, można i tak.
> >>
> >> Ano mozna.
> >> Zwlaszcza, ze jest to zgodne ze z podstawowa logika i
> >> specyfika Pythona (metkowanie).
> >
> > A jaka jest "podstawowa logika i specyfika Pythona",
> > z której by ta zgodność wynikała?
>
> Metkowanie.
> 1. Obiekty w Pythonie sa wylacznie "metkowane".
> Kopiowane sa wylacznie prymitywy (int , float, bool i.. i chyba tyle).
Tzn. przekazywane przez referencję?
> 2. definicja funkcji to jest _statement_ wiec wszystko co podlega
> ewaluacji, jest _wlasnie wtedy_ ewaluowane.
> Stad wartosci domyslne sa ewaluowane w momencie wykonania
> _statementu_ def function().
A jakie są pozostałe "statementy"?
> >> Kwestia czy zle (przylaczam sie do twierdzenia ze jest to mylace,
> >> - choc wylacznie dla poczatkujacych), czy dobrze (przy rekurencji
> >> przydatne czesto) jest dyskusyjna.
> >
> > To może podaj kilka argumentów na rzecz takiego rozwiązania
> > (bo ja serio nie widzę żadnego)
>
> W rekurencji latwo zapamietac jakas "sciezke" wlasnie w takim
> parametrze.
>
> No ale przyklad z tej dyskusji.
>
> pierwsze = [2]
> def jest_pierwsza(liczba, pierwsze=pierwsze):
> erasto = int(sqrt(liczba) + 0.5)
> czy_pierwsza = all(liczba % pierwsza for pierwsza in pierwsze
> if pierwsza <= erasto)
> if czy_pierwsza: pierwsze.append(liczba)
> return czy_pierwsza
>
> Mozna zapisac tak:
>
> def jest_pierwsza(liczba, pierwsze=[2]):
> erasto = int(sqrt(liczba) + 0.5)
> czy_pierwsza = all(liczba % pierwsza for pierwsza in pierwsze
> if pierwsza <= erasto)
> if czy_pierwsza: pierwsze.append(liczba)
> return czy_pierwsza
>
> Po co tworzyc niepotrzebnie globala/statica jesli jest on potrzebny
> tylko wewnetrznie?
> Jak wiadomo Python nie posiada takiej konstrukcji zmiennych/obiektow
> statycznych funkcji w takim sensie jak C
>
> int fun()
> {
> static int = 3;
> }
>
> wiec w ten sposob tworzy sie w Pythonie wlasnie zmienne statyczne
> nie zasmiecajac wyzszego namespace.
Można też użyć do tego celu "domknięcia", albo klasy.
Przekazanie parametru rekurencyjnie do funkcji to nic trudnego
> >> PS: Innym podejsciam jest zastosowanie czegos w rodzaju:
> >>
> >> def f(x=on_the_call(None)):
> >> return x
> >
> > Czyli mamy co najmniej dwa złe idiomy zamiast jednego dobrego rozwiązania.
>
> Dlaczego zle ?
> Nie widze w nich nic zlego.
Sam powiedziałeś, że "bywa mylące".
Ja uważam, że jest mylące z dobrych powodów.
> Zwlaszcza w stosunku do expr w takim Lisp gdzie nawet priorytet
> opeatorow poszedl do kosza wiec trzeba go wymuszac odpowiednia
> kolejnoscia ewaluacji i/lub nawiasami (a nawet trzeba wymuszac/okreslac
> tymiz lewo-prawo-lacznosc operatorow).
> Np: (* A (* B (* C D))) to co innego niz (* (* (* C D) B) A)
> Przecie to nieskonczone zrodlo pomylek.
?
Jakich pomyłek?
W każdym języku f(x, f(y, f(z, w))) to raczej coś innego niż
f(f(f(z, w), y, x).
I to nie jest "wymuszanie nawiasami lewo-prawo-łączności operatorów",
bo w Lispie syntaktyczine w ogóle nie ma czegoś takiego.
Akurat operator mnożenia jest (semantycznie) łączny i przemienny,
toteż nie ma znaczenia, czy napiszesz tak, czy inaczej.
Możesz też napisać (* A B C D) albo (* C D B A).
> PS: Tylko mi nie probuj mowic, ze jest inaczej bo drzewiej
> pisywalem (fakt ze rzadko, nie umialem sie przekonac:) w AutoLispie
> makra do AutoCADa "cus tam" liczace i... to dla numeryka byl
> istny koszmar :(
Co ja mam Ci próbować wmówić?
Jak czegoś nie lubisz, to to Twoja sprawa.
> W porzadnych jezykach programowania kolejnosc obliczania expr. byla
> zawsze od lewa do prawa, a priorytet operatorow jest scisle okreslony
> i dla arytmetycznych zgodny z normalna matematyka.
Lepiej zamiast "normalna matematyka" powiedzieć
"matematyka, której mnie uczono".
> Oczywiscie C/C++ to popsul bo w nim stwierdzono (z wydumanych wzgledow
> wydajnosciowych oczywscie:) ze kolejnosc ewaluacji czesci wyrazen jest
> .. dowolna co rowniez jest zrodlem niekiedy koszmarow (gdy
> funckcje maja efekty uboczne - a miewaja czesciej niz sie wydaje:).
W "normalnej matematyce" funkcje nie mają efektów ubocznych.
> PS: Nawiasy nie pomoga. Nawiasy w C/C++ wymuszaja priorytety, ale nie
> kolejnosc ewaluacji wyrazen.
> Np takie cus w Algolu, Pascalu, Fortranie, PL/I, Javie, C# czy innym
> Pythonie:
> double y = 3;
> double fun(double x)
> {
> y += x;
> return y;
> }
> z = 2 * fun(3) + fun(7);
> byloby jednoznaczne (wynik 25), ale juz w C/C++ moze to byc
> albo 25 albo 36 (zaleznie od kierunku wiatru, kompilatora,
> gestosci Slonca, % w nalewce Szwagra itp).
No i bardzo dobrze.
Przynajmniej zniechęca ludzi do pisania takich programów.
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-01-11 21:31 +0100 |
| Message-ID | <q1aufn$15m2$1@gioia.aioe.org> |
| In reply to | #32326 |
On 2019-01-11 19:14, godek.maciek@gmail.com wrote:
> W dniu czwartek, 10 stycznia 2019 15:47:22 UTC+1 użytkownik AK napisał:
>
>> Metkowanie.
>> 1. Obiekty w Pythonie sa wylacznie "metkowane".
>> Kopiowane sa wylacznie prymitywy (int , float, bool i.. i chyba tyle).
>
> Tzn. przekazywane przez referencję?
Nie. To jednak nie jest to samo co referencja w C++ czy innej
Javie.
>
>> 2. definicja funkcji to jest _statement_ wiec wszystko co podlega
>> ewaluacji, jest _wlasnie wtedy_ ewaluowane.
>> Stad wartosci domyslne sa ewaluowane w momencie wykonania
>> _statementu_ def function().
>
> A jakie są pozostałe "statementy"?
Takie jak w manualu.
>>>> Kwestia czy zle (przylaczam sie do twierdzenia ze jest to mylace,
>>>> - choc wylacznie dla poczatkujacych), czy dobrze (przy rekurencji
>>>> przydatne czesto) jest dyskusyjna.
>>>
>>> To może podaj kilka argumentów na rzecz takiego rozwiązania
>>> (bo ja serio nie widzę żadnego)
>>
>> W rekurencji latwo zapamietac jakas "sciezke" wlasnie w takim
>> parametrze.
>>
>> No ale przyklad z tej dyskusji.
>>
>> pierwsze = [2]
>> def jest_pierwsza(liczba, pierwsze=pierwsze):
>> erasto = int(sqrt(liczba) + 0.5)
>> czy_pierwsza = all(liczba % pierwsza for pierwsza in pierwsze
>> if pierwsza <= erasto)
>> if czy_pierwsza: pierwsze.append(liczba)
>> return czy_pierwsza
>>
>> Mozna zapisac tak:
>>
>> def jest_pierwsza(liczba, pierwsze=[2]):
>> erasto = int(sqrt(liczba) + 0.5)
>> czy_pierwsza = all(liczba % pierwsza for pierwsza in pierwsze
>> if pierwsza <= erasto)
>> if czy_pierwsza: pierwsze.append(liczba)
>> return czy_pierwsza
>>
>> Po co tworzyc niepotrzebnie globala/statica jesli jest on potrzebny
>> tylko wewnetrznie?
>> Jak wiadomo Python nie posiada takiej konstrukcji zmiennych/obiektow
>> statycznych funkcji w takim sensie jak C
>>
>> int fun()
>> {
>> static int = 3;
>> }
>>
>> wiec w ten sposob tworzy sie w Pythonie wlasnie zmienne statyczne
>> nie zasmiecajac wyzszego namespace.
>
> Można też użyć do tego celu "domknięcia", albo klasy.
Po co ?
PS: Owszem, Przy wiekszej ilosci danych/atrybutow uzywa sie w Py klasy,
named tuple, slownika, domkniec itp itp.
> Przekazanie parametru rekurencyjnie do funkcji to nic trudnego
Po co przekazywac "z gory" jesli mozna to samo uzyskac
w lokalnym scope ? No po co ? Bo?
>>>> PS: Innym podejsciam jest zastosowanie czegos w rodzaju:
>>>>
>>>> def f(x=on_the_call(None)):
>>>> return x
>>>
>>> Czyli mamy co najmniej dwa złe idiomy zamiast jednego dobrego rozwiązania.
>>
>> Dlaczego zle ?
>> Nie widze w nich nic zlego.
>
> Sam powiedziałeś, że "bywa mylące".
> Ja uważam, że jest mylące z dobrych powodów.
No jesli sie nie czyta wpierw nic o jezyku/manuali
to wszytsko bywa mylace :)
Poza tym to bardzo standardowe idiomy.
Wszedzie w Py spotykane.
>> Zwlaszcza w stosunku do expr w takim Lisp gdzie nawet priorytet
>> opeatorow poszedl do kosza wiec trzeba go wymuszac odpowiednia
>> kolejnoscia ewaluacji i/lub nawiasami (a nawet trzeba wymuszac/okreslac
>> tymiz lewo-prawo-lacznosc operatorow).
>> Np: (* A (* B (* C D))) to co innego niz (* (* (* C D) B) A)
>> Przecie to nieskonczone zrodlo pomylek.
> ?
> Jakich pomyłek?
> W każdym języku f(x, f(y, f(z, w))) to raczej coś innego niż
> f(f(f(z, w), y, x).
Tyle ze przy mnozeniu jest to to samo.
Chodzi o to ze trzeba ciagle pilnowac priorytetow operatorow
(czy kolejnisci) przez odpowednie konstrukcje - czyli na bakier
normalnej metematyce. Notacja Lisp akurat wyrazeniom arytmetycznym
wyraznie szkodzi i nie ma co tego tlumaczyc "elegancja" czy
"czystoscia" paradygmatow jezyka. To syf w uzyciu i tyle!
> I to nie jest "wymuszanie nawiasami lewo-prawo-łączności operatorów",
> bo w Lispie syntaktyczine w ogóle nie ma czegoś takiego.
> Akurat operator mnożenia jest (semantycznie) łączny i przemienny,
> toteż nie ma znaczenia, czy napiszesz tak, czy inaczej.
Ma znaczenie bo w jezykach programowania _istnieja efekty
uboczne_ i kolejnosc ewaluacji (od lewa do prawa) MA
znaczenie.
> Możesz też napisać (* A B C D) albo (* C D B A).
Moge. Tylko czy to wyglada na zapis matematyczny?
Toz to zwykla lista :)
>
>> PS: Tylko mi nie probuj mowic, ze jest inaczej bo drzewiej
>> pisywalem (fakt ze rzadko, nie umialem sie przekonac:) w AutoLispie
>> makra do AutoCADa "cus tam" liczace i... to dla numeryka byl
>> istny koszmar :(
>
> Co ja mam Ci próbować wmówić?
> Jak czegoś nie lubisz, to to Twoja sprawa.
Nie lubie dlatego, ze nie lubie.
Nie lubie, bo sprawia tak wiele niedogodnosci,
ze odciaga od domeny na rzecz młotka.
>
>> W porzadnych jezykach programowania kolejnosc obliczania expr. byla
>> zawsze od lewa do prawa, a priorytet operatorow jest scisle okreslony
>> i dla arytmetycznych zgodny z normalna matematyka.
>
> Lepiej zamiast "normalna matematyka" powiedzieć
> "matematyka, której mnie uczono".
Mnie uczono normalnej a nie (pre-post-s)fiksowanej.
>
>> Oczywiscie C/C++ to popsul bo w nim stwierdzono (z wydumanych wzgledow
>> wydajnosciowych oczywscie:) ze kolejnosc ewaluacji czesci wyrazen jest
>> .. dowolna co rowniez jest zrodlem niekiedy koszmarow (gdy
>> funckcje maja efekty uboczne - a miewaja czesciej niz sie wydaje:).
>
> W "normalnej matematyce" funkcje nie mają efektów ubocznych.
Programowanie "realne" to nie matematyka i efekty uboczne
sa "immanentna czescia" nie tylko C++.
W "moich czasach" nie mowilo sie "funkcje" ale "procedury".
Nazwe "funkcje" (intencjonalnie) zostawialo sie matematyce.
Algol/Simula"
integer procedure A()
begin
end
real procedure A()
begin
end
procedure C()
begin
end
>> PS: Nawiasy nie pomoga. Nawiasy w C/C++ wymuszaja priorytety, ale nie
>> kolejnosc ewaluacji wyrazen.
>> Np takie cus w Algolu, Pascalu, Fortranie, PL/I, Javie, C# czy innym
>> Pythonie:
>> double y = 3;
>> double fun(double x)
>> {
>> y += x;
>> return y;
>> }
>> z = 2 * fun(3) + fun(7);
>> byloby jednoznaczne (wynik 25), ale juz w C/C++ moze to byc
>> albo 25 albo 36 (zaleznie od kierunku wiatru, kompilatora,
>> gestosci Slonca, % w nalewce Szwagra itp).
>
> No i bardzo dobrze.
> Przynajmniej zniechęca ludzi do pisania takich programów.
Masz Ty pojecie o produkcyjnym rzemiosle?
Jesli mozna, to ludzie pisza zle i tyle.
Zaden jezyk przed tym nie uchroni, lecz powinien przynajmniej
zadbac, aby wyniki byly powtarzalne i nie zalezaly od kierunku wiatru.
Jezyki takie jak Algolu/Simula, Pascalu, Modula2, Fortran, PL/I, Java,
Python, C#, VB o to zadbaly. C++ nie.
AK
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | pl.comp.programming
csiph-web