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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2018-12-29 03:27 -0800 |
| Message-ID | <177b2553-5b38-4a17-9031-3d3397407caa@googlegroups.com> |
| In reply to | #32169 |
W dniu piątek, 28 grudnia 2018 23:07:15 UTC+1 użytkownik Maciej Sobczak napisał:
> > Przykłady podałem w linku (i szczerze wątpię, żeby potomność
> > zechciała kiedykolwiek grzebać na tym śmietnisku).
>
> W linku był artykuł o kiepskim kodzie, który znalazłeś w necie. Krytyka języka z tego żadna. Zwłaszcza w przypadku języka, który jest popularny a przez to używany również przez tych, którzy uniwersalnie piszą kiepski kod.
Nic dziwnego, że "krytyka języka z tego żadna", bo to nie była
krytyka języka. Twoje pytanie, na ile je zrozumiałem, dotyczyło
złych nawyków.
> [operator przypisania]
>
> > W większości miejsc nie jest konieczne.
> > A jest to zły nawyk, ponieważ - mówiąc skrótowo - zwiększa złożoność
> > środków analizy programów
>
> Nie, nie zwiększa.
Owszem, zwiększa.
> Albo, jeśli faktycznie zwiększa, to jest to problem autorów takich narzędzi a nie użytkowników języka. Jako użytkownik języka akceptuję ten układ. Ba - ja go nawet akceptuję jako autor takiego narzędzia.
Otóż to właśnie jest problem użytkowników języka.
Proponuję, żebyś - zamiast zgadywać w ciemno o czym mówię
- spróbował przeczytać tę książkę, i dopiero wtedy się
wypowiedzieć.
To dobra książka, naprawdę. Może na początku wydawać się
"zbyt banalna", zwłaszcza dla kogoś, kto ma już doświadczenie
z programowaniem. Ale owo wrażenie szybko ustępuje.
> > Dokładniej jest to wyjaśnione tutaj:
> [link do sicp]
>
> Rozumiem - czyli w Scheme zwiększa. Trudno, jest to problem języka Scheme. I autorów narzędzi analizy tego języka.
Jest to w takim samym stopniu "problem języka Scheme",
jak "problem języków" takich jak Erlang, Haskell, Java, C++,
Mathematica, Pascal i wielu innych.
> Ale dlaczego to ma być zły nawyk w C++ (czy w jakimkolwiek języku imperatywnym, bo problem jest ogólny), to nadal nie rozumiem.
To przeczytaj książkę.
> > Pytasz o moje doświadczenia, to Ci mówię.
>
> Ale jeśli Twoje doświadczenia to kiepski kod znaleziony w necie, to można mieć też dobre doświadczenia.
Moje doświadczenia są różne.
Swoją wiedzę o C++ czerpałem głównie z ksiązki Stroustrupa "Język C++"
oraz z książki Kernighana i Pike'a "Lekcja programowania".
Jeżeli idzie o inne źródła, z których się uczyłem, to opisałem to
kiedyś tutaj:
https://www.quora.com/What-is-something-you-wish-you-knew-when-you-first-started-functional-programming/answer/Panicz-Godek
> > Jeżeli Cię nie interesują albo masz sobie z nich szydzić,
> > to nie pytaj.
>
> Pytam, bo zostawiasz swoje posty w stanie niedopowiedzenia ("C++ tworzy złe nawyki, bo tak"). Potem ktoś to przeczyta i pomyśli, że tak faktycznie jest. Tymczasem, w przypadku niedopowiedzeń, jest pole do dyskusji i chcę je pokazać.
Nie napisałem że "C++ tworzy złe nawyki, bo tak". Napisałem
coś takiego:
"ja sam musiałem oduczać się różnych złych nawyków, których
nabrałem, ucząc się programowania poprzez takie języki
jak C czy C++"
Rzeczywiście, nie jest to super szczegółowo dopowiedziane,
ale jest tam wyraźnie powiedziane, że to JA nabrałem złych
nawyków, a nie że "C++ stworzył jakieś nawyki".
> > Nawyki nie są "cechą języka", tylko ludzi.
>
> Tak. Np. większosć ludzi ma złe nawyki żywieniowe.
> Ale to nie jest problem żywności.
Otyłość jest problemem w tzw. krajach rozwiniętych,
w których jest łatwy dostęp do słodyczy i śmieciowego
jedzenia. Jest to problem środowiskowy.
> > Języki mogą pomagać wykształcać w ludziach takie czy inne nawyki.
>
> Tak. Przykładowo, Ada jest lepsza od C++ pod względem wykształcania nawyków. Nie zmienia to faktu, że widziałem bardzo dobry kod w C++ i bardzo zły w Adzie.
W porządku. W każdym języku można pisać kiepski kod.
> > Więcej, wokół języków tworzą się kultury.
>
> Tak. A w przypadku jezyków bardzo rozbudowanych i popularnych również subkultury. Coś jak z żywieniem.
> Pytanie teraz, czy trzeba zmienić język, czy wystarczy znaleźć lepszą subkulturę, żeby podnieść poziom. Na to pytanie nie odpowiemy pisząc po prostu, że C++ wyrabia złe nawyki.
Zgoda.
> > Artykuł, który podlinkowałem, to nie jest "po prostu randomowy
> > kod który znalazłem gdzieś w necie": to jest kod, którym ktoś
> > się podzielił, żeby inni mogli go czytać.
>
> Czyli randomowy. Przecież w necie nie ma innych kodów, niż te, którymi ktoś się podzielił, żeby inni mogli je czytać. Podobnie jest z filmami na YouTube.
Są też kody, którymi ktoś się podzielił, bo tego wymagała od niego
licencja. Albo kody, którymi ktoś się "podzielił", bo nie zabezpieczył
repozytorium. Albo kody, którymi ktoś się podzielił, bo serwis hostujący
jego backupy tego wymaga.
> > I to jest kod pełen
> > anty-wzorców, których źródłem są właśnie złe nawyki.
>
> Dobrze. To może lepiej pokazać dobre wzorce na dobrym kodzie?
Te również podałem.
> > I, co znamienne, to jest kod,
> > który nie jest nietypowy dla programistów C++. Powiedziałbym
> > (na podstawie swoich doświadczeń), że jest bardzo typowy.
>
> Nadal nie wiem, czy trzeba zmienić język, żeby pisać lepiej.
Też nie wiem. Ale jeżeli idzie o mnie, to nie umiem pisać
w C++ kodu tak, żeby być z niego zadowolonym.
> > Mogę też spróbować sformułować tę myśl inaczej:
> > postaraj się odpowiedzieć na pytanie, dlaczego
> > taki "zły kod" powstaje.
>
> To jest bardzo cenne pytanie. Nie wiem, czy znam odpowiedź.
> Może dlatego, że ludzie uczą się z przypadkowego kodu znalezionego w necie?
> I akurat kodu w C++ jest na tyle dużo, że łatwo znaleźć ten kiepski?
> Coś jak z filmami na YT.
> Myślę, że pewnym czynnikiem jest też fakt, że nasz gatunek traci powoli zdolność czytania książek, zadowalając się przypadkowym "contentem z netu". To zjawisko akurat dotyczy nie tylko programowania.
>
> Nadal nie wiemy, czy należy zmienić język, żeby pisać dobrze.
> Albo, wracając do pierwszego pytania, czy C++ jest (nie)dobry do nauki.
Wydaje mi się, że pytanie "czy C++ jest dobry do nauki"
to trochę mało. Raczej należałoby zapytać, czy dane materiały
dydaktyczne są dobre, albo czy określona metodologia nauczania
jest skuteczna.
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-12-29 15:21 -0800 |
| Message-ID | <e82ee973-2df4-4cd0-a9df-46c638eaada9@googlegroups.com> |
| In reply to | #32171 |
> > [operator przypisania] > > > > > W większości miejsc nie jest konieczne. > > > A jest to zły nawyk, ponieważ - mówiąc skrótowo - zwiększa złożoność > > > środków analizy programów > > > > Nie, nie zwiększa. > > Owszem, zwiększa. To tak, jakbyś powiedział, że silnik zwiększa koszt samochodu. Otóż nie zwiększa, bo jest jego integralną częścią. Klima albo automat może zwiększać, ale nie silnik. Podobnie jest z operatorem przypisania w językach imperatywnych. On niczego nie zwiększa, bo nie może go nie być. > Proponuję, żebyś - zamiast zgadywać w ciemno o czym mówię > - spróbował przeczytać tę książkę, i dopiero wtedy się > wypowiedzieć. Czytałem. Tylko jakoś nie uległem czarowi języków funkcjonalnych do tego stopnia, żeby uznać je jako teoretyczną podstawę do czegokolwiek. I mam wrażenie (również z poprzednich naszych dyskusji), że tak właśnie sądzisz - że języki funkcjonalne są podstawą, z której można budować inne konstrukcje. Dlatego zastanawiasz się, jaki jest koszt dodania operatora przypisania. Tymczasem w informatyce, jeżeli w ogóle jest jakaś podstawa dla innych konstrukcji, to zwyczajowo była nią maszyna Turinga (i nie widzę powodu, żeby miała stracić ten status) a akurat tam jest już koncepcja modyfikacji wartości. Głowica zapisująca nową wartość w tym samym miejscu to właśnie operator przypisania. W tym kontekście zamiast pytać, jaki jest koszt dodania operatora przypisania do czegokolwiek, należałoby zapytać, jaki jest koszt udawania, że go może nie być. Otóż ten koszt to jest między innymi ta dyskusja. :-) > To dobra książka, naprawdę. https://cemerick.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program/ Wracając do tematu: jeżeli operator przypisania jest problemem w Scheme, to jest to problem w Scheme. W językch imperatywnych ten operator nie jest problemem, tylko integralną częścią języka. A narzędzi analitycznych to w ogóle nie komplikuje, naprawdę. > > Nadal nie wiem, czy trzeba zmienić język, żeby pisać lepiej. > > Też nie wiem. Ale jeżeli idzie o mnie, to nie umiem pisać > w C++ kodu tak, żeby być z niego zadowolonym. Mi się zdarzyło. Natomiast przyznam, że moje własne niezadowolenie z języka C++ skierowało mnie ku nauce Ady. I paradoksalnie, mój C++ się wtedy też poprawił. > Wydaje mi się, że pytanie "czy C++ jest dobry do nauki" > to trochę mało. Raczej należałoby zapytać, czy dane materiały > dydaktyczne są dobre, albo czy określona metodologia nauczania > jest skuteczna. Tak, to prawda. Ale znam ludzi, którzy twardo stosują C++ jako platformę do nauki programowania i struktur danych. Myślę, że przy odpowiednim prowadzeniu to nie jest zły pomysł. Ale sam osobiście poleciłbym nowicjuszom język Wolfram. Również dzieciom, jak im się już Scratch znudził. C++ nie jest dobrym pierwszym językiem, chociaż może być bardzo praktycznym językiem w późniejszej pracy czy innym realnym projekcie. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2018-12-30 04:06 -0800 |
| Message-ID | <6e9cd033-9896-4571-8ded-e67910151428@googlegroups.com> |
| In reply to | #32184 |
W dniu niedziela, 30 grudnia 2018 00:21:16 UTC+1 użytkownik Maciej Sobczak napisał:
> > > [operator przypisania]
> > >
> > > > W większości miejsc nie jest konieczne.
> > > > A jest to zły nawyk, ponieważ - mówiąc skrótowo - zwiększa złożoność
> > > > środków analizy programów
> > >
> > > Nie, nie zwiększa.
> >
> > Owszem, zwiększa.
>
> To tak, jakbyś powiedział, że silnik zwiększa koszt samochodu.
> Otóż nie zwiększa, bo jest jego integralną częścią. Klima albo automat może zwiększać, ale nie silnik.
> Podobnie jest z operatorem przypisania w językach imperatywnych. On niczego nie zwiększa, bo nie może go nie być.
Nie. Programy, które nie posiadają instrukcji przypisania,
można analizować, po prostu zastępując wyrażenia ich wartościami.
Programów, w których używa się instrukcji przypisania, nie
można analizować w taki sposób - trzeba zaprzęgać inne środki
analizy. Oczywiście można ostrożnie wprowadzać instrukcje
przypisania, otrzymując modele, które wciąż mają dobre właściwości.
I oczywiście obowiązkowy link do Quory ;]
https://www.quora.com/What-is-your-opinion-on-purely-functional-programming/answer/Panicz-Godek
> > Proponuję, żebyś - zamiast zgadywać w ciemno o czym mówię
> > - spróbował przeczytać tę książkę, i dopiero wtedy się
> > wypowiedzieć.
>
> Czytałem. Tylko jakoś nie uległem czarowi języków funkcjonalnych do tego stopnia, żeby uznać je jako teoretyczną podstawę do czegokolwiek.
> I mam wrażenie (również z poprzednich naszych dyskusji), że tak właśnie sądzisz - że języki funkcjonalne są podstawą, z której można budować inne konstrukcje. Dlatego zastanawiasz się, jaki jest koszt dodania operatora przypisania.
Tzn. ściśle rzecz biorąc cała informatyka teoretyczna bazuje na
"czystych funkcjach" - to jest budulec, z którego tworzy się
semantyki denotacyjne dla języków programowania.
> Tymczasem w informatyce, jeżeli w ogóle jest jakaś podstawa dla innych konstrukcji, to zwyczajowo była nią maszyna Turinga (i nie widzę powodu, żeby miała stracić ten status) a akurat tam jest już koncepcja modyfikacji wartości. Głowica zapisująca nową wartość w tym samym miejscu to właśnie operator przypisania.
Jeśli zapytamy, jaki model obliczeń jest współcześnie
najbardziej rozpowszechniony i najlepiej zrozumiany, to prawdopodobnie
tym modelem obliczeń będzie arkusz kalkulacyjny: jest bardzo duża
rzesza osób, które umieją korzystać z arkuszy kalkulacyjnych,
a które nawet nie wiedzą, że to jest programowanie.
Ten model obliczeń charakteryzuje się tym, że nie ma w nim
przepływu sterowania ani operacji przypisania. Jest dużo
prostszym modelem od maszyny von Neumanna, choć oczywiście
nie wszystko da się w nim zrealizować. (Ale można w nim robić
np. takie programy, jak sieci neuronowe. I wspiera obliczenia na
GPGPU)
Model podstawieniowy jest bardziej złożony od arkusza
kalkulacyjnego. Ale jest też bardziej uniwersalny w tym sensie,
że umożliwia tworzenie odrębnych komponentów i łączenie ich
ze sobą na różne sposoby.
Dobrym przykładem tego rodzaju kompozycjonalności są
potoki UNIXa. Co prawda programy, które łączy się w potoki,
takie jak sed czy grep, są napisane w sposób imperatywny,
ale same te programy nie polegają w żaden sposób na globalnym
stanie.
> W tym kontekście zamiast pytać, jaki jest koszt dodania operatora przypisania do czegokolwiek, należałoby zapytać, jaki jest koszt udawania, że go może nie być.
> Otóż ten koszt to jest między innymi ta dyskusja. :-)
Tutaj nie chodzi o to, że operatora przypisania ma nie być.
Chodzi o to, żeby nie używać go wtedy, kiedy to nie jest konieczne.
Programy, które nie polegają na globalnym stanie, analizuje
się łatwiej - i to przede wszystkim analizuje się je łatwiej
osobom, które muszą pracować z zastanym kodem, czyli
programistom. W językach takich jak C istnieją idiomy, które
pozwalają ograniczać zasięg instrukcji przypisania do
minimum (np. pętle for z iteratorem), ale one istnieją
właśnie dlatego, że modyfikacje globalnego stanu są
kłopotliwe.
> > To dobra książka, naprawdę.
>
> https://cemerick.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program/
Nie wiem co miałoby z tego linka wynikać dla tej dyskusji.
> Wracając do tematu: jeżeli operator przypisania jest problemem w Scheme, to jest to problem w Scheme. W językch imperatywnych ten operator nie jest problemem, tylko integralną częścią języka. A narzędzi analitycznych to w ogóle nie komplikuje, naprawdę.
Owo ustalenie, że stosowanie operatora przypisania (oraz operatów
wyrażających przepływ sterowania) komplikuje
środki analizy programu, dotyczy wszystkich języków, w których
procedury mogą przyjmować argumenty i zwracać wartości.
Dotyczy zatem takich języków, jak Java, C++, JavaScript,
Pascal, PHP, Perl, Python i wielu innych.
> > > Nadal nie wiem, czy trzeba zmienić język, żeby pisać lepiej.
> >
> > Też nie wiem. Ale jeżeli idzie o mnie, to nie umiem pisać
> > w C++ kodu tak, żeby być z niego zadowolonym.
>
> Mi się zdarzyło.
A to z chęcią bym zobaczył ;]
> Natomiast przyznam, że moje własne niezadowolenie z języka C++ skierowało mnie ku nauce Ady. I paradoksalnie, mój C++ się wtedy też poprawił.
Nie wiem co miałoby w tym być paradoksalnego - nauka nowych języków
programowania daje nam nowe perspektywy na to, czym ogólnie jest
programowanie. Akurat dla mnie ciekawie byłoby się dowiedzieć,
czego się można nauczyć od Ady, bo nie miałem z nią żadnej styczności.
W quorowym artykule, który wcześniej podlinkowywałem ("what are some
examples of bad code"), dlatego nie zawarłem dobrej implementacji
w C++, że naprawdę nie wiedziałbym, jak się za to zabrać.
Mógłbym napisać "Haskella w C++", ale nie wiem, czy to by było
zgodne z "duchem C++" (jeżeli ten język w ogóle ma jakiegoś ducha)
> > Wydaje mi się, że pytanie "czy C++ jest dobry do nauki"
> > to trochę mało. Raczej należałoby zapytać, czy dane materiały
> > dydaktyczne są dobre, albo czy określona metodologia nauczania
> > jest skuteczna.
>
> Tak, to prawda. Ale znam ludzi, którzy twardo stosują C++ jako platformę do nauki programowania i struktur danych. Myślę, że przy odpowiednim prowadzeniu to nie jest zły pomysł.
> Ale sam osobiście poleciłbym nowicjuszom język Wolfram. Również dzieciom, jak im się już Scratch znudził. C++ nie jest dobrym pierwszym językiem, chociaż może być bardzo praktycznym językiem w późniejszej pracy czy innym realnym projekcie.
Jak dla mnie Wolfram pewnie byłby OK, gdyby był open-source'owy.
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-01-02 01:17 -0800 |
| Message-ID | <12e671b0-ee5d-46ab-b8c1-a1651292e040@googlegroups.com> |
| In reply to | #32185 |
> Nie. Programy, które nie posiadają instrukcji przypisania, > można analizować, po prostu zastępując wyrażenia ich wartościami. > Programów, w których używa się instrukcji przypisania, nie > można analizować w taki sposób Dlaczego? Pytam, bo analizuję i może coś źle robię. > - trzeba zaprzęgać inne środki > analizy. Jakie? Czy te inne środki analizy są gorsze - w sensie, że dają gorsze efekty? > Tzn. ściśle rzecz biorąc cała informatyka teoretyczna bazuje na > "czystych funkcjach" To ja chyba czytałem inną książkę. > > Tymczasem w informatyce, jeżeli w ogóle jest jakaś podstawa dla innych konstrukcji, to zwyczajowo była nią maszyna Turinga > Jeśli zapytamy, jaki model obliczeń jest współcześnie > najbardziej rozpowszechniony Zdecydowanie nie jest nim programowanie funkcjonalne. > i najlepiej zrozumiany, to prawdopodobnie > tym modelem obliczeń będzie arkusz kalkulacyjny: jest bardzo duża > rzesza osób, które umieją korzystać z arkuszy kalkulacyjnych, > a które nawet nie wiedzą, że to jest programowanie. > Ten model obliczeń charakteryzuje się tym, że nie ma w nim > przepływu sterowania ani operacji przypisania. Brniesz. https://www.google.com/search?q=Excel+assign+value+to+cell > Tutaj nie chodzi o to, że operatora przypisania ma nie być. > Chodzi o to, żeby nie używać go wtedy, kiedy to nie jest konieczne. I po długiej dyskusji, w której gdzieś tam wcześniej wspomniałeś o złych nawykach z C++, nadal nie wiem, gdzie w C++ nie jest to konieczne. > Programy, które nie polegają na globalnym stanie, analizuje > się łatwiej Jesteś pierwszy, który wspomniał o globalnym stanie. Po co? > > https://cemerick.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program/ > > Nie wiem co miałoby z tego linka wynikać dla tej dyskusji. A taki tam przypominacz, że nawet u źródeł SICP traci autorytet. > Owo ustalenie, że stosowanie operatora przypisania (oraz operatów > wyrażających przepływ sterowania) komplikuje > środki analizy programu, W jaki sposób komplikuje? > > > Też nie wiem. Ale jeżeli idzie o mnie, to nie umiem pisać > > > w C++ kodu tak, żeby być z niego zadowolonym. > > > > Mi się zdarzyło. > > A to z chęcią bym zobaczył ;] Link w sygnaturze. > Akurat dla mnie ciekawie byłoby się dowiedzieć, > czego się można nauczyć od Ady, bo nie miałem z nią żadnej styczności. Kultury tworzenia fizycznej struktury kodu, nacisku na projekt używanych typów danych, paru fajnych idiomów w okolicy programowania wielowątkowego oraz ciekawej obserwacji, jak dużo można zrobić bez używania jawnie oraz niejawnie (!) pamięci dynamicznej (np. prawie wszystkie wzorce projektowe GoF). Jeżeli masz zacięcie teoretyczne, warto wiedzieć, że na podzbiorze Ady wysósł SPARK, czyli język zintegrowany z metodą formalną do weryfikacji jego poprawności. Last but not least, bardzo sensowny podzbiór Ady (w tym cały potrzebny dla SPARKa) ma profil tzw. Zero FootPrint Run-Time, czyli nie wymaga wsparcia żadnej dodatkowej warstwy kodu. Wszystkie powyższe pozwoliły mi inaczej spojrzeć na prace robione w innych językach (w szczególności w C++). Interesują mnie systemy wbudowane (w tym krytyczne) i powyższe cechy, zwłaszcza ZFP, są dla mnie wyjątkowo cenne. Polecam. > Jak dla mnie Wolfram pewnie byłby OK, gdyby był open-source'owy. Dlaczego? -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-02 04:42 -0800 |
| Message-ID | <2bb8d0ea-1fd1-4900-a48c-943d728b8a9d@googlegroups.com> |
| In reply to | #32208 |
W dniu środa, 2 stycznia 2019 10:17:08 UTC+1 użytkownik Maciej Sobczak napisał:
> > Nie. Programy, które nie posiadają instrukcji przypisania,
> > można analizować, po prostu zastępując wyrażenia ich wartościami.
> > Programów, w których używa się instrukcji przypisania, nie
> > można analizować w taki sposób
>
> Dlaczego?
> Pytam, bo analizuję i może coś źle robię.
No to weźmy taki przykład:
int f(void) {
static n = 0;
return ++n;
}
Jaką wartość ma wyrażenie f()?
> > - trzeba zaprzęgać inne środki
> > analizy.
>
> Jakie?
Inne. Różne. Zależy od uwarunkowań problemu.
> Czy te inne środki analizy są gorsze - w sensie, że dają gorsze efekty?
Myślę, że jedyną odpowiedzią, jakiej mogę udzielić, jest
"to zależy".
> > Tzn. ściśle rzecz biorąc cała informatyka teoretyczna bazuje na
> > "czystych funkcjach"
>
> To ja chyba czytałem inną książkę.
Bardzo możliwe. Istnieje na świecie wiele książek.
> > > Tymczasem w informatyce, jeżeli w ogóle jest jakaś podstawa dla innych konstrukcji, to zwyczajowo była nią maszyna Turinga
>
> > Jeśli zapytamy, jaki model obliczeń jest współcześnie
> > najbardziej rozpowszechniony
>
> Zdecydowanie nie jest nim programowanie funkcjonalne.
>
> > i najlepiej zrozumiany, to prawdopodobnie
> > tym modelem obliczeń będzie arkusz kalkulacyjny: jest bardzo duża
> > rzesza osób, które umieją korzystać z arkuszy kalkulacyjnych,
> > a które nawet nie wiedzą, że to jest programowanie.
> > Ten model obliczeń charakteryzuje się tym, że nie ma w nim
> > przepływu sterowania ani operacji przypisania.
>
> Brniesz.
>
> https://www.google.com/search?q=Excel+assign+value+to+cell
Widzę, że próbujesz zabłysnąć ekwiwokacją.
> > Tutaj nie chodzi o to, że operatora przypisania ma nie być.
> > Chodzi o to, żeby nie używać go wtedy, kiedy to nie jest konieczne.
>
> I po długiej dyskusji, w której gdzieś tam wcześniej wspomniałeś o złych nawykach z C++, nadal nie wiem, gdzie w C++ nie jest to konieczne.
Cóż, w takim razie chyba bardziej nie pomogę.
> > Programy, które nie polegają na globalnym stanie, analizuje
> > się łatwiej
>
> Jesteś pierwszy, który wspomniał o globalnym stanie. Po co?
Ponieważ to jeden ze złych nawyków.
> > > https://cemerick.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program/
> >
> > Nie wiem co miałoby z tego linka wynikać dla tej dyskusji.
>
> A taki tam przypominacz, że nawet u źródeł SICP traci autorytet.
"while I had Prof. Sussman’s ear, I asked him whether he thought that the shift in the nature of a typical programmer’s world minimizes the relevancy of the themes and principles embodied in scheme. His response was an emphatic ‘no’; in the general case, those core ideas and principles that scheme and SICP have helped to spread for so many years are just as important as they ever were. "
> > Owo ustalenie, że stosowanie operatora przypisania (oraz operatów
> > wyrażających przepływ sterowania) komplikuje
> > środki analizy programu,
>
> W jaki sposób komplikuje?
Po raz dziesiąty pytasz o to samo.
W taki sposób, że proste środki analizy programu (podstawianie
wartości za wyrażenia) przestają być wystarczające, i potrzebne
są bardziej skomplikowane środki.
> > Jak dla mnie Wolfram pewnie byłby OK, gdyby był open-source'owy.
>
> Dlaczego?
Bo lubię móc poznawać w jaki sposób są zrobione różne rzeczy.
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2019-01-03 00:57 -0800 |
| Message-ID | <55b459d2-1af9-459c-9064-25100303eaaf@googlegroups.com> |
| In reply to | #32214 |
> No to weźmy taki przykład:
>
> int f(void) {
> static n = 0;
> return ++n;
> }
>
> Jaką wartość ma wyrażenie f()?
A jaką miał poprzednio?
I dlaczego użyłeś słowa static?
Czy musisz sięgać aż po tak bardzo niszowe przykłady, żeby wykazać, że C++ jest zły? Czy to znaczy, że w programie C++, w którym nie ma słowa static, opisywane przez Ciebie problemy nie występują? Czy to znaczy, że taki program jest równie dobry, jak program, w którym przypisań nie ma?
> > Czy te inne środki analizy są gorsze - w sensie, że dają gorsze efekty?
>
> Myślę, że jedyną odpowiedzią, jakiej mogę udzielić, jest
> "to zależy".
W takim razie jest to też odpowiedź na pytanie, czy C++ jest zły albo gorszy od czegoś tam, albo czy kreuje złe nawyki. I w sumie do tego zmierzałem.
Przyjmijmy więc, że C++ jest dobry tam, gdzie kryterium "to zależy" wypada na jego korzyść. To chyba dobry wniosek?
> > I po długiej dyskusji, w której gdzieś tam wcześniej wspomniałeś o złych nawykach z C++, nadal nie wiem, gdzie w C++ nie jest to konieczne.
>
> Cóż, w takim razie chyba bardziej nie pomogę.
Dla mnie OK.
> > > Jak dla mnie Wolfram pewnie byłby OK, gdyby był open-source'owy.
> >
> > Dlaczego?
>
> Bo lubię móc poznawać w jaki sposób są zrobione różne rzeczy.
Poznawanie jak coś jest zrobione jest wciągające, ale nie wymagam tego od każdego narzędzia, którego używam. Ze względu na naturę projektów wbudowanych lubię wiedzieć, jak działa C++ (albo Ada, SPARK, itp.). Ale są też inne projekty, gdzie mogę pozwolić sobie na niewiedzę i zastąpić ją zaufaniem. Wtedy używam Wolframa. Polecam - zwłaszcza, że jest mocno Lispowaty w swoich fundamentach i sądząc po tym co piszesz na tej grupie, jest szansa, że by Ci się bardzo spodobał.
--
Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-03 05:34 -0800 |
| Message-ID | <97514df3-8702-402f-8e61-5d0c5b154802@googlegroups.com> |
| In reply to | #32225 |
W dniu czwartek, 3 stycznia 2019 09:57:06 UTC+1 użytkownik Maciej Sobczak napisał:
> > No to weźmy taki przykład:
> >
> > int f(void) {
> > static n = 0;
> > return ++n;
> > }
> >
> > Jaką wartość ma wyrażenie f()?
>
> A jaką miał poprzednio?
Bardzo dobre pytanie. Nie będziemy na nie na razie odpowiadać,
ale zapamiętajmy je sobie.
A teraz inny przykład:
int g(int x) {
return x + 2;
}
Jaką wartość ma wyrażenie g(5)?
Na to pytanie odpowiesz bez problemu.
Nie będziesz musiał zadawać dodatkowego pytania
w rodzaju "jaka była poprzednia wartość tego wyrażenia?".
I to właśnie brak tego rodzaju pytań sprawia, że
ten model jest prostszy.
> I dlaczego użyłeś słowa static?
Dla przykładu.
> Czy musisz sięgać aż po tak bardzo niszowe przykłady, żeby wykazać, że C++ jest zły?
Mój przykład nie miał na celu wykazania "że C++ jest zły"
(cokolwiek by ono miało oznaczać).
Używanie statycznych zmiennych w obrębie funkcji nie jest
niszowe. W niektórych sytuacjach jest użyteczne.
> Czy to znaczy, że w programie C++, w którym nie ma słowa static, opisywane przez Ciebie problemy nie występują?
Nie. To, o czym mówię, nie ma związku z użyciem słowa "static".
> Czy to znaczy, że taki program jest równie dobry, jak program, w którym przypisań nie ma?
Nie rozumiem pytania. Nie wiem, co miałoby znaczyć, że "taki program
jest równie dobry jak jakiś inny program".
Programy są o tyle dobre, o ile służą do celów, do których mają służyć.
> > > Czy te inne środki analizy są gorsze - w sensie, że dają gorsze efekty?
> >
> > Myślę, że jedyną odpowiedzią, jakiej mogę udzielić, jest
> > "to zależy".
>
> W takim razie jest to też odpowiedź na pytanie, czy C++ jest zły albo gorszy od czegoś tam, albo czy kreuje złe nawyki. I w sumie do tego zmierzałem.
Jedyną osobą, która w tym wątku użyła określeń "C++ jest zły"
czy "C++ kreuje złe nawyki" jesteś Ty.
> Przyjmijmy więc, że C++ jest dobry tam, gdzie kryterium "to zależy" wypada na jego korzyść. To chyba dobry wniosek?
To samo można powiedzieć o wszystkim zawsze.
Toteż nie jest to szczególnie wartościowy poznawczo wniosek.
> > > > Jak dla mnie Wolfram pewnie byłby OK, gdyby był open-source'owy.
> > >
> > > Dlaczego?
> >
> > Bo lubię móc poznawać w jaki sposób są zrobione różne rzeczy.
>
> Poznawanie jak coś jest zrobione jest wciągające, ale nie wymagam tego od każdego narzędzia, którego używam. Ze względu na naturę projektów wbudowanych lubię wiedzieć, jak działa C++ (albo Ada, SPARK, itp.). Ale są też inne projekty, gdzie mogę pozwolić sobie na niewiedzę i zastąpić ją zaufaniem. Wtedy używam Wolframa. Polecam - zwłaszcza, że jest mocno Lispowaty w swoich fundamentach i sądząc po tym co piszesz na tej grupie, jest szansa, że by Ci się bardzo spodobał.
Swego czasu nawet wyjechałem z taką propozycją na Quorze:
https://quora-feature-requests-notepad.quora.com/Mathematica-style-notebook
ale niestety pomysł nie został podchwycony.
[toc] | [prev] | [next] | [standalone]
| From | Roman Tyczka <noemail@because.no> |
|---|---|
| Date | 2019-01-03 17:15 +0100 |
| Message-ID | <2mm540k22rer.dlg@tyczka.com> |
| In reply to | #32229 |
On Thu, 3 Jan 2019 05:34:40 -0800 (PST), godek.maciek@gmail.com wrote: >>> > Czy te inne środki analizy są gorsze - w sensie, że dają gorsze efekty? >>> >>> Myślę, że jedyną odpowiedzią, jakiej mogę udzielić, jest >>> "to zależy". >> >> W takim razie jest to też odpowiedź na pytanie, czy C++ jest zły albo gorszy od czegoś tam, albo czy kreuje złe nawyki. I w sumie do tego zmierzałem. > > Jedyną osobą, która w tym wątku użyła określeń "C++ jest zły" > czy "C++ kreuje złe nawyki" jesteś Ty. Zgadnij kto to napisał: "ja sam musiałem oduczać się różnych złych nawyków, których nabrałem, ucząc się programowania poprzez takie języki jak C czy C++" -- pozdrawiam Roman Tyczka
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-03 08:30 -0800 |
| Message-ID | <e8828dd3-86a5-4eb1-9747-f16db6ef659d@googlegroups.com> |
| In reply to | #32231 |
W dniu czwartek, 3 stycznia 2019 17:15:08 UTC+1 użytkownik Roman Tyczka napisał: > > Jedyną osobą, która w tym wątku użyła określeń "C++ jest zły" > > czy "C++ kreuje złe nawyki" jesteś Ty. > > Zgadnij kto to napisał: > > "ja sam musiałem oduczać się różnych złych nawyków, których > nabrałem, ucząc się programowania poprzez takie języki > jak C czy C++" Nie muszę zgadywać, bo to ja to pisałem. I nie jest tam napisane ani "C++ jest zły", ani "C++ kreuje złe nawyki". Jest tam napisane, że ja uczyłem się programowania w oparciu o (m.in.) C i C++ i nabrałem wtedy wielu złych nawyków. Zagadnienie było zresztą dokładniej roztrząśnięte w dalszej części tego wątku. I podkreśliłem tam, że nie napisałem, że "C++ stworzył jakieś nawyki". Czego jeszcze nie rozumiesz?
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-01-03 17:44 +0100 |
| Message-ID | <q0le5s$foe$1@gioia.aioe.org> |
| In reply to | #32233 |
On 2019-01-03 17:30, godek.maciek@gmail.com wrote: >> Zgadnij kto to napisał: >> >> "ja sam musiałem oduczać się różnych złych nawyków, których >> nabrałem, ucząc się programowania poprzez takie języki >> jak C czy C++" > > Nie muszę zgadywać, bo to ja to pisałem. ...i bardzo slusznie napisales:) To swieta prawda/rzeczywistosc. > I nie jest tam napisane ani "C++ jest zły", > ani "C++ kreuje złe nawyki". Jesli kreuje zle nawyki to po prostu jest zly! :). AK
[toc] | [prev] | [next] | [standalone]
| From | Roman Tyczka <noemail@because.no> |
|---|---|
| Date | 2019-01-04 17:48 +0100 |
| Message-ID | <po4u774toq7b.dlg@tyczka.com> |
| In reply to | #32233 |
On Thu, 3 Jan 2019 08:30:55 -0800 (PST), godek.maciek@gmail.com wrote: >>> Jedyną osobą, która w tym wątku użyła określeń "C++ jest zły" >>> czy "C++ kreuje złe nawyki" jesteś Ty. >> >> Zgadnij kto to napisał: >> >> "ja sam musiałem oduczać się różnych złych nawyków, których >> nabrałem, ucząc się programowania poprzez takie języki >> jak C czy C++" > > Nie muszę zgadywać, bo to ja to pisałem. > I nie jest tam napisane ani "C++ jest zły", > ani "C++ kreuje złe nawyki". > > Jest tam napisane, że ja uczyłem się programowania w oparciu > o (m.in.) C i C++ i nabrałem wtedy wielu złych nawyków. > > Zagadnienie było zresztą dokładniej roztrząśnięte w dalszej > części tego wątku. I podkreśliłem tam, że nie napisałem, > że "C++ stworzył jakieś nawyki". > > Czego jeszcze nie rozumiesz? Ja wszystko rozumiem. Pytanie czego Ty nie rozumiesz w tym co sam napisałeś? No, ale jak się człek zapędzi w kozi róg to potem nagnie każdą rzeczywistość i udowodni, że białe jest czarne. -- pozdrawiam Roman Tyczka
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-04 09:44 -0800 |
| Message-ID | <2b5514f4-e171-4d39-8ae1-d874b8af71a5@googlegroups.com> |
| In reply to | #32267 |
W dniu piątek, 4 stycznia 2019 17:48:21 UTC+1 użytkownik Roman Tyczka napisał: > >>> Jedyną osobą, która w tym wątku użyła określeń "C++ jest zły" > >>> czy "C++ kreuje złe nawyki" jesteś Ty. > >> > >> Zgadnij kto to napisał: > >> > >> "ja sam musiałem oduczać się różnych złych nawyków, których > >> nabrałem, ucząc się programowania poprzez takie języki > >> jak C czy C++" > > > > Nie muszę zgadywać, bo to ja to pisałem. > > I nie jest tam napisane ani "C++ jest zły", > > ani "C++ kreuje złe nawyki". > > > > Jest tam napisane, że ja uczyłem się programowania w oparciu > > o (m.in.) C i C++ i nabrałem wtedy wielu złych nawyków. > > > > Zagadnienie było zresztą dokładniej roztrząśnięte w dalszej > > części tego wątku. I podkreśliłem tam, że nie napisałem, > > że "C++ stworzył jakieś nawyki". > > > > Czego jeszcze nie rozumiesz? > > Ja wszystko rozumiem. Pytanie czego Ty nie rozumiesz w tym co sam > napisałeś? No, ale jak się człek zapędzi w kozi róg to potem nagnie każdą > rzeczywistość i udowodni, że białe jest czarne. Mhm. I rozumiem, że gdybym powiedział, że jak byłem na wsi, to się przeziębiłem, uznałbyś, że stwierdziłem, że wieś powoduje przeziębienie?
[toc] | [prev] | [next] | [standalone]
| From | Roman Tyczka <noemail@because.no> |
|---|---|
| Date | 2019-01-04 22:14 +0100 |
| Message-ID | <pj9f7wz80xib.dlg@tyczka.com> |
| In reply to | #32268 |
On Fri, 4 Jan 2019 09:44:30 -0800 (PST), godek.maciek@gmail.com wrote: >>>>> Jedyną osobą, która w tym wątku użyła określeń "C++ jest zły" >>>>> czy "C++ kreuje złe nawyki" jesteś Ty. >>>> >>>> Zgadnij kto to napisał: >>>> >>>> "ja sam musiałem oduczać się różnych złych nawyków, których >>>> nabrałem, ucząc się programowania poprzez takie języki >>>> jak C czy C++" >>> >>> Nie muszę zgadywać, bo to ja to pisałem. >>> I nie jest tam napisane ani "C++ jest zły", >>> ani "C++ kreuje złe nawyki". >>> >>> Jest tam napisane, że ja uczyłem się programowania w oparciu >>> o (m.in.) C i C++ i nabrałem wtedy wielu złych nawyków. >>> >>> Zagadnienie było zresztą dokładniej roztrząśnięte w dalszej >>> części tego wątku. I podkreśliłem tam, że nie napisałem, >>> że "C++ stworzył jakieś nawyki". >>> >>> Czego jeszcze nie rozumiesz? >> >> Ja wszystko rozumiem. Pytanie czego Ty nie rozumiesz w tym co sam >> napisałeś? No, ale jak się człek zapędzi w kozi róg to potem nagnie każdą >> rzeczywistość i udowodni, że białe jest czarne. > > Mhm. I rozumiem, że gdybym powiedział, że jak byłem na wsi, to się > przeziębiłem, uznałbyś, że stwierdziłem, że wieś powoduje przeziębienie? Gdybyś jednocześnie twierdził, że pobyt w mieście nie powoduje przeziębień to tak, tak właśnie bym uznał. Drobna acz kluczowa różnica. -- pozdrawiam Roman Tyczka
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-04 13:25 -0800 |
| Message-ID | <c829fb80-3d69-4851-aedb-64bd9bd677e2@googlegroups.com> |
| In reply to | #32269 |
W dniu piątek, 4 stycznia 2019 22:14:55 UTC+1 użytkownik Roman Tyczka napisał: > >>>>> Jedyną osobą, która w tym wątku użyła określeń "C++ jest zły" > >>>>> czy "C++ kreuje złe nawyki" jesteś Ty. > >>>> > >>>> Zgadnij kto to napisał: > >>>> > >>>> "ja sam musiałem oduczać się różnych złych nawyków, których > >>>> nabrałem, ucząc się programowania poprzez takie języki > >>>> jak C czy C++" > >>> > >>> Nie muszę zgadywać, bo to ja to pisałem. > >>> I nie jest tam napisane ani "C++ jest zły", > >>> ani "C++ kreuje złe nawyki". > >>> > >>> Jest tam napisane, że ja uczyłem się programowania w oparciu > >>> o (m.in.) C i C++ i nabrałem wtedy wielu złych nawyków. > >>> > >>> Zagadnienie było zresztą dokładniej roztrząśnięte w dalszej > >>> części tego wątku. I podkreśliłem tam, że nie napisałem, > >>> że "C++ stworzył jakieś nawyki". > >>> > >>> Czego jeszcze nie rozumiesz? > >> > >> Ja wszystko rozumiem. Pytanie czego Ty nie rozumiesz w tym co sam > >> napisałeś? No, ale jak się człek zapędzi w kozi róg to potem nagnie każdą > >> rzeczywistość i udowodni, że białe jest czarne. > > > > Mhm. I rozumiem, że gdybym powiedział, że jak byłem na wsi, to się > > przeziębiłem, uznałbyś, że stwierdziłem, że wieś powoduje przeziębienie? > > Gdybyś jednocześnie twierdził, że pobyt w mieście nie powoduje przeziębień > to tak, tak właśnie bym uznał. > Drobna acz kluczowa różnica. A w którym miejscu stwierdziłem, że "pobyt w mieście nie powoduje przeziębień"? Rozumiem, że w tej przenośni chodziłoby o to, że twierdzę, że stosując języki inne, niż C czy C++, nie można wyrobić złych nawyków? Jeśli tak, to w którym miejscu? A jeśli nie, to czy mógłbyś tę myśl rozwinąć?
[toc] | [prev] | [next] | [standalone]
| From | AK <nobody@nowhere.net> |
|---|---|
| Date | 2019-01-03 17:24 +0100 |
| Message-ID | <q0lcv9$abq$1@gioia.aioe.org> |
| In reply to | #32229 |
On 2019-01-03 14:34, godek.maciek@gmail.com wrote: > W dniu czwartek, 3 stycznia 2019 09:57:06 UTC+1 użytkownik Maciej Sobczak napisał: >> W takim razie jest to też odpowiedź na pytanie, czy C++ jest zły albo gorszy od >> czegoś tam, albo czy kreuje złe nawyki. I w sumie do tego zmierzałem. > > Jedyną osobą, która w tym wątku użyła określeń "C++ jest zły" > czy "C++ kreuje złe nawyki" jesteś Ty. No to bede drugi. C++ jest zly. Tak: jest zwyczajnie zly, bo nie tylko kreuje zle nawyki (a kreuje i to bardzo), ale tez dlatego, ze nawet w "doswiadczonych rekach" jest zwyczajnie nieprzewidywalny. Nie pomoga tu zadne MISRY, ani chor Ayatolahow. Po prostu taka jest rzeczywistosc, bo... (jak wszystko) istnieja jezyki prog. _obiektywnie_ lepsze i gorsze. Do tych zlych naleza na pewno: C++, Perl, Tcl, stary Fortran (IV a nawet 77), takze stary Cobol itd itd. PS: Na poczatku dyskusji wymieniles IMHO najwazniejsze kryterium "zlosci" C++. Po tym dalsza dyskusje mozna by spokojnie zamknac :) Aatollahow i tak NIC nie przekona. Ani Twoja nieszablonowosc/otwartosc (szacunek:), ani moje doswiadczenie (w C++ rowno 32 lata). Ciebie zhetuja, ze nie masz doswiadczenia, a mnie ze... mam za duze :) i skostnialem/nie umiem calosci C++... i nie przekona ich to ze wlasnie pisze/rozwijam parser C++14, aby moc... automatem przekonwertowywac programy z chorego dzis C++ na cos innego/lepszego (glownie C#). Zeby nie bylo: doceniam zmiany wprowadzone przez C++11/14/17 tyl ze ja myslalem ze nastapia po ~5 latach, a nastapily po ponad 30stu.W dodatku wymuszone przez dawno istniejace/okrzeple "ficzery" w innych jezykach (dalej jednak nie wprowadzono do standardu properties, ani finally - i nie pomoze tu zadne RAI bo.. nawet standardowe std tegoz RA nie wspiera/wymusza. PS0: Nie twierdze ze Lisp-owatosc jest super. O nie! Wada tego jezyka jest po pierwsze nieczytelna/trudna do ogarniecia skladnia. Druga wada (ktora Ty uwazasz za zalete) jest dogmat funcyjnosci i "bezstanowosci". Swiat jednak jest obiektowy a obiety stany posiadaja (nie zawsze sa wyliczane/wyliczalne). Oczywiscie rozumiem znaczenie czystej funcyjnosci Lispa - przeciez to jego glowna/immanentna cecha -, ale w obszarze/niszy jaka jest inzynieria programowania. W normalnym swiecie rzemieslniczego programowania jest to jednak za malo. Czlek mysli/swiat jest zbudowany bardziej obiektowo/stanowo, a nie funcyjnie zawsze bedzie "ciagnal" do czegos co to myslenie dobrze odzwiercedla, niz "przestawi sie" na myslenie o wszytskim jako wyniku chain-a funkcji. CZyli: doceniam elegancje Lispa, ale niestety nie nie moge docenic praktycznosci Lispa w zwyklym zyciu programistycznym. Czlek nie mysli odwrotną notacją polską AK
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-03 09:20 -0800 |
| Message-ID | <11837655-52b0-4e12-9a01-866e6c1ef1ce@googlegroups.com> |
| In reply to | #32232 |
W dniu czwartek, 3 stycznia 2019 17:24:12 UTC+1 użytkownik AK napisał: > >> W takim razie jest to też odpowiedź na pytanie, czy C++ jest zły albo gorszy od > >> czegoś tam, albo czy kreuje złe nawyki. I w sumie do tego zmierzałem. > > > > Jedyną osobą, która w tym wątku użyła określeń "C++ jest zły" > > czy "C++ kreuje złe nawyki" jesteś Ty. > > No to bede drugi. > C++ jest zly. > Tak: jest zwyczajnie zly, bo nie tylko kreuje zle nawyki > (a kreuje i to bardzo), ale tez dlatego, ze nawet w "doswiadczonych > rekach" jest zwyczajnie nieprzewidywalny. Ja się z Tobą zgadzam. Ale stwierdzenie, że "C++ jest zły", jest nieprecyzyjne. Zły do czego? Moim zdaniem C++ jest np. doskonały jako przykład tego, w jaki sposób nie należy projektować języków programowania. Również w kwestii kreowania nawyków, owo stwierdzenie jest skrótem myślowym. Wiele materiałów dydaktycznych napisanych wokół C++ bardzo moim zdaniem pomaga w kreowaniu złych nawyków. Ale wyobrażam sobie, że być może można by było stworzyć materiały dydaktyczne, które korzystałyby z C++ (czy jakiegoś podzbioru C++), a które nie propagowałyby tych złych nawyków. Nie znam takich materiałów, ale to nie znaczy, że takie nie mogą istnieć. (Może "Effective C++" jest czymś takim? Nie wiem, nie czytałem. Na pewno materiały Stroustrupa, z którymi miałem styczność, nie były dobre) > Nie pomoga tu zadne MISRY, ani chor Ayatolahow. > Po prostu taka jest rzeczywistosc, bo... (jak wszystko) istnieja > jezyki prog. _obiektywnie_ lepsze i gorsze. > Do tych zlych naleza na pewno: C++, Perl, Tcl, stary Fortran (IV > a nawet 77), takze stary Cobol itd itd. Jeżeli idzie o Perla, to w niektórych zastosowaniach jest wygodnym narzędziem, ale istotnie nie jest dobrym językiem do pisania dużych programów. > PS: Na poczatku dyskusji wymieniles IMHO najwazniejsze kryterium > "zlosci" C++. Po tym dalsza dyskusje mozna by spokojnie zamknac :) > Aatollahow i tak NIC nie przekona. > Ani Twoja nieszablonowosc/otwartosc (szacunek:), ani moje doswiadczenie > (w C++ rowno 32 lata). Ciebie zhetuja, ze nie masz doswiadczenia, a > mnie ze... mam za duze :) i skostnialem/nie umiem calosci C++... > i nie przekona ich to ze wlasnie pisze/rozwijam parser C++14, aby moc... > automatem przekonwertowywac programy z chorego dzis C++ na cos > innego/lepszego (glownie C#). Kolega, z którym pracowałem przez ostatni rok, rozwijał kiedyś język programowania Ć, dający się transformować do różnych innych platform (C, C#, Java, Perl, JavaScript, ActionScript i D): http://cito.sourceforge.net/ > Zeby nie bylo: doceniam zmiany wprowadzone przez C++11/14/17 > tyl ze ja myslalem ze nastapia po ~5 latach, a nastapily po ponad > 30stu.W dodatku wymuszone przez dawno istniejace/okrzeple "ficzery" > w innych jezykach (dalej jednak nie wprowadzono do standardu properties, > ani finally - i nie pomoze tu zadne RAI bo.. nawet standardowe std > tegoz RA nie wspiera/wymusza. > > PS0: Nie twierdze ze Lisp-owatosc jest super. O nie! Wada tego jezyka > jest po pierwsze nieczytelna/trudna do ogarniecia skladnia. Myślę, że Lisp jest tak samo nieczytelny dla osób nieprogramujących w Lispie, jak chiński dla osób nieposługujących się chińskim. Pewnie przed typografią programów komputerowych jest jeszcze długa droga, i pewnie dużo dałoby się zrobić, żeby Lisp był czytelniejszy. Ale składnia Lispa jest bardzo łatwa do opanowania. Piszesz: (operator argumenty ...) i to wszystko. > Druga wada (ktora Ty uwazasz za zalete) jest dogmat funcyjnosci i > "bezstanowosci". To nie jest dogmat. To jest podejście promowania promowane może w Schemie i Clojure. Programiści Common Lispa raczej go nie uznają. > Swiat jednak jest obiektowy a obiety stany posiadaja > (nie zawsze sa wyliczane/wyliczalne). Oczywiscie rozumiem znaczenie > czystej funcyjnosci Lispa - przeciez to jego glowna/immanentna cecha -, > ale w obszarze/niszy jaka jest inzynieria programowania. > W normalnym swiecie rzemieslniczego programowania jest to jednak > za malo. Czlek mysli/swiat jest zbudowany bardziej obiektowo/stanowo, > a nie funcyjnie zawsze bedzie "ciagnal" do czegos co to myslenie dobrze > odzwiercedla, niz "przestawi sie" na myslenie o wszytskim jako wyniku > chain-a funkcji. Nie zgadzam się. Człowiek jest przyzwyczajony do tego, że myślenie nie ma w świecie żadnych skutków ubocznych (poza upływającym czasem). Jest przyzwyczajony do rozróżniania myślenia i działania. Przynajmniej od czasów Kartezjusza jest przyzwyczajony do rozróżniania myślenia i działania. Zgadzam się, że programowanie funkcyjne nie jest uniwersalne w tym sensie, że nie wszystko da się w nim zrobić. Ale warto go używać wszędzie tam, gdzie się nadaje (czyli np. w data science, narzędziach do przetwarzania języków programowania czy algorytmach kombinatorycznych, ale już nie w programowaniu systemowym czy do tworzenia interfejsów graficznych), bo to pozwala uniknąć wielu niepotrzebnych pułapek. Przykład, który lubię dawać na różnych prezentacjach, to program liczący sumę kwadratów początkowych siedmiu liczb pierwszych. Imperatywnie zapisalibyśmy go tak: 1: licznik := 7 2: liczba := 0 3: suma := 0 4: dopóki (licznik > 0): 5: jeżeli jest_pierwsza(liczba): 6: suma := suma + liczba^2 7: licznik := licznik - 1 8: liczba := liczba + 1 i jeszcze musieli dopowiedzieć, że po wykonaniu programu wynik znajdziemy w zmiennej "suma". Natomiast przy podejściu funkcyjnym po prostu "formalizujemy" sformułowaine problemu: "suma kwadratów początkowych 7 liczb pierwszych" ma swoją strukturę gramatyczną, którą możemy uwypuklić, biorąc jednostki znaczeniowe w nawiasy: (suma (kwadraty (początkowe 7 liczby-pierwsze))) Teraz wystarczy nam wyjaśnić, co to jest (suma elementów) czym są (kwadraty elementów), co to jest (początkowe N elementy) i czym są liczby-pierwsze. To jest kod, który bardzo łatwo się komponuje, i który bardzo łatwo się czyta, testuje i analizuje (I nie trzeba wyjaśniać, gdzie należy szukać wyniku) wiadomo, że (o ile definicje pojęć są takie, jakich byśm oczekiwali) wyrażenie (suma (kwadraty (początkowe 7 liczby-pierwsze))) jest równoważne wyrażeniu (suma (kwadraty '(2 3 5 7 11 13))) które jest równoważne wyrażeniu (suma '(4 9 25 49 121 169)) i tak dalej. Zgodzę się, że przy projektowaniu systemów czasu rzeczywistego jest dużo kodu, którego nie da się "wepchnąć" w ten schemat. Ale nawet wtedy można zrobić dużo, żeby pozostać blisko tego modelu (warto przyjrzeć się np. modelowi aktorów z Erlanga/Elixira) > CZyli: doceniam elegancje Lispa, ale niestety nie > nie moge docenic praktycznosci Lispa w zwyklym zyciu programistycznym. > Czlek nie mysli odwrotną notacją polską Odwrotna notacja polska jest w języku Forth. Tutaj masz "w pełni onawiasowaną notację polską" (czasem nazywaną Cambridge-Polish) I jest moim zdaniem wartościowym narzędziem do myślenia. (ja dla zarobku też programuję głównie w C, ale od Lispa nauczyłem się bardzo dużo)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-01-03 12:51 -0800 |
| Message-ID | <4a9839e3-8ec6-4249-8b65-106016aaf109@googlegroups.com> |
| In reply to | #32236 |
W dniu czwartek, 3 stycznia 2019 18:20:04 UTC+1 użytkownik godek....@gmail.com napisał:
>
> Przykład, który lubię dawać na różnych prezentacjach, to program
> liczący sumę kwadratów początkowych siedmiu liczb pierwszych.
>
> Imperatywnie zapisalibyśmy go tak:
>
> 1: licznik := 7
> 2: liczba := 0
> 3: suma := 0
> 4: dopóki (licznik > 0):
> 5: jeżeli jest_pierwsza(liczba):
> 6: suma := suma + liczba^2
> 7: licznik := licznik - 1
> 8: liczba := liczba + 1
>
> i jeszcze musieli dopowiedzieć, że po wykonaniu programu
> wynik znajdziemy w zmiennej "suma".
>
> Natomiast przy podejściu funkcyjnym po prostu "formalizujemy"
> sformułowaine problemu: "suma kwadratów początkowych 7 liczb pierwszych"
> ma swoją strukturę gramatyczną, którą możemy uwypuklić, biorąc jednostki
> znaczeniowe w nawiasy:
>
> (suma (kwadraty (początkowe 7 liczby-pierwsze)))
>
> Teraz wystarczy nam wyjaśnić, co to jest (suma elementów)
> czym są (kwadraty elementów), co to jest (początkowe N elementy)
> i czym są liczby-pierwsze.
>
> To jest kod, który bardzo łatwo się komponuje, i który
> bardzo łatwo się czyta, testuje i analizuje (I nie trzeba wyjaśniać,
> gdzie należy szukać wyniku)
>
> wiadomo, że (o ile definicje pojęć są takie, jakich byśm oczekiwali) wyrażenie
>
> (suma (kwadraty (początkowe 7 liczby-pierwsze)))
>
> jest równoważne wyrażeniu
>
> (suma (kwadraty '(2 3 5 7 11 13)))
>
> które jest równoważne wyrażeniu
>
> (suma '(4 9 25 49 121 169))
>
> i tak dalej.
>
lol ale mozesz podac ten kod w lispie w postaci takiej kompletnosci jak ten przyklad w pseudkodzie, by to rzeczywiscie porownac?
bo to jest raczej istotnie
w c taki programik nie wyglada zbyt tragicznie
int PoliczSumeParuPoczatkowychLiczbPierwszych(int ilu)
{
int dodano_pierwszych =0;
int suma = 0;
for(int i=0;;i++)
{
if(jest_liczba_pierwsza(i))
{
suma+=i*i;
dodano_pierwszych++;
if(dodano_pierwszych==ilu) return suma;
}
}
}
to ze nie wydziela on etapow na podej pierwsze, podnies do kwadratu zsumuj wynika raczej z tego ze pisze sie to tak by dzialalo szybko.. jak ktos sie nie upiera by bylo tak szybko moze podzielic na te fazy
chetnie bym zobaczyl taki kompletny progamik w tym lispie scheme czy co to tam jest
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-03 13:21 -0800 |
| Message-ID | <1563f55d-4dbd-4ae7-9b9b-e8224dbfca60@googlegroups.com> |
| In reply to | #32238 |
W dniu czwartek, 3 stycznia 2019 21:51:47 UTC+1 użytkownik fir napisał:
> W dniu czwartek, 3 stycznia 2019 18:20:04 UTC+1 użytkownik godek....@gmail.com napisał:
> >
> > Przykład, który lubię dawać na różnych prezentacjach, to program
> > liczący sumę kwadratów początkowych siedmiu liczb pierwszych.
> >
> > Imperatywnie zapisalibyśmy go tak:
> >
> > 1: licznik := 7
> > 2: liczba := 0
> > 3: suma := 0
> > 4: dopóki (licznik > 0):
> > 5: jeżeli jest_pierwsza(liczba):
> > 6: suma := suma + liczba^2
> > 7: licznik := licznik - 1
> > 8: liczba := liczba + 1
> >
> > i jeszcze musieli dopowiedzieć, że po wykonaniu programu
> > wynik znajdziemy w zmiennej "suma".
> >
> > Natomiast przy podejściu funkcyjnym po prostu "formalizujemy"
> > sformułowaine problemu: "suma kwadratów początkowych 7 liczb pierwszych"
> > ma swoją strukturę gramatyczną, którą możemy uwypuklić, biorąc jednostki
> > znaczeniowe w nawiasy:
> >
> > (suma (kwadraty (początkowe 7 liczby-pierwsze)))
> >
> > Teraz wystarczy nam wyjaśnić, co to jest (suma elementów)
> > czym są (kwadraty elementów), co to jest (początkowe N elementy)
> > i czym są liczby-pierwsze.
> >
> > To jest kod, który bardzo łatwo się komponuje, i który
> > bardzo łatwo się czyta, testuje i analizuje (I nie trzeba wyjaśniać,
> > gdzie należy szukać wyniku)
> >
> > wiadomo, że (o ile definicje pojęć są takie, jakich byśm oczekiwali) wyrażenie
> >
> > (suma (kwadraty (początkowe 7 liczby-pierwsze)))
> >
> > jest równoważne wyrażeniu
> >
> > (suma (kwadraty '(2 3 5 7 11 13)))
> >
> > które jest równoważne wyrażeniu
> >
> > (suma '(4 9 25 49 121 169))
> >
> > i tak dalej.
> >
> lol ale mozesz podac ten kod w lispie w postaci takiej kompletnosci jak ten przyklad w pseudkodzie, by to rzeczywiscie porownac?
>
> bo to jest raczej istotnie
>
>
> w c taki programik nie wyglada zbyt tragicznie
>
>
> int PoliczSumeParuPoczatkowychLiczbPierwszych(int ilu)
> {
>
> int dodano_pierwszych =0;
> int suma = 0;
>
> for(int i=0;;i++)
> {
> if(jest_liczba_pierwsza(i))
> {
> suma+=i*i;
> dodano_pierwszych++;
> if(dodano_pierwszych==ilu) return suma;
> }
> }
> }
>
> to ze nie wydziela on etapow na podej pierwsze, podnies do kwadratu zsumuj wynika raczej z tego ze pisze sie to tak by dzialalo szybko.. jak ktos sie nie upiera by bylo tak szybko moze podzielic na te fazy
>
>
> chetnie bym zobaczyl taki kompletny progamik w tym lispie scheme czy co to tam jest
Ogólnie derywację tego programu mam dość dogłębnie opisaną
w pierwszym rozdziale "Pamphletu":
https://github.com/panicz/pamphlet/raw/master/pamphlet.pdf
W praktyce zapisałbym go raczej np. tak (jeżeli język
wspierałby leniwą ewaluację):
(sum (map square (initial 7 (only prime? numbers))))
gdzie "map", "only" i "initial" są zdefiniowane tak:
(define (map f list)
(if (null? list)
'()
;else
(cons (f (first list)) (map f (rest list)))))
(define (initial n elements)
(if (= n 0)
'()
;else
(cons (first elements) (initial (- n 1) (rest elements))))))
(define (only satisfying? elements)
(if (null? elements)
'()
;else
(if (satisfying? (first elements))
(cons (first elements) (only satisfying? (rest elements)))
;else
(only satisfying? (rest elements)))))
W Haskellu może jest nieco zwięźlej i czytelniej:
map f [] = []
map f (h:t) = (f h):(map f t)
initial 0 elements = []
initial n (first:rest) = first:(initial (n-1) rest)
only satisfying [] = []
only satisfying (first:rest) = if (satisfying first)
then first:(only satisfying rest)
else only satisfying rest
Teraz, w języku z leniwą ewaluacją możemy zbudować nieskończoną listę liczb:
(define (numbers-from n)
(cons n (numbers-from (+ n 1))))
(define numbers (numbers-from 0))
albo w Haskellu:
numbersFrom n = n:(numbersFrom (n+1))
numbers = numbersFrom 0
Sumę definiujemy następująco:
(define (sum list)
(if (null? list)
0
;else
(+ (first list) (sum (rest list)))))
albo w Haskellu:
sum [] = 0
sum (first:rest) = first + (sum rest)
W jezyku bez leniwej ewaluacji jest nieco ciężej (ten wariant jest
opisany w Pamphlecie)
Jeżeli idzie o "wydajność", to kompilator Haskella wspiera technikę
kompilacji zwaną "fuzją" albo "deforestacją", i efektywnie wynikowy
kod będzie z grubsza równoważny temu, co Ty napisałeś (nie będą
tworzone żadne dodatkowe struktury w pamięci, tylko będzie pętla
iterująca po jakichś tam zmiennych)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-01-03 16:13 -0800 |
| Message-ID | <0c9d0514-0a39-4a7f-aed2-9229eabebcff@googlegroups.com> |
| In reply to | #32239 |
W dniu czwartek, 3 stycznia 2019 22:21:26 UTC+1 użytkownik godek....@gmail.com napisał:
> W dniu czwartek, 3 stycznia 2019 21:51:47 UTC+1 użytkownik fir napisał:
> > W dniu czwartek, 3 stycznia 2019 18:20:04 UTC+1 użytkownik godek....@gmail.com napisał:
> > >
> > > Przykład, który lubię dawać na różnych prezentacjach, to program
> > > liczący sumę kwadratów początkowych siedmiu liczb pierwszych.
> > >
> > > Imperatywnie zapisalibyśmy go tak:
> > >
> > > 1: licznik := 7
> > > 2: liczba := 0
> > > 3: suma := 0
> > > 4: dopóki (licznik > 0):
> > > 5: jeżeli jest_pierwsza(liczba):
> > > 6: suma := suma + liczba^2
> > > 7: licznik := licznik - 1
> > > 8: liczba := liczba + 1
> > >
> > > i jeszcze musieli dopowiedzieć, że po wykonaniu programu
> > > wynik znajdziemy w zmiennej "suma".
> > >
> > > Natomiast przy podejściu funkcyjnym po prostu "formalizujemy"
> > > sformułowaine problemu: "suma kwadratów początkowych 7 liczb pierwszych"
> > > ma swoją strukturę gramatyczną, którą możemy uwypuklić, biorąc jednostki
> > > znaczeniowe w nawiasy:
> > >
> > > (suma (kwadraty (początkowe 7 liczby-pierwsze)))
> > >
> > > Teraz wystarczy nam wyjaśnić, co to jest (suma elementów)
> > > czym są (kwadraty elementów), co to jest (początkowe N elementy)
> > > i czym są liczby-pierwsze.
> > >
> > > To jest kod, który bardzo łatwo się komponuje, i który
> > > bardzo łatwo się czyta, testuje i analizuje (I nie trzeba wyjaśniać,
> > > gdzie należy szukać wyniku)
> > >
> > > wiadomo, że (o ile definicje pojęć są takie, jakich byśm oczekiwali) wyrażenie
> > >
> > > (suma (kwadraty (początkowe 7 liczby-pierwsze)))
> > >
> > > jest równoważne wyrażeniu
> > >
> > > (suma (kwadraty '(2 3 5 7 11 13)))
> > >
> > > które jest równoważne wyrażeniu
> > >
> > > (suma '(4 9 25 49 121 169))
> > >
> > > i tak dalej.
> > >
> > lol ale mozesz podac ten kod w lispie w postaci takiej kompletnosci jak ten przyklad w pseudkodzie, by to rzeczywiscie porownac?
> >
> > bo to jest raczej istotnie
> >
> >
> > w c taki programik nie wyglada zbyt tragicznie
> >
> >
> > int PoliczSumeParuPoczatkowychLiczbPierwszych(int ilu)
> > {
> >
> > int dodano_pierwszych =0;
> > int suma = 0;
> >
> > for(int i=0;;i++)
> > {
> > if(jest_liczba_pierwsza(i))
> > {
> > suma+=i*i;
> > dodano_pierwszych++;
> > if(dodano_pierwszych==ilu) return suma;
> > }
> > }
> > }
> >
> > to ze nie wydziela on etapow na podej pierwsze, podnies do kwadratu zsumuj wynika raczej z tego ze pisze sie to tak by dzialalo szybko.. jak ktos sie nie upiera by bylo tak szybko moze podzielic na te fazy
> >
> >
> > chetnie bym zobaczyl taki kompletny progamik w tym lispie scheme czy co to tam jest
>
> Ogólnie derywację tego programu mam dość dogłębnie opisaną
> w pierwszym rozdziale "Pamphletu":
> https://github.com/panicz/pamphlet/raw/master/pamphlet.pdf
>
> W praktyce zapisałbym go raczej np. tak (jeżeli język
> wspierałby leniwą ewaluację):
>
> (sum (map square (initial 7 (only prime? numbers))))
>
> gdzie "map", "only" i "initial" są zdefiniowane tak:
>
jakos nie wyglada mi to na prostsze niz wersja w c
a co to jest tam wyzej sum square (inty?) prime? (funkcja?) i numbers (???)
nie wyglada to na prostsze od c (dlugie jakies) a w to ze to bedzie tak szybkie tez nie do konca wierze ale powiedzmy ze to mniej istotne, przydaloby sie jednak by bylo choc prostsze a nie wyglada
sam ten kod w c chyab w sumie mozna napisac prsciej
int PoliczSumeParuPoczatkowychLiczbPierwszych(int ilu)
{
int i = 0, dodano = 0, suma = 0;
for(;;)
if(jest_liczba_pierwsza(++i))
{
suma += i*i ;
if(++dodano==ilu) return suma;
}
}
to i tak jest przydlugie, niepodobaja mi sie zwlaszcza te niepotrzebne jakby deklaracje.. no i jest trioche kryptyczne, no ale tak to sie pisze w c
> (define (map f list)
> (if (null? list)
> '()
> ;else
> (cons (f (first list)) (map f (rest list)))))
>
> (define (initial n elements)
> (if (= n 0)
> '()
> ;else
> (cons (first elements) (initial (- n 1) (rest elements))))))
>
> (define (only satisfying? elements)
> (if (null? elements)
> '()
> ;else
> (if (satisfying? (first elements))
> (cons (first elements) (only satisfying? (rest elements)))
> ;else
> (only satisfying? (rest elements)))))
>
> W Haskellu może jest nieco zwięźlej i czytelniej:
>
> map f [] = []
> map f (h:t) = (f h):(map f t)
>
> initial 0 elements = []
> initial n (first:rest) = first:(initial (n-1) rest)
>
> only satisfying [] = []
> only satisfying (first:rest) = if (satisfying first)
> then first:(only satisfying rest)
> else only satisfying rest
>
> Teraz, w języku z leniwą ewaluacją możemy zbudować nieskończoną listę liczb:
>
> (define (numbers-from n)
> (cons n (numbers-from (+ n 1))))
>
> (define numbers (numbers-from 0))
>
> albo w Haskellu:
>
> numbersFrom n = n:(numbersFrom (n+1))
>
> numbers = numbersFrom 0
>
> Sumę definiujemy następująco:
>
> (define (sum list)
> (if (null? list)
> 0
> ;else
> (+ (first list) (sum (rest list)))))
>
> albo w Haskellu:
>
> sum [] = 0
> sum (first:rest) = first + (sum rest)
>
> W jezyku bez leniwej ewaluacji jest nieco ciężej (ten wariant jest
> opisany w Pamphlecie)
>
> Jeżeli idzie o "wydajność", to kompilator Haskella wspiera technikę
> kompilacji zwaną "fuzją" albo "deforestacją", i efektywnie wynikowy
> kod będzie z grubsza równoważny temu, co Ty napisałeś (nie będą
> tworzone żadne dodatkowe struktury w pamięci, tylko będzie pętla
> iterująca po jakichś tam zmiennych)
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2019-01-04 00:40 -0800 |
| Message-ID | <3097018f-2da8-413f-81aa-0ede708b2459@googlegroups.com> |
| In reply to | #32241 |
W dniu piątek, 4 stycznia 2019 01:13:33 UTC+1 użytkownik fir napisał:
> > Ogólnie derywację tego programu mam dość dogłębnie opisaną
> > w pierwszym rozdziale "Pamphletu":
> > https://github.com/panicz/pamphlet/raw/master/pamphlet.pdf
> >
> > W praktyce zapisałbym go raczej np. tak (jeżeli język
> > wspierałby leniwą ewaluację):
> >
> > (sum (map square (initial 7 (only prime? numbers))))
> >
> > gdzie "map", "only" i "initial" są zdefiniowane tak:
> >
>
> jakos nie wyglada mi to na prostsze niz wersja w c
To nie jest tylko kwestia "wyglądania".
Do zrozumienia tego kodu wystarczy stosować rozumowanie
"podstawieniowe", które wcześniej pokazałem.
Do zrozumienia Twojego kodu w C oprócz podstawienia (które też
jest potrzebne, bo zdefiniowałeś funkcję z parametrem) trzeba
też rozumieć takie rzeczy, jak przepływ sterowania albo
operator przypisania.
> a co to jest tam wyzej sum square (inty?) prime? (funkcja?) i numbers (???)
jak mamy wyrażenie
(sum (map square (initial 7 (only prime? numbers))))
to sygnatury typów będą następujące:
sum :: Num a => [a] -> a
oznacza to, że funkcja "sum" bierze listę elementów o jakimś typie
numerycznym (czyli takim, dla którego zdefiniowany jest operator dodawania)
i zwraca element numeryczny. Operator :: czytamy jako "jest typu".
Rzeczy po lewej stronie operatora "=>" to tzw. "ograniczenia typów",
zaś to po prawej jest już konkretną sygnaturą. [a] oznacza listę elementów
typu a.
map :: (a -> b) -> [a] -> [b]
map jest funkcją, która pobiera jakąś funkcję jednoargumentową
oraz listę elementów, do których można zastosować tę funkcję,
i zwraca listę elementów typu wynikowego funkcji.
Warto zwrócić uwagę, że choć nasza percepcja jest taka, że "map" jest
funkcją dwuargumentową, z sygnatury typów możemy wyczytać, że jest to
funkcja pobierająca jakiś argument (funkcję) i zwracająca funkcję
pobierającą jakiś argument (listę), czyli - mówiąc w pewnym uproszczeniu
wszystkie wieloargumentowe funkcje w Haskellu są tak naprawdę jednoargumentowymi
funkcjami zwracającymi funkcje (ten ficzer nosi nazwę "Currying",
albo - jak chciała polska tłumaczka książki "Język C++" Stroustrupa
- "doprawianie" (!))
Funkcji square nie definiowaliśmy, ale jej definicja będzie taka:
square x = x * x
a sygnatura typów to oczywiście
square :: Num a => a -> a
(czyli funkcja, która bierze coś numerycznego i zwraca coś numerycznego
tego samego typu).
initial :: Int -> [a] -> [a]
Funkcja only pobiera predykat (czyli funkcję zwracającą wartość Boolowską)
i listę elementów, do których ten predykat daje się zastosować, i zwraca
"pomniejszoną" listę elementów:
only :: (a -> Bool) -> [a] -> [a]
Warto zwrócić uwagę, że system typów Haskella nie pozwala wyrazić tego,
że wynik funkcji jest "pomniejszony" (ale są języki, takie jak Idris
czy Liquid Haskell, w których tego rodzaju własności daje się wyrazić
w sygnaturze typów)
Wreszcie, numbers to po prostu lista liczb całkowitych:
numbers :: [Int]
> nie wyglada to na prostsze od c (dlugie jakies)
Funkcje "only", "map" i "initial" są już predefiniowane.
(tylko "only" nosi tak naprawdę nazwę "filter", a "initial" -- "take").
Ty w C użyłeś np. operatora "for" bez podawania jego definicji
(czego w C zresztą i tak nie dałoby się zrobić).
Gdyby korzystać z gotowych funkcji, i nie chcieć definiować np.
square, to (zakładając dostępność funkcji isPrime) cały program
wyglądałby tak:
foldr (+) 0 (map (^2) (take 7 (filter isPrime [2 ..])))
Warto przy tej okazji powiedzieć nieco o rodzinie funkcji fold.
Zasadnicza idea jest taka, że
fold (*) [a,b,c,d] = a * b * c * d
Jednak powyższe sformułowanie jest niejednoznaczne, bo prawą
stronę można interpretować jako
(a * (b * (c * d)))
albo jako
(((a * b) * c) * d)
albo jako
((a * b) * (c * d))
W praktyce Haskell daje dwie funkcje, foldl i foldr, które
działają w taki sposób:
foldl (*) e [a,b,c,d] = (((e * a) * b) * c) * d
foldr (*) e [a,b,c,d] = a * (b * (c * (d * e)))
Dodatkowy parametr e sprawia, że funkcje mają sensowną wartość
również dla listy pustej, i rozluźnia nieco wymagania narzucane
na operator (*).
(Oczywiście, (*) niekoniecznie oznacza tutaj mnożenie, ale
dowolny operator dwuargumentowy)
> a w to ze to bedzie tak szybkie tez nie do konca wierze
Informatyka to nie jest religia. Jak w coś nie wierzysz, to możesz
sprawdzić. (Tzn. ściśle rzecz biorąc pewnie nie będzie "tak szybkie",
bo Haskellowy runtime ma jakieś tam dodatkowe narzuty)
> przydaloby sie jednak by bylo choc prostsze a nie wyglada
Moim zdaniem jest tak proste, jak tylko się da.
> sam ten kod w c chyab w sumie mozna napisac prsciej
>
>
> int PoliczSumeParuPoczatkowychLiczbPierwszych(int ilu)
> {
> int i = 0, dodano = 0, suma = 0;
>
> for(;;)
> if(jest_liczba_pierwsza(++i))
> {
> suma += i*i ;
> if(++dodano==ilu) return suma;
> }
> }
Dla mnie nie jest to ani trochę prostsze od poprzedniej wersji.
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | pl.comp.programming
csiph-web