Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #30172 > unrolled thread
| Started by | godek.maciek@gmail.com |
|---|---|
| First post | 2017-08-12 14:07 -0700 |
| Last post | 2017-09-03 08:40 -0700 |
| Articles | 20 on this page of 206 — 15 participants |
Back to article view | Back to pl.comp.programming
Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-12 14:07 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-12 23:55 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-12 15:43 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-13 07:04 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-12 20:17 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-12 22:44 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-13 02:23 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-13 15:01 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-13 07:16 -0700
Re: Co jest nie tak z C++ (było: Rust) w systemie siła 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-08-13 16:52 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-13 18:15 +0200
Re: Co jest nie tak z C++ (było: Rust) w systemie siła 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-08-13 18:44 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-13 20:32 +0200
Re: Co jest nie tak z C++ (było: Rust) w systemie siła 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-08-13 21:23 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-08-16 09:47 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-16 20:28 +0200
Re: Co jest nie tak z C++ (było: Rust) Mateusz Bogusz <mabakay@o2.pl> - 2017-08-16 20:35 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-16 22:21 +0200
Re: Co jest nie tak z C++ (było: Rust) Mateusz Bogusz <mabakay@o2.pl> - 2017-08-18 18:46 +0200
Re: Co jest nie tak z C++ (było: Rust) szykcech@gmail.com - 2017-08-21 13:15 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-21 14:49 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-22 01:03 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-22 00:42 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-22 01:21 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-22 04:13 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-22 05:24 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-22 05:54 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-22 06:12 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-23 02:01 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 02:29 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-23 03:14 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 04:42 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-24 01:25 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 02:38 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-24 03:20 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 04:02 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-24 06:42 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-24 08:32 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-24 09:10 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-24 12:24 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:37 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-25 01:13 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 12:32 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-24 14:48 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 15:23 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-25 07:04 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-25 07:27 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-25 07:40 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 20:04 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-25 11:57 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 22:52 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-26 03:57 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-26 10:32 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-27 10:18 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 23:04 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-08-25 13:22 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 23:09 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 07:08 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-24 16:12 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-25 02:35 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-25 06:45 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 18:01 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 18:26 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-26 03:12 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 14:42 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-26 06:07 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 15:13 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-26 06:40 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 16:03 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-26 08:44 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 19:30 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-26 00:18 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 11:59 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-26 04:20 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 15:01 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-26 13:29 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-27 08:07 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-27 01:53 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-27 12:21 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-27 04:47 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-27 04:56 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-27 04:53 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-27 05:56 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-28 07:29 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-28 08:29 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-28 08:49 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 00:49 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-29 23:00 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 06:35 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 18:35 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 18:38 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 10:46 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-30 06:32 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 18:46 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 00:46 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 10:45 +0200
Re: Co jest nie tak z C++ (było: Rust) Szyk Cech <szyk100@o2.pl> - 2017-08-30 10:46 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 18:40 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 07:09 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 16:30 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 07:42 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 16:53 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 17:02 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 08:12 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 19:17 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 20:48 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 19:12 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 19:09 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 20:46 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 12:20 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 21:59 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-08-30 13:15 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 13:18 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 13:16 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 22:45 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 14:09 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-31 09:50 +0200
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-31 01:52 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-31 01:56 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-31 07:05 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-31 09:28 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-31 19:35 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-31 11:09 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-31 10:54 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-31 19:19 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-31 19:37 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-29 07:03 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-27 13:20 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-28 09:39 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-29 06:26 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-29 08:32 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-29 18:46 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-29 11:26 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:29 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:05 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:08 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 06:46 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:14 +0200
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-25 01:20 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-01 15:18 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-01 23:28 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-02 01:45 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-02 08:27 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-02 12:27 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-03 01:58 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-03 03:24 -0800
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2018-01-03 14:17 +0100
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-04 01:52 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-04 03:08 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-05 02:51 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-05 05:09 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-07 13:30 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-07 14:00 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-08 05:20 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-08 11:25 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-09 04:35 -0800
Re: Co jest nie tak z C++ (było: Rust) Roman Tyczka <noemail@because.no> - 2018-01-03 20:13 +0100
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-04 01:36 -0800
Re: Co jest nie tak z C++ (było: Rust) Roman Tyczka <noemail@because.no> - 2018-01-05 22:57 +0100
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-07 13:19 -0800
Re: Co jest nie tak z C++ (było: Rust) Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2018-01-02 14:32 +0100
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:04 +0200
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-25 00:45 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 12:54 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 17:55 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 15:22 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 17:31 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:33 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 14:33 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-24 00:14 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 23:45 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:06 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 12:39 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 15:24 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 08:05 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 17:35 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 15:13 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 08:18 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 17:38 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:35 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 01:06 -0700
[OT, SPAM] Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:07 +0200
Re: [OT, SPAM] Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 22:51 -0700
Re: [OT, SPAM] Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 17:41 +0200
Re: [OT, SPAM] Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-25 08:52 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 13:05 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 18:00 +0200
Re: Co jest nie tak z C++ (było: Rust) Piotr Chamera <piotr_chamera@poczta.onet.pl> - 2017-08-23 18:15 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:17 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:11 +0200
Re: Co jest nie tak z C++ (było: Rust) Mateusz Bogusz <mabakay@o2.pl> - 2017-08-24 20:11 +0200
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-25 00:42 -0700
Re: Co jest nie tak z C++ (było: Rust) Mateusz Bogusz <mabakay@o2.pl> - 2017-08-25 22:53 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 13:12 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-22 04:49 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-22 05:16 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:02 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 12:35 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 17:49 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 18:54 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 20:20 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 21:00 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-08-21 23:43 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 20:52 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-09-03 01:15 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-09-03 08:40 -0700
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-21 14:49 -0700 |
| Message-ID | <c6d7c705-4b1b-484f-8702-d9f8c054d71c@googlegroups.com> |
| In reply to | #30392 |
W dniu poniedziałek, 21 sierpnia 2017 22:15:55 UTC+2 użytkownik szyk...@gmail.com napisał: > Ja odnoszę wrażenie, że obecnie programiści nie za bardzo wiedzą jaki język jest na prawdę najlepszy i myślą, że w zasadzie to najbardziej zależy od zastosowania. Bo w większości wypadków nie ważne jest jak jest szybki - liczy się jak szybko da się coś zakodować. Co więcej, niektórzy programiści (np. ja) śmią twierdzić, że stwierdzenie, że "język programowania jest szybki", jest błędem kategorialnym. Może można powiedzieć, że dany język posiada implementację pozwalającą na szybkie wykonywanie napisanego w nim kodu. Ale w ogólnym przypadku sprawa nie jest taka prosta. > Ja natomiast mam inne zdanie na ten temat. > > Moim zdaniem (porównując najpopularniejsze języki: Asembler, C, C++, D, Java, PHP, Python, JavaScript - tyle poznałem i mi to wystarczy) okazuje się, że C++ jest najlepszy. Oto powody: Jeżeli chcesz zrobić aplikację działającą w przeglądarce, C++ wiele Ci nie pomoże -- niestety, jesteś raczej skazany na JavaScript, albo coś, co się kompiluje do JavaScriptu (Elm, CoffeeScript, TypeScript, PureScript, ClojureScript, ...) Jeżeli zaś idzie o stwierdzenie, czy dany przekrój języków jest wystarczający, to tak naprawdę kwestia nie jest taka oczywista. Ludwig Wittgenstein stwierdził w "Traktacie logiczno-filozoficznym": "Granice mojego języka oznaczają granice mojego świata". W podobnym duchu rozumował Paul Graham, formułując swój "Blub paradox": http://www.paulgraham.com/avg.html Najlepszy język, jaki znamy, nie pozwala nam obiektywnie spojrzeć na jego wady. Dopiero znajomość wielu różnych języków pozwala widzieć wady i zalety w pooszczególnych przypadkach. Moim zdaniem Haskell jest pod wieloma względami dużo lepszy niż C++. Ale pewnie warto się zapoznać z odmiennymi sposobami myślenia, takimi z jakimi masz do czynienia w przypadku języków takich jak Forth, Prolog, Smalltalk czy Scheme. > 1. Bez udziwnień obsługuje standardowe API obecnych systemów operacyjnych (czyli C). D ma niby wsparcie dla funkcji C ale trzeba je zdeklarować w języku D. W C++ też musisz zadeklarować te funkcje jako extern "C". Zaś jeżeli idzie o udziwnienia, to name mangling jest jednym z największych, jakie widziałem. > 2. Zapewnia wszystko to co język obiektowy powinien mieć - a nawet więcej niż wiele innych języków, bo ma wielodziedziczenie i szablony. I to wszystko ma bez udziwnień - są to cechy naturalne tego języka. Szablony zdają mi się jednym wielkim udziwnieniem. Tym bardziej, że nie zostały zaprojektowane w celu, do którego finalnie zaczęły być używane. > Tak więc nie jest uczciwe porównywanie tego języka do Asemblera. Tu bym porównał raczej Asemblera do łopaty, a C++ do koparki, a języki skryptowe do mini koparek. W ogóle mówienie o asemblerze jako języku to pomyłka. > 3. Kompiluje się do kodu maszynowego i przez to działa w sposób naturalny - jak to przewiduje producent procesora. Jego pliki wykonywalne są najmniejsze z możliwych, No chyba nie są. > są prawie tak szybkie jak programy asemblerowe i działają samodzielnie (wymagając jedynie bibliotek dll - jeśli tak zostały skompilowane - a często wymaga tego licencja biblioteki). Nie wymaga żadnego interpretera, ani żadnych "maszyn wirtualnych" które nic nie dają prawdziwemu programiście (bo gdy do C++ przechodzi się z Asemblera to ręczne zarządzanie pamięcią jest czymś naturalnym i intuicyjnym - ja w ten sposób się uczyłem, bo to wydawało mi się najsensowniejsze i nadal tak mi się wydaje). Poza tym obecnie w C++ zarządzanie pamięcią często ogranicza się do podania "rodzica" jako parametr konstruktora i on usuwa ten nowy obiekt (Qt tak jest zrobione), lub używa się "sprytnych wskaźników" które usuną obiekt kiedy trzeba (to implementuje biblioteka standardowa). Czyli masz miliard różnych sposobów zarządzania pamięcią, co w konsekwencji utrudnia wnioskowanie o tym, co się wydarzy > 4. Umożliwia dobrą separację interfejsu (deklaracji) i implementacji. Są pliki *.h które dobrze opisują zawartość plików *.cpp. To trzeba docenić, bo tego nie ma w innych (wymienionych) językach z wyjątkiem C. W Haskellu separacja interfejsu od implementacji jest dużo lepsza niż w C++ > 5. Jest przenośny. Umiejętnie pisane programy (w Qt ;] ) są bez problemowo przenośne. A kod nieprzenośny daje się izolować (można wyłączać całe pliki *.cpp i kompilować warunkowo). Ta przenośność teoretycznie nie jest obarczona jakimś spadkiem wydajności czy innymi ukrytymi kosztami. Teoretycznie programy C++ są przenośne na każdą platformę na którą jest odpowiednio aktualny kompilator C++. Jednak ważniejszym ograniczeniem jest wsparcie danej platformy przez dostawców bibliotek. Python też jest przenośny między różnymi platformami (w końcu jest napisany w C). Podobnie Haskell. Scheme jest tak przenośny, że aż ciężko to sobie wyobrazić. Są kompilatory Scheme do C, kompilatory do kodu maszynowego popularnych platform, kompilatory do JavaScriptu, interpretery w JavaScripcie, implementacje na JVM i na CLR. Zresztą C wydaje się bardziej przenośny niż C++. Z pewnością dużo łatwiej napisać dla niego kompilator. > 6. C++ żyje własnym życiem bez dominacji jednej firmy która by narzucała innym jaki ten język ma być. Nie kompatybilne zmiany się nie przyjmują, bo ludzie chcą mieć wybór - np.: pod Windows kompilator VC++, a pod Linuxem g++... Python tak samo. Haskell tak samo. Racket tak samo.
[toc] | [prev] | [next] | [standalone]
| From | "AK" <nobody@nowhere.net> |
|---|---|
| Date | 2017-08-22 01:03 +0200 |
| Message-ID | <onfotu$lh6$1@node1.news.atman.pl> |
| In reply to | #30392 |
Użytkownik <szykcech@gmail.com> napisał: > Ja natomiast mam inne zdanie na ten temat. Dobrze, Wolno Ci przeciez. Tylko nie kłam ze poznales _cokowiek innego_ poza C/C++ Tak! Madrze ktos zacytowal filozofa: "granice mego jezyka wytyczaja granice mego swiata" Twoj swiat bolesnie ograniczaja kraty ++. AK
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2017-08-22 00:42 -0700 |
| Message-ID | <029f4610-f485-42c9-8c26-d94f4d419acf@googlegroups.com> |
| In reply to | #30397 |
On Tuesday, August 22, 2017 at 1:04:32 AM UTC+2, AK wrote: > Użytkownik <szykcech@gmail.com> napisał: > > > Ja natomiast mam inne zdanie na ten temat. > > Dobrze, Wolno Ci przeciez. > Tylko nie kłam ze poznales _cokowiek innego_ poza C/C++ > Tak! Madrze ktos zacytowal filozofa: "granice mego jezyka wytyczaja granice mego swiata" > Twoj swiat bolesnie ograniczaja kraty ++. Ale jaka konkretnie mądrość z tego cytatu płynie w kontekście języków programowania? Pozdrawiam
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-22 01:21 -0700 |
| Message-ID | <3bc0ce1a-9f95-426f-9cc4-5de0e35a6ccd@googlegroups.com> |
| In reply to | #30399 |
W dniu wtorek, 22 sierpnia 2017 09:42:53 UTC+2 użytkownik M.M. napisał:
> > Tak! Madrze ktos zacytowal filozofa: "granice mego jezyka wytyczaja granice mego swiata"
> > Twoj swiat bolesnie ograniczaja kraty ++.
>
> Ale jaka konkretnie mądrość z tego cytatu płynie w kontekście
> języków programowania?
Pozwolę sobie odpowiedzieć nieco większym cytatem, pochodzącym od
Alana Kaya, twórcy języka Smalltalk:
Allen Newell visited PARC with his theory of hierarchical thinking
and was challenged to prove it. He was given a programming problem
to solve while the protocol was collected. The problem was: given
a list of items, produce a list consisting of all of the odd indexed
items followed by all of the even indexed items. Newell's internal
programming language resembled IPL-V in which pointers are manipulated
explicitly, and he got into quite a struggle to do the program.
In 2 seconds I wrote down:
oddsEvens(x) = append(odds(x), evens(x))
the statement of the problem in Landin's LISP syntax—and also
the first part of the solution. Then a few seconds later:
where odds(x) = if null(x) ∨ null(tl(x)) then x
else hd(x) & odds(ttl(x))
evens(x) = if null(x) ∨ null(tl(x)) then nil
else odds(tl(x))
This characteristic of writing down many solutions in declarative
form and have them also be the programs is part of the appeal
and beauty of this kind of language. Watching a famous guy much
smarter than I struggle for more than 30 minutes to not quite
solve the problem his way (there was a bug) made quite an impression.
It brought home to me once again that "point of view is worth 80 IQ points."
I wasn't smarter but I had a much better internal thinking tool to
amplify my abilities.
http://worrydream.com/EarlyHistoryOfSmalltalk/
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2017-08-22 04:13 -0700 |
| Message-ID | <693ac316-4d15-4fa3-a0e9-f83645248f7c@googlegroups.com> |
| In reply to | #30400 |
> In 2 seconds I wrote down: > > oddsEvens(x) = append(odds(x), evens(x)) > > the statement of the problem in Landin's LISP syntax—and also > the first part of the solution. Then a few seconds later: > > where odds(x) = if null(x) ∨ null(tl(x)) then x > else hd(x) & odds(ttl(x)) > evens(x) = if null(x) ∨ null(tl(x)) then nil > else odds(tl(x)) Co za sieczka. To ma być "wysokopoziomowe"? W języku Wolfram można tak: oddsEvens[x_] := Join[x[[1 ;; ;; 2]], x[[2 ;; ;; 2]]] gdzie zapis x[[i ;; ;; s]] oznacza listę elementów wybranych z x, od i-tego do końca z krokiem s, a Join skleja listy podane jako argumenty. Jedna linijka kodu, posługując się wyłącznie pojęciami z dziedziny zadanego problemu. Wtedy można mówić o programowaniu wysokopoziomowym. > I wasn't smarter but I had a much better internal thinking tool to > amplify my abilities. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-22 05:24 -0700 |
| Message-ID | <c24b0ded-1779-4cf4-89b6-d11a2b56c71d@googlegroups.com> |
| In reply to | #30402 |
W dniu wtorek, 22 sierpnia 2017 13:13:54 UTC+2 użytkownik Maciej Sobczak napisał: > > In 2 seconds I wrote down: > > > > oddsEvens(x) = append(odds(x), evens(x)) > > > > the statement of the problem in Landin's LISP syntax—and also > > the first part of the solution. Then a few seconds later: > > > > where odds(x) = if null(x) ∨ null(tl(x)) then x > > else hd(x) & odds(ttl(x)) > > evens(x) = if null(x) ∨ null(tl(x)) then nil > > else odds(tl(x)) > > Co za sieczka. To ma być "wysokopoziomowe"? > > W języku Wolfram można tak: > > oddsEvens[x_] := Join[x[[1 ;; ;; 2]], x[[2 ;; ;; 2]]] > > gdzie zapis x[[i ;; ;; s]] oznacza listę elementów wybranych z x, od i-tego do końca z krokiem s, a Join skleja listy podane jako argumenty. Faktycznie, właśnie coś takiego sobie myślę widząc zapis x[[i ;; ;; s]]. I właśnie w ten sposób chciałbym zapisywać "listę elementów wybranch z x od i-tego miejsca z krokiem s". Bo to się rozumie samo przez się. Zresztą, jaka mogłaby być inna interpretacja dla podwójnego średnika oddzielonego spacją w podwójnie zagnieżdżonym nawiasie kwadratowym?
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2017-08-22 05:54 -0700 |
| Message-ID | <d9e1f7b0-fcac-4864-b7da-4ac7ebde6c3c@googlegroups.com> |
| In reply to | #30405 |
> Faktycznie, właśnie coś takiego sobie myślę widząc zapis > x[[i ;; ;; s]]. Bez czytania dokumentacji i przy pierwszym kontakcie ze składnią? Niezły jesteś. Ja musiałem przeczytać dokumentację, o tutaj: http://reference.wolfram.com/language/ref/Part.html > Zresztą, jaka mogłaby być inna > interpretacja dla podwójnego średnika oddzielonego spacją w podwójnie > zagnieżdżonym nawiasie kwadratowym? Po rzuceniu okiem na linka powyżej (tak nawet bez przewijania, wystarczy początek strony) interpretacja mogłaby być właśnie taka a nie inna. I wyobraź sobie, że o hd(x), tl(x) i ttl(x) też trzeba najpierw gdzieś przeczytać, bo bez tego to są mnemoniki z epoki asemblera, chyba że mam losowo wybrać coś z tych wyników: http://www.acronymfinder.com/HD.html http://www.acronymfinder.com/TL.html http://www.acronymfinder.com/TTL.html Pierwsze wyniki to: High Definition Toilet Total Teraz moja kolej: "jaka mogłaby być inna interpretacja"? Tak, znam LISPa i wiem co te skróty mogą oznaczać w Twoim SmallTalkowym cytacie, ale jak trolować, to najlepiej w parach. Na poważnie, ten Twój przykład mnie kompletnie nie przekonał. Nieparzyste i parzyste elementy to pojęcia na tyle oczywiste, że nie powinny wymagać rekurencyjnej rekonstrukcji ani sprawdzania cztery razy (!) czy coś jest nullem, czy nie jest. Najśmieszniejsze jest to, że ten cytat był o wyższości czegoś nad językiem opartym o wskaźniki - a tu proszę, cztery razy test na nulla, żeby wybrać z listy co drugi element? No bez jaj. To jest strzał w stopę. Dobrze, że takie języki to tylko historia. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-22 06:12 -0700 |
| Message-ID | <51e012ee-a143-4497-b42c-4c595ec16bbc@googlegroups.com> |
| In reply to | #30407 |
W dniu wtorek, 22 sierpnia 2017 14:54:08 UTC+2 użytkownik Maciej Sobczak napisał: > > Faktycznie, właśnie coś takiego sobie myślę widząc zapis > > x[[i ;; ;; s]]. > > Bez czytania dokumentacji i przy pierwszym kontakcie ze składnią? Niezły jesteś. To był sarkazm. Łatwo jest nawymyślać dużo dziwnej składni dla języków programowania, która może się podobać twórcy tej składni i ewentualnie jakiejś grupie jego fanbojów, ale która jest zupełnie niezrozumiała dla osób z zewnątrz. > Ja musiałem przeczytać dokumentację, o tutaj: > > http://reference.wolfram.com/language/ref/Part.html Właśnie o to chodzi. A Alan Kay NIE MUSIAŁ przeczytać żadnej dokumentacji, żeby rozwiązać ten problem przy pomocy podstawowych operatorów i rekurencji. > > Zresztą, jaka mogłaby być inna > > interpretacja dla podwójnego średnika oddzielonego spacją w podwójnie > > zagnieżdżonym nawiasie kwadratowym? > > Po rzuceniu okiem na linka powyżej (tak nawet bez przewijania, wystarczy początek strony) interpretacja mogłaby być właśnie taka a nie inna. > > I wyobraź sobie, że o hd(x), tl(x) i ttl(x) też trzeba najpierw gdzieś przeczytać, bo bez tego to są mnemoniki z epoki asemblera, chyba że mam losowo wybrać coś z tych wyników: Owszem. hd, tl i ttl, czy car, cdr i cddr to nie są dobre nazwy. pewnie head i tail albo first i rest byłyby lepsze. Tym niemniej, są to najprostsze możliwe koncepty, które wystarczy opanować, żeby zrozumieć bardzo dużo kodu tego rodzaju. Dla odmiany, żebyś nie wiem ile siedział w Mathematice, zawsze znajdą się jakieś operatory, których nie będziesz miał szans zrozumieć bez dokumentacji. I niestety, takie symbole jak # czy @ nie są samodokumentujące (w przeciwieństwie do nazw funkcji) > Pierwsze wyniki to: High Definition Toilet Total > > Teraz moja kolej: "jaka mogłaby być inna interpretacja"? > > Tak, znam LISPa i wiem co te skróty mogą oznaczać w Twoim SmallTalkowym cytacie, ale jak trolować, to najlepiej w parach. > > Na poważnie, ten Twój przykład mnie kompletnie nie przekonał. Odnoszę wrażenie, że nawet do Ciebie nie dotarł. > Nieparzyste i parzyste elementy to pojęcia na tyle oczywiste, że nie powinny wymagać rekurencyjnej rekonstrukcji ani sprawdzania cztery razy (!) czy coś jest nullem, czy nie jest. Najśmieszniejsze jest to, że ten cytat był o wyższości czegoś nad językiem opartym o wskaźniki - a tu proszę, cztery razy test na nulla, żeby wybrać z listy co drugi element? No bez jaj. To jest strzał w stopę. Dobrze, że takie języki to tylko historia. Może przed skrytykowaniem najpierw spróbowałbyś zrozumieć kontekst tego, o czym mowa?
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2017-08-23 02:01 -0700 |
| Message-ID | <cbff479c-fed1-4379-82c4-547376fb73b2@googlegroups.com> |
| In reply to | #30408 |
> > Ja musiałem przeczytać dokumentację, o tutaj: > > Właśnie o to chodzi. A Alan Kay NIE MUSIAŁ przeczytać żadnej > dokumentacji, Musiał. Musiał przeczytać o hd, tl, ttl, nil i null oraz wiedzieć, co robią operatory v oraz &. I jeszcze parę innych rzeczy. > Owszem. hd, tl i ttl, czy car, cdr i cddr to nie są dobre nazwy. No nie są. Ale po pierwszym dniu da się zapamiętać. Podobnie jak da się zapamiętać jak wygląda indeksowanie list w Wolframie. > Dla odmiany, żebyś nie wiem ile siedział w Mathematice, zawsze znajdą > się jakieś operatory, których nie będziesz miał szans zrozumieć > bez dokumentacji. Dla odmiany, żebyś nie wiem ile siedział w Lispie czy innym SmallTalku, zawsze znajdą się jakies funkcje, których nie będziesz miał szans zrozumieć bez dokumentacji. > bez dokumentacji. I niestety, takie symbole jak # czy @ nie są > samodokumentujące Faktycznie nie są. > (w przeciwieństwie do nazw funkcji) W przeciwieństwie np. do funkcji ttl? Niestety nie bardzo. > > Na poważnie, ten Twój przykład mnie kompletnie nie przekonał. > > Odnoszę wrażenie, że nawet do Ciebie nie dotarł. Nie przekonał. Rozumiem, że parę dekad temu ktoś się jarał, że można rekurencyjnie wyciągnąć z listy elementy na nieparzystych pozycjach. Parę dekad później mnie takie coś nie jara. > Może przed skrytykowaniem najpierw spróbowałbyś zrozumieć kontekst tego, > o czym mowa? Że mimo wszystko było to fajniejsze, niż istniejące alternatywy? Mogło tak być. Ale dzisiaj mnie to nie przekonuje. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-23 02:29 -0700 |
| Message-ID | <3e09407c-ec5a-4d26-aea2-e25fa76466e3@googlegroups.com> |
| In reply to | #30416 |
W dniu środa, 23 sierpnia 2017 11:01:44 UTC+2 użytkownik Maciej Sobczak napisał: > > > Ja musiałem przeczytać dokumentację, o tutaj: > > > > Właśnie o to chodzi. A Alan Kay NIE MUSIAŁ przeczytać żadnej > > dokumentacji, > > Musiał. Musiał przeczytać o hd, tl, ttl, nil i null oraz wiedzieć, co robią operatory v oraz &. I jeszcze parę innych rzeczy. Nie. Musiał nauczyć się języka, który potem zmieścił się w jego głowie. Język programowania stał się narzędziem do myślenia, a nie sposobem wydawania komputerowi rozkazów. > > Dla odmiany, żebyś nie wiem ile siedział w Mathematice, zawsze znajdą > > się jakieś operatory, których nie będziesz miał szans zrozumieć > > bez dokumentacji. > > Dla odmiany, żebyś nie wiem ile siedział w Lispie czy innym SmallTalku, > zawsze znajdą się jakies funkcje, których nie będziesz miał szans > zrozumieć bez dokumentacji. Ale przynajmniej będziesz miał szanse je wypowiedzieć bez dokumentacji. > > bez dokumentacji. I niestety, takie symbole jak # czy @ nie są > > samodokumentujące > > Faktycznie nie są. > > > (w przeciwieństwie do nazw funkcji) > > W przeciwieństwie np. do funkcji ttl? Niestety nie bardzo. Nie mówię o kryptycznych nazwach funkcji. Zawsze można wymyślić nazwę, która nie będzie niczego nikomu mówiła. Jednak w moim odczuciu linijka oddsEvens(x) = append(odds(x), evens(x)) jest zdecydowanie czytelniejsza od oddsEvens[x_] := Join[x[[1 ;; ;; 2]], x[[2 ;; ;; 2]]] > > > Na poważnie, ten Twój przykład mnie kompletnie nie przekonał. > > > > Odnoszę wrażenie, że nawet do Ciebie nie dotarł. > > Nie przekonał. Nie przekonał do czego? > Rozumiem, że parę dekad temu ktoś się jarał, że można rekurencyjnie > wyciągnąć z listy elementy na nieparzystych pozycjach. Parę dekad > później mnie takie coś nie jara. Jednak nie dotarł. > > Może przed skrytykowaniem najpierw spróbowałbyś zrozumieć kontekst tego, > > o czym mowa? > > Że mimo wszystko było to fajniejsze, niż istniejące alternatywy? Nie. Że język jest narzędziem do myślenia. Nota bene Mathematica, której przykład podałeś, też jest językiem aplikatywnym, którego zasadnicze założenia wywodzą się z Lispa, i również można o nim wnioskować w terminach podstawieniowego modelu obliczeń. To, czy wprowadzisz do języka podstawowy operator do rozwiązania problemu X, czy musisz sobie ten operator sam zdefiniować, jest sprawą drugorzędną (o ile oczywiście język daje ci możliwość definiowania) > Mogło tak być. Ale dzisiaj mnie to nie przekonuje. Nie przekonuje do czego?
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2017-08-23 03:14 -0700 |
| Message-ID | <695ab241-0f16-4264-acb4-d3dd3d16e3f6@googlegroups.com> |
| In reply to | #30417 |
> > Musiał. Musiał przeczytać o hd, tl, ttl, nil i null oraz wiedzieć, co robią operatory v oraz &. I jeszcze parę innych rzeczy. > > Nie. Urodził się z tą wiedzą? Naprawdę? > Musiał nauczyć się języka, który potem zmieścił się w jego głowie. To stwierdzenie dotyczy wszystkich języków. Mam wrażenie, że ideologizujesz i dorabiasz mitologię do czegoś, co na to nie zasługuje. > Ale przynajmniej będziesz miał szanse je wypowiedzieć bez dokumentacji. Ale przecież operatory w Wolframie też można wypowiedzieć. Np. operator indeksowania (to te podwójne nawiasy) nazywa się Part. I co ciekawe, jest to po prostu inna składnia na to samo, więc a[[idx]] oraz Part[a,idx] to są te same operacje. Różnią się tylko w pisowni. Podobnie, x+y to Plus[x,y]. Itd. Oznacza to też, że każdy program w Wolframie można napisać nie używając żadnych operatorów. Czyli jeśli nieczytelne operatory są dla Ciebie problemem i wolisz samodokumentujący się zapis słowny, to w Wolframie możesz mieć tego nawet więcej, niż w SmallTalku. > Jednak w moim odczuciu linijka > > oddsEvens(x) = append(odds(x), evens(x)) > > jest zdecydowanie czytelniejsza od > > oddsEvens[x_] := Join[x[[1 ;; ;; 2]], x[[2 ;; ;; 2]]] No bez jaj. Naprawdę nie zrozumiałeś? oddsEvens[x_] := Join[odds[x], evens[x]] Teraz lepiej? Oczywiście, teraz potrzebujesz zdefiniować osobno czym jest odds[x_] oraz evens[x_], np.: odds[x_]:=x[[1 ;; ;; 2]] evens[x_]:=x[[2 ;; ;; 2]] albo nawet: odds[x_]:=Part[x, 1 ;; ;; 2] evens[x_]:=Part[x, 2 ;; ;; 2] jeśli bardzo nie lubisz podwójnych nawiasów. Ale uznałem, że taka "refaktoryzacja" jest tutaj przesadą, bo jeśli jakaś funkcja pomocnicza jest implementowana jedną operacją, to nie ma po co takiej funkcji definiować i można od razu rozwiązać właściwy (ten zadany) problem. > Nie przekonał do czego? A do czego miał przekonać? :-) > Że język jest narzędziem do myślenia. Każdy jest. Dlatego ten Twój przykład niczego szczególnego w tym zakresie nie pokazał. Ot, dawno temu jakiś koleś napisał długi i skomplikowany program na zrobienie prostej rzeczy. Dzisiaj proste rzeczy robi się krótkimi programami, dzięki czemu można podnieść poziom i łatwiej/szybciej myśleć o rzeczach bardziej skomplikowanych. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-23 04:42 -0700 |
| Message-ID | <cc3f901a-2460-4337-ace4-f8eff6432710@googlegroups.com> |
| In reply to | #30418 |
W dniu środa, 23 sierpnia 2017 12:15:01 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Musiał. Musiał przeczytać o hd, tl, ttl, nil i null oraz wiedzieć, co robią operatory v oraz &. I jeszcze parę innych rzeczy.
> >
> > Nie.
>
> Urodził się z tą wiedzą? Naprawdę?
Nie. Gdybyś przeczytał jedno zdanie za tym słowem,
pewnie zauważyłbyś, że było tam napisane
"Musiał nauczyć się języka".
Podejrzewam, że gdybyś przeczytał jeden post przed tym,
w którym wkleiłem ten cytat, nie wszczynałbyś tej
dyskusji.
> > Musiał nauczyć się języka, który potem zmieścił się w jego głowie.
>
> To stwierdzenie dotyczy wszystkich języków. Mam wrażenie,
> że ideologizujesz i dorabiasz mitologię do czegoś, co na to nie zasługuje.
Tak. Tylko że w przypadku niektórych języków rozwiązanie
tego problemu zajmuje pół godziny albo wymaga grzebania po dokumentacji,
żeby zarówno zapisać, jak i zrozumieć rozwiązanie, a w przypadku innych
-- kilkanaście sekund, i wszystko jest podane na dłoni.
Mogę podać inny przykład, bliższy temu, o czym tutaj jest mowa.
Kiedyś, dawno temu, jak jeszcze pisałem engine 3D w C++, to na podstawie
książki Stroustrupa skleciłem główną pętlę, której fragment wyglądał
tak, mniej więcej:
for (int i = 0; i < ticks_per_frame; i++) {
for_each(in_seq(sectors), bind2nd(mem_fun(&Sector::update), 0.07));
for_each(in_seq(portals), bind2nd(mem_fun(&Portal::update), 0.07));
for_each(in_seq(ropes), bind2nd(mem_fun(&Rope::update), 0.07));
}
Twórca języka dostarczył mi środki wyrazu, i kiedy czytam ten kod, jestem
z grubsza w stanie zrozumieć, co robią takie kwiatki, jak in_seq,
bind2nd czy mem_fun. Ale bez książki raczej bym czegoś takiego nie
napisał. Pewnie nawet bez kompilatora miałbym problem, czy umieścić
ampersand tu i ówdzie, czy nie umieszczać.
Dla odmiany taki chociażby Python pozwoliłby wyrazić te konstrukcje
np. tak:
for instance in range(ticks_per_second):
for sector in sectors:
sector.update(0.07)
for portal in portals:
portal.update(0.07)
for rope in ropes:
rope.update(0.07)
W Pythonie piszę rzadko, ale nie musiałem zerkać do dokumentacji,
żeby napisać powyższych kilka linijek.
> > Ale przynajmniej będziesz miał szanse je wypowiedzieć bez dokumentacji.
>
> Ale przecież operatory w Wolframie też można wypowiedzieć.
> Np. operator indeksowania (to te podwójne nawiasy) nazywa się
> Part.
Dziwne. Nie przyszło mi do głowy, żeby [[_ ;; ;; _]] wymówić "Part".
Prędzej wymówiłbym to jako "otwórz nawias kwadratowy, otwórz nawias
kwadratowy, coś, spacja, średnik, średnik, spacja, średnik, średnik,
spacja, coś, zamknij nawias kwadratowy, zamknij nawias kwadratowy".
> > Jednak w moim odczuciu linijka
> >
> > oddsEvens(x) = append(odds(x), evens(x))
> >
> > jest zdecydowanie czytelniejsza od
> >
> > oddsEvens[x_] := Join[x[[1 ;; ;; 2]], x[[2 ;; ;; 2]]]
>
> No bez jaj. Naprawdę nie zrozumiałeś?
Zrozumiałem, i to od razu, jak tylko wyjaśniłeś, co robi operator
[[_ ;; ;; _]]. Pewnie gdybyś nie wyjaśnił, to znając cel rozwiązania,
i tak bym odgadł, co ów dziwny splot symboli oznacza.
Stwierdzam tylko, że to pierwsze jest czytelniejsze.
> oddsEvens[x_] := Join[odds[x], evens[x]]
>
> Teraz lepiej?
Czytelniej.
Wątpliwości w dalszym ciągu wzbudza rola podkreślnika po argumencie
po lewej stronie znaku ":=", oraz to, dlaczego do wyrażenia tożsamości
użyto symbolu powszechnie używanego w informatyce w roli przypisania.
> Oczywiście, teraz potrzebujesz zdefiniować osobno czym jest odds[x_] oraz evens[x_], np.:
>
> odds[x_]:=x[[1 ;; ;; 2]]
> evens[x_]:=x[[2 ;; ;; 2]]
>
> albo nawet:
>
> odds[x_]:=Part[x, 1 ;; ;; 2]
> evens[x_]:=Part[x, 2 ;; ;; 2]
>
> jeśli bardzo nie lubisz podwójnych nawiasów.
Podwójnych podwójnych średników też nie lubię.
> Ale uznałem, że taka "refaktoryzacja" jest tutaj przesadą,
> bo jeśli jakaś funkcja pomocnicza jest implementowana jedną
> operacją, to nie ma po co takiej funkcji definiować
> i można od razu rozwiązać właściwy (ten zadany) problem.
Zgadzam się.
Gdybyśmy zresztą nawet nie dysponowali funkcją Parts, moglibyśmy
ją sobie zdefiniować przy pomocy cons, car, cdr i rekurencji.
> > Nie przekonał do czego?
>
> A do czego miał przekonać? :-)
Że języki, które znamy, warunkują sposób, w jaki myślimy,
albo -- jak to powiedział Wittgenstein, "granice mojego języka
wyznaczają granice mojego świata".
Nie wiem zresztą, czy miał przekonać. Raczej miał stanowić
ilustrację tego, w jaki sposób ta maksyma odzwierciedla się
w kontekście języków programowania. Sądzę, że -- mimo wszystkich
zarzutów, jakie wysnułeś, dotyczących rozwiązania wymyślonego
przez Kaya (i które nb nijak się mają do tego, co chciałem
zakomunikować) -- stanowi dobrą ilustrację.
> > Że język jest narzędziem do myślenia.
>
> Każdy jest. Dlatego ten Twój przykład niczego szczególnego
> w tym zakresie nie pokazał. Ot, dawno temu jakiś koleś
> napisał długi i skomplikowany program na zrobienie prostej
> rzeczy.
Skoro mowa o kontekście, może przeczytaj sobie, kim był
ów "jakiś koleś".
Hegel co prawda ponoć mawiał, że jedną rzeczą, której uczy
nas historia, jest to, że niczego się nie potrafimy z historii
nauczyć, jednak sądzę, że warto próbować przezwyciężać
te nasze ułomności -- w szczególności warto przyglądać się
temu, jak historycznie kształtowały się nasze sposoby rozumienia
obliczania i komputerów.
Oczywiście, można sobie "być mądrym" i przyjść na gotowe.
(I wyciągać z historii wciąż ten sam jeden wniosek)
> Dzisiaj proste rzeczy robi się krótkimi programami,
> dzięki czemu można podnieść poziom i łatwiej/szybciej myśleć
> o rzeczach bardziej skomplikowanych.
Skoro mowa o kontekście, może zamiast pokazywać przykład
w Mathematice, która stosunkowo niewiele różni się od ISWIMa z lat 60.,
może spróbowałbyś pokazać rozwiązanie tego zadania w nowoczesnym
języku, jakim jest C++, żebyśmy zobaczyli, jak naprawdę "dzisiaj
się robi proste rzeczy"?
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2017-08-24 01:25 -0700 |
| Message-ID | <6893a024-8cec-4a3f-9d41-5c7af61ba33b@googlegroups.com> |
| In reply to | #30419 |
> Mogę podać inny przykład, bliższy temu, o czym tutaj jest mowa.
>
> for (int i = 0; i < ticks_per_frame; i++) {
> for_each(in_seq(sectors), bind2nd(mem_fun(&Sector::update), 0.07));
> for_each(in_seq(portals), bind2nd(mem_fun(&Portal::update), 0.07));
> for_each(in_seq(ropes), bind2nd(mem_fun(&Rope::update), 0.07));
> }
Faktycznie koszmarek.
> Dla odmiany taki chociażby Python pozwoliłby wyrazić te konstrukcje
> np. tak:
>
> for instance in range(ticks_per_second):
> for sector in sectors:
> sector.update(0.07)
A gdzieś tak od pół dekady C++ pozwala tak:
for (Sector & s : sectors)
s.update(0.07);
W pewnym okresie była taka moda, że chyba wszystkie języki teraz mają coś podobnego.
> > Ale przecież operatory w Wolframie też można wypowiedzieć.
> > Np. operator indeksowania (to te podwójne nawiasy) nazywa się
> > Part.
>
> Dziwne. Nie przyszło mi do głowy, żeby [[_ ;; ;; _]] wymówić "Part".
Dziwne. Tak się właśnie ten operator nazywa. Podobnie, + nazywa się Plus. Itd.
> Prędzej wymówiłbym to jako "otwórz nawias kwadratowy, otwórz nawias
> kwadratowy, coś, spacja, średnik, średnik, spacja, średnik, średnik,
> spacja, coś, zamknij nawias kwadratowy, zamknij nawias kwadratowy".
Jasne. A wywołanie funkcji w SmallTalku wymawiasz "ttl, otwórz nawias okrągły, coś, zamknij nawias okrąły". Nie silmy się na takie trolowanie.
> Wątpliwości w dalszym ciągu wzbudza rola podkreślnika po argumencie
> po lewej stronie znaku ":=",
To jest wzorzec, który akceptuje cokolwiek. Czyli jest to definicja funkcji, która ma jeden argument dowolnego typu. Można wzorzec ograniczyć np tak:
oddsEvens[x_List] := ...
i wtedy jest to funkcja, która ma jeden argument typu List.
W tym przypadku można byłoby tak zrobić, ale wtedy taka funkcja działałaby tylko z listami, a akurat nie tylko listy mają taką strukturę, którą moglibyśmy chcieć w ten sposób uporządkować. Dlatego wolałem zostawić szerszy wzorzec.
http://reference.wolfram.com/language/ref/Blank.html
> oraz to, dlaczego do wyrażenia tożsamości
> użyto symbolu powszechnie używanego w informatyce w roli przypisania.
Bo to jest przypisanie. Tak się właśnie definiuje funkcje.
http://reference.wolfram.com/language/ref/SetDelayed.html
> Podwójnych podwójnych średników też nie lubię.
To napisz x[[1;;-1;;2]], wtedy będzie widać, że indeksowanie jest od 1 do końca. Ta spacja między średnikami to opuszczone -1.
> Zgadzam się.
> Gdybyśmy zresztą nawet nie dysponowali funkcją Parts, moglibyśmy
> ją sobie zdefiniować przy pomocy cons, car, cdr i rekurencji.
I to jest właśnie coś, czego nie lubię.
Indeksowanie jest naturalną operacją i dla komputera (w sensie: hardware) bardziej podstawową. Dlatego wolę, jeśli język ją wspiera bezpośrednio.
W ogóle, w naturze nie ma procesów rekurencyjnych. To jest na siłę wciskany ludziom kit, że rekurencja jest podstawą innych rzeczy. Dlatego języki promujące rekurencję jako podstawową konstrukcję są nienaturalne - zarówno w nauce, jak i w wykonaniu.
> Że języki, które znamy, warunkują sposób, w jaki myślimy,
Niezupełnie. Pierwszy język może to warunkować (i Wittgensteinowi chodziło o język naturalny). Natomiast później nasze myślenie może warunkować pozostałe wybory.
> Nie wiem zresztą, czy miał przekonać. Raczej miał stanowić
> ilustrację tego, w jaki sposób ta maksyma odzwierciedla się
> w kontekście języków programowania. Sądzę, że -- mimo wszystkich
> zarzutów, jakie wysnułeś, dotyczących rozwiązania wymyślonego
> przez Kaya (i które nb nijak się mają do tego, co chciałem
> zakomunikować) -- stanowi dobrą ilustrację.
Tak. Kiepski język prowadzi do kiepskiego myślenia i w rezultacie do kiepskich programów. :-)
> w szczególności warto przyglądać się
> temu, jak historycznie kształtowały się nasze sposoby rozumienia
> obliczania i komputerów.
Tak.
> Skoro mowa o kontekście, może zamiast pokazywać przykład
> w Mathematice, która stosunkowo niewiele różni się od ISWIMa z lat 60.,
> może spróbowałbyś pokazać rozwiązanie tego zadania w nowoczesnym
> języku, jakim jest C++, żebyśmy zobaczyli
Dlaczego? Ty nie pokazałeś przykładu w C++. :-)
--
Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-24 02:38 -0700 |
| Message-ID | <fae3b8a7-99fa-4843-9f11-12e807b46d8e@googlegroups.com> |
| In reply to | #30447 |
W dniu czwartek, 24 sierpnia 2017 10:25:26 UTC+2 użytkownik Maciej Sobczak napisał:
> > Mogę podać inny przykład, bliższy temu, o czym tutaj jest mowa.
> >
> > for (int i = 0; i < ticks_per_frame; i++) {
> > for_each(in_seq(sectors), bind2nd(mem_fun(&Sector::update), 0.07));
> > for_each(in_seq(portals), bind2nd(mem_fun(&Portal::update), 0.07));
> > for_each(in_seq(ropes), bind2nd(mem_fun(&Rope::update), 0.07));
> > }
>
> Faktycznie koszmarek.
Najgorsze jest to, że Stroustrup sam do czegoś takiego zachęcał.
> > Dla odmiany taki chociażby Python pozwoliłby wyrazić te konstrukcje
> > np. tak:
> >
> > for instance in range(ticks_per_second):
> > for sector in sectors:
> > sector.update(0.07)
>
> A gdzieś tak od pół dekady C++ pozwala tak:
>
> for (Sector & s : sectors)
> s.update(0.07);
Niestety, owe przeboje miały miejsce ponad dekadę temu.
Z tego co widziałem, w późniejszym kodzie zrobiłem sobie
coś takiego:
for_every(body , bodies)
(*body)->update(0.07);
gdzie for_every zdefiniowałem sobie jako następujące makro:
#define for_every(ITERATOR, COLLECTION) \
for(typeof(COLLECTION.begin()) ITERATOR = COLLECTION.begin(); \
ITERATOR != COLLECTION.end(); ++ITERATOR)
aż się dziwię, że byłem wtedy na tyle mądry, żeby nie napisać
#define in ,
Ale to był już okres schyłkowy, po którym dałem sobie spokój z C++em
(poza tym, że czasem go trochę używałem, jak potrzebowałem np. tablicy
haszującej albo innej kolekcji odmiennej od tablicy i ew. listy linkowanej)
> > > Ale przecież operatory w Wolframie też można wypowiedzieć.
> > > Np. operator indeksowania (to te podwójne nawiasy) nazywa się
> > > Part.
> >
> > Dziwne. Nie przyszło mi do głowy, żeby [[_ ;; ;; _]] wymówić "Part".
>
> Dziwne. Tak się właśnie ten operator nazywa. Podobnie, + nazywa się Plus. Itd.
Że + nazywa się Plus, to bym jeszcze może odgadnął.
> > Prędzej wymówiłbym to jako "otwórz nawias kwadratowy, otwórz nawias
> > kwadratowy, coś, spacja, średnik, średnik, spacja, średnik, średnik,
> > spacja, coś, zamknij nawias kwadratowy, zamknij nawias kwadratowy".
>
> Jasne. A wywołanie funkcji w SmallTalku wymawiasz "ttl, otwórz
> nawias okrągły, coś, zamknij nawias okrąły". Nie silmy się na
> takie trolowanie.
Akurat w Smalltalku masz zupełnie inną składnię, w której nie ma nawiasów.
Na matematyce uczono mnie, żeby f(x) czytać jako "f od x" albo
"wartośćć f w punkcie x". Nie uczono mnie, jak czytać [[_ ;; ;; _]]
> > Wątpliwości w dalszym ciągu wzbudza rola podkreślnika po argumencie
> > po lewej stronie znaku ":=",
>
> To jest wzorzec, który akceptuje cokolwiek. Czyli jest to definicja funkcji, która ma jeden argument dowolnego typu. Można wzorzec ograniczyć np tak:
Napisałem "wątpliwości", a nie "ciekawość" ;]
> oddsEvens[x_List] := ...
>
> i wtedy jest to funkcja, która ma jeden argument typu List.
> W tym przypadku można byłoby tak zrobić, ale wtedy taka funkcja działałaby tylko z listami, a akurat nie tylko listy mają taką strukturę, którą moglibyśmy chcieć w ten sposób uporządkować. Dlatego wolałem zostawić szerszy wzorzec.
>
> http://reference.wolfram.com/language/ref/Blank.html
>
> > oraz to, dlaczego do wyrażenia tożsamości
> > użyto symbolu powszechnie używanego w informatyce w roli przypisania.
>
> Bo to jest przypisanie. Tak się właśnie definiuje funkcje.
>
> http://reference.wolfram.com/language/ref/SetDelayed.html
Może w Mathematice, ale nie w matematyce. W matematyce
do określania tożsamości używa się symbolu =. Tego samego
symbolu używa się w ISWIM czy Haskell (w taki sam sposób).
> > Podwójnych podwójnych średników też nie lubię.
>
> To napisz x[[1;;-1;;2]], wtedy będzie widać, że indeksowanie jest od 1 do końca. Ta spacja między średnikami to opuszczone -1.
Włos na głowie jeży się coraz bardziej.
> > Zgadzam się.
> > Gdybyśmy zresztą nawet nie dysponowali funkcją Parts, moglibyśmy
> > ją sobie zdefiniować przy pomocy cons, car, cdr i rekurencji.
>
> I to jest właśnie coś, czego nie lubię.
> Indeksowanie jest naturalną operacją i dla komputera (w sensie: hardware) bardziej podstawową. Dlatego wolę, jeśli język ją wspiera bezpośrednio.
>
> W ogóle, w naturze nie ma procesów rekurencyjnych.
> To jest na siłę wciskany ludziom kit, że rekurencja jest
> podstawą innych rzeczy. Dlatego języki promujące rekurencję
> jako podstawową konstrukcję są nienaturalne - zarówno w nauce,
> jak i w wykonaniu.
To nie jest wciskanie ludziom kitu. Rekurencja w ogólności
jest prostsza do zrozumienia dla ludzi. Jeżeli spojrzeć na
rzeczy, które dzieją się w logice, to praktycznie wszystkie
podstawowe aksjomatyki mają charakter rekurencyjny, a bardzo
wiele dowodów jest indukcyjnych. Istnieje wiele zagadnień,
na przykład w kombinatoryce i teorii języków, które
mają bardzo naturalny sposób wyrazu przy pomocy rekurencji,
i których wyrażenie bez rekurencji w praktyce wymaga
"emulowania rekurencji" (np. tworzenia jawnych stosów).
Z rekurencją jest jednak taki problem, że o ile przy programowaniu
funkcyjnym jest prosta, o tyle analiza programów proceduralnych
używających rekurencję potrafi przyprawić o zawrót głowy.
> > Że języki, które znamy, warunkują sposób, w jaki myślimy,
>
> Niezupełnie. Pierwszy język może to warunkować
> (i Wittgensteinowi chodziło o język naturalny).
> Natomiast później nasze myślenie może warunkować pozostałe wybory.
Nie sądzę, żeby Wittgensteinowi chodziło ściśle o język naturalny.
Wittgenstein pisał "Traktat Logiczno-Filozoficzny" pod silnym wpływem
pism Fregego, który stworzył swój własny formalizm do precyzyjnego
zapisywania myśli (który finalnie ewoluował w coś, co dzisiaj znamy
jako rachunek predykatów). Ciekawostką nieujętą w komiksie jest to,
że Frege traktował swoją pracę jako realizację idei Leibniza zwanej
"calculus ratiocinator" albo "characteristica universalis", polegającej
na stworzeniu rachunku opisującego ludzkie myślenie. (Od innej strony
-- właśnie języka naturalnego -- do tej idei podszedł profesor Andrzej
Bogusławski z Uniwersytetu Warszawskiego, którego praca zainspirowała
Annę Wierzbicką do rozwinięcia systemu zwanego "Naturalnym Metajęzykiem
Semantycznym", będącego próbą ekstrakcji podstawowych "atomów znaczeniowych"
pozwalających opisać ludzkie rozumienie. Ot, ciekawostka)
Nota bene ta historia (tzn. o Fregem i Wittgensteinie) została bardzo
ładnie opowiedziana w komiksie pt. Logicomix, wydanym również w
języku polskim (zdaje się że wydawnictwo W.A.B.)
I oczywiście, ja się z Tobą zgadam, że nie jest tak, że "wszystko
jest językiem" -- że nasze doświadczenie jest w dużej mierze pozajęzykowe.
Ale trochę prawdy jest w tym Wittgensteinowskim stwierdzeniu.
> > Nie wiem zresztą, czy miał przekonać. Raczej miał stanowić
> > ilustrację tego, w jaki sposób ta maksyma odzwierciedla się
> > w kontekście języków programowania. Sądzę, że -- mimo wszystkich
> > zarzutów, jakie wysnułeś, dotyczących rozwiązania wymyślonego
> > przez Kaya (i które nb nijak się mają do tego, co chciałem
> > zakomunikować) -- stanowi dobrą ilustrację.
>
> Tak. Kiepski język prowadzi do kiepskiego myślenia
> i w rezultacie do kiepskich programów. :-)
Tak. To jest wniosek na poziomie ogólnym.
Z kolei nieznajomość historii prowadzi do tego,
że nie rozumiemy wartości tego, co posiadamy.
Allen Newell to naprawdę był niegłupi facet,
ale w czasach "po wynalezieniu Lispa" trudno
zrozumieć, jak ktoś mógł wpaść na coś tak pokracznego,
jak IPL.
> > Skoro mowa o kontekście, może zamiast pokazywać przykład
> > w Mathematice, która stosunkowo niewiele różni się od ISWIMa z lat 60.,
> > może spróbowałbyś pokazać rozwiązanie tego zadania w nowoczesnym
> > języku, jakim jest C++, żebyśmy zobaczyli
>
> Dlaczego? Ty nie pokazałeś przykładu w C++. :-)
:)
Ja swoje stanowisko dotyczące C++ staram się jasno artykułować.
W moim odczuciu to nie jest dobry język do formułowania myśli.
W jakimś sensie jest to wartościowy eksperyment dla tych, którzy
potrafią się uczyć na cudzych błędach, bo wydaje mi się, że
nie ma błędu, którego projektanci C++ by nie popełnili.
Jeżeli Twój stosunek do C++ jest równie sceptyczny, co mój,
to może ten apel powinienem skierować do entuzjastów tego
języka. Ktoś się podejmie?
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2017-08-24 03:20 -0700 |
| Message-ID | <049f5172-9176-48b7-b2dc-1f762f00f364@googlegroups.com> |
| In reply to | #30448 |
On Thursday, August 24, 2017 at 11:38:34 AM UTC+2, godek....@gmail.com wrote: > Ja swoje stanowisko dotyczące C++ staram się jasno artykułować. Każdy ma takie prawo. > W moim odczuciu to nie jest dobry język do formułowania myśli. W C++ przy pomocy odpowiednio zdefiniowanych klas, metod i funkcji, można utworzyć sobie "język", może nie do formułowania myśli, ale do zwięzłego rozwiązania problemu. > W jakimś sensie jest to wartościowy eksperyment dla tych, którzy > potrafią się uczyć na cudzych błędach, bo wydaje mi się, że > nie ma błędu, którego projektanci C++ by nie popełnili. C++ to asembler obiektowy. Dużo lepiej nie da się takiego języka zaprojektować. Ja czasami też bym chciał w C++ programować ciut dalej od warstwy sprzętowej. Ale cóż, jest jak jest. Projektanci C++ mogli zrobić dwa języki wywodzące się z C: jeden kompatybilny z C i dający się szybko skompilować na byle jakim sprzęcie, a drugi wysokopoziomowy, niekompatybilny i stawiający na wygodę programisty a nie na wygodę kompilatora, czy optymalizatora. To był ich jedyny poważny błąd że nie wywiedli z języka C dwóch standardów np. C++ i D++. > Jeżeli Twój stosunek do C++ jest równie sceptyczny, co mój, > to może ten apel powinienem skierować do entuzjastów tego > języka. Ktoś się podejmie? W wielu praktycznych zastosowaniach nie ma alternatywy. Pozdrawiam
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-24 04:02 -0700 |
| Message-ID | <f9f7b1ab-e7e3-453a-928a-85616ef67e25@googlegroups.com> |
| In reply to | #30449 |
W dniu czwartek, 24 sierpnia 2017 12:20:37 UTC+2 użytkownik M.M. napisał: > On Thursday, August 24, 2017 at 11:38:34 AM UTC+2, godek....@gmail.com wrote: > > Ja swoje stanowisko dotyczące C++ staram się jasno artykułować. > Każdy ma takie prawo. > > > > W moim odczuciu to nie jest dobry język do formułowania myśli. > W C++ przy pomocy odpowiednio zdefiniowanych klas, metod i > funkcji, można utworzyć sobie "język", może nie do formułowania > myśli, ale do zwięzłego rozwiązania problemu. W książce "Lekcja Programowania" był taki cytat: "Dobry programista poradzi sobie z ubogim językiem czy pokracznym systemem operacyjnym, ale nawet najlepsze środowisko programistyczne nie uratuje słabego programisty" i oczywiście w jakimś sensie jest to truizm. Tyle że może wytwarzać fałszywe przeświadczenie, że jakość języka programowania nie ma żadnego znaczenia, a jakość programisty ma wyłączne znaczenie. Wydaje mi się, że przykład Allena Newella i Alana Kaya pokazuje, że tak nie jest. Dobry programista poradzi sobie z C++ -- z czasem nauczy się omijać pułapki i obchodzić jego ograniczenia. Wytworzy "swój własny" sposób programowania w C++, w którym będzie się w stanie bez problemu poruszać. Wytworzy sobie swoją własną bibliotekę klas, metod i definicji, w którym będzie w stanie "rozwiązywać problemy" czy budować systemy. Jeśli będzie musiał. Tyle że moim zdaniem to nie jest dobra droga dla rozwoju przemysłu i programisty. Lepiej mieć wspólny język, którym możemy się bez problemu porozumieć -- tym bardziej, że często samo sformułowanie problemu jest już jego rozwiązaniem (albo jego kluczową częścią). > > W jakimś sensie jest to wartościowy eksperyment dla tych, którzy > > potrafią się uczyć na cudzych błędach, bo wydaje mi się, że > > nie ma błędu, którego projektanci C++ by nie popełnili. > C++ to asembler obiektowy. Dużo lepiej nie da się takiego > języka zaprojektować. Nie rozumiem. Co to jest "asembler obiektowy"? > Ja czasami też bym chciał w C++ programować > ciut dalej od warstwy sprzętowej. Ale cóż, jest jak jest. > > Projektanci C++ mogli zrobić dwa języki wywodzące się z C: Projektanci C++ nie są jedynymi osobami na świecie, które mogą robić języki programowania. (często mam wrażenie, że sukces C++ wziął się stąd, że było wiele osób, którym wydawało się, że jest inaczej) > > Jeżeli Twój stosunek do C++ jest równie sceptyczny, co mój, > > to może ten apel powinienem skierować do entuzjastów tego > > języka. Ktoś się podejmie? > W wielu praktycznych zastosowaniach nie ma alternatywy. Zawsze jest jakaś alternatywa. Czasem po prostu trzeba włożyć nieco pracy, żeby jej poszukać.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-08-24 06:42 -0700 |
| Message-ID | <910f005c-8ce0-459b-992c-3ab8cdfa2a54@googlegroups.com> |
| In reply to | #30450 |
W dniu czwartek, 24 sierpnia 2017 13:02:09 UTC+2 użytkownik godek....@gmail.com napisał: > W dniu czwartek, 24 sierpnia 2017 12:20:37 UTC+2 użytkownik M.M. napisał: > > C++ to asembler obiektowy. Dużo lepiej nie da się takiego > > języka zaprojektować. > > Nie rozumiem. Co to jest "asembler obiektowy"? > jak juz o makroassembler obiektowy ;c (mrugam bo jest to troche faktem i zarazem jest tym cos dosyc komicznego (bo m.in. faktycznie c++ jest na przyklad bardziej makroassemblerem niz c (o ktorym mozna by powiedziec moze na upartego ze jest jakims tam asemblerem ale o wiele mniej niz o c++, gdzie w tym gaszczu makr mozna sie niezle zamotac - gdzie w tedy juz nie motasz sie w asemblerze tylko w makrach ;c) [btw ostatnio pracuje nad swoim asemblerem "org-asm" jestem juz bardzo blisko do wrzucenia do sciagniecie pierwszej dzialajacej choc okrojonej wersji testowej, moze napisze o tym posta bo to okazalo sie pisanie tego dosyc ciekawe (zwlaszcza ze ladnie integruje sie z moim "siclem") tak naprawde z tej roboty zostalo mi zrobienie tlumaczenie etykiet na konkretne adresy (co chyab dzis bede robic) i spiecie roznych zrobionych juz z grubsza kawalkow w jedno et voila]
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2017-08-24 08:32 -0700 |
| Message-ID | <d5a271c0-c1f1-4d7a-bc2a-1f2310585ba1@googlegroups.com> |
| In reply to | #30450 |
On Thursday, August 24, 2017 at 1:02:09 PM UTC+2, godek....@gmail.com wrote: > W dniu czwartek, 24 sierpnia 2017 12:20:37 UTC+2 użytkownik M.M. napisał: > > On Thursday, August 24, 2017 at 11:38:34 AM UTC+2, godek....@gmail.com wrote: > > > Ja swoje stanowisko dotyczące C++ staram się jasno artykułować. > > Każdy ma takie prawo. > > > > > > > W moim odczuciu to nie jest dobry język do formułowania myśli. > > W C++ przy pomocy odpowiednio zdefiniowanych klas, metod i > > funkcji, można utworzyć sobie "język", może nie do formułowania > > myśli, ale do zwięzłego rozwiązania problemu. > > W książce "Lekcja Programowania" był taki cytat: > > "Dobry programista poradzi sobie z ubogim językiem > czy pokracznym systemem operacyjnym, ale nawet > najlepsze środowisko programistyczne nie uratuje > słabego programisty" > > i oczywiście w jakimś sensie jest to truizm. Tyle > że może wytwarzać fałszywe przeświadczenie, że > jakość języka programowania nie ma żadnego znaczenia, > a jakość programisty ma wyłączne znaczenie. > Wydaje mi się, że przykład Allena Newella i Alana Kaya > pokazuje, że tak nie jest. Rozumiem. Ale powiedz mi jeszcze, co myślisz o dobrych bibliotekach w C++, które w praktyce są dostępne od wielu lat. Czy te biblioteki nie czynią z C++ właśnie dobrego środowiska? W sumie o tym pisałem wcześniej, tylko nie użyłem słowa "biblioteka". Pewnie że nie zawsze chce mi się pisać w C++ wyrażeń regularnych, ale kiedyś miałem przypadek, w którym program słabo działał na gotowacach. Problemem była wydajność. Wyrzeźbiłem ręcznie jakiś podzbiór funkcjonalności regexp i mógł działać. C++ to język który daje dwie możliwości na raz - ręcznie rzeźbienie z którym poradzi sobie tylko dobry programista, albo dobre biblioteki przy pomocy których każdy programista stosunkowo szybko napisze działającą aplikację. > Dobry programista poradzi sobie z C++ -- z czasem nauczy > się omijać pułapki i obchodzić jego ograniczenia. Zastanawiam się, czy w moim przypadku nie było inaczej. Na początku, gdy po ludzku programowałem w C++, nie wpadałem zbyt często w zbyt duże pułapki. Potem przyszła Java, w Javie programowałem w bardzo podobny stylu jak w C++. Ale jeszcze potem napotykałem często na problemy wydajnościowe i musiałem wrócić do C++, tyle że w C++ już po ludzku nie programowałem - a to powodowało że czasami doprowadzałem aplikację do stanu w którym była mało podatna na rozwój - ale dzialała szybko na tanim sprzęcie. W zasadzie w pułapki wpadałem częściej jako doświadczony programista, jako początkujący nie prowokowałem sytuacji prowadzących w ślepe uliczki. > Wytworzy > "swój własny" sposób programowania w C++, w którym będzie > się w stanie bez problemu poruszać. Wytworzy sobie swoją > własną bibliotekę klas, metod i definicji, w którym będzie > w stanie "rozwiązywać problemy" czy budować systemy. Jeśli > będzie musiał. Tak, coś takiego mialem na myśli, albo po prostu weźmie QT. W co większych firmach mają swoje gotowe i bardzo dobre biblioteki. > Tyle że moim zdaniem to nie jest dobra droga dla rozwoju > przemysłu i programisty. Lepiej mieć wspólny język, którym > możemy się bez problemu porozumieć -- tym bardziej, że > często samo sformułowanie problemu jest już jego rozwiązaniem > (albo jego kluczową częścią). Że wspólny się zgadzam. Jestem za tym, aby rozbudować bibliotekę QT np. 10 razy pod względem funkcjonalności. Jestem też za tym, aby dodać wersje klas nastawione na wydajność, a nie na wygodę programisty. Potem niech komitet wykupi prawa do tej biblioteki i ustali bibliotekę QT jako bibliotekę standardową. A różni producenci niech dostarczają swoje implementacje. Pewnie że lepiej byłoby, gdyby wszyscy na Ziemie gadali w jednym języku, ale czy angielski jest lepszy od hiszpańskiego, to nie wiem. > > > W jakimś sensie jest to wartościowy eksperyment dla tych, którzy > > > potrafią się uczyć na cudzych błędach, bo wydaje mi się, że > > > nie ma błędu, którego projektanci C++ by nie popełnili. > > C++ to asembler obiektowy. Dużo lepiej nie da się takiego > > języka zaprojektować. > > Nie rozumiem. Co to jest "asembler obiektowy"? To powszechnie znana drwina z obiektowości-wskaźnikowej jaką wprowadza C++ :D > > Ja czasami też bym chciał w C++ programować > > ciut dalej od warstwy sprzętowej. Ale cóż, jest jak jest. > > > > Projektanci C++ mogli zrobić dwa języki wywodzące się z C: > > Projektanci C++ nie są jedynymi osobami na świecie, które > mogą robić języki programowania. (często mam wrażenie, że > sukces C++ wziął się stąd, że było wiele osób, którym wydawało > się, że jest inaczej) Jakiś język programowania kompilowany do C można napisać :) > > > > Jeżeli Twój stosunek do C++ jest równie sceptyczny, co mój, > > > to może ten apel powinienem skierować do entuzjastów tego > > > języka. Ktoś się podejmie? > > W wielu praktycznych zastosowaniach nie ma alternatywy. > > Zawsze jest jakaś alternatywa. Czasem po prostu trzeba włożyć > nieco pracy, żeby jej poszukać. Ale chodzi o sensowne alternatywy. Czasami chciałbym język javo-podobny, kompilowany, bez wywoływania metod po nazwie, bez automatycznego zwalniania pamięci, bez plików nagłówkowych, bez sieczki składniowej w szablonach, bez wskaźników... Ale ostatnio... mało używam malloc i new, wskaźników używam tylko w gorącej pętli, za to mam 3-4-krotnie zagnieżdżone szablony i edytor głupieje, zamiast mnie wspierać. Zobacz kod drzewa i testu które niedawno wrzuciłem, tam bezposrednio nie operuję na new i malloc, a wskaźniki są tylko w tych pętelkach, które są ważne dla wydajności. https://drzewa-czerwono-czarne.blogspot.com/p/kod-zrodowy-programu-testujacego.html https://drzewa-czerwono-czarne.blogspot.com/p/kod-zrodowy-c-drzewa-czerwono-czarne.html Używanie tego drzewa nie jest strasznie trudne, a daje bardzo dużą wydajność. Jak w haskelu i lispie używa się drzew czerwono-czarnych? Pozdrawiam
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-08-24 09:10 -0700 |
| Message-ID | <a2a69c80-d03c-4f1b-bae1-52ab331bb191@googlegroups.com> |
| In reply to | #30453 |
W dniu czwartek, 24 sierpnia 2017 17:32:35 UTC+2 użytkownik M.M. napisał: > > Jakiś język programowania kompilowany do C można napisać :) > org-asm juz prawi zrobiony tak ze niedlugo bede mogl robic wlasne kompilatory kompilujace do exe, firr nie chodzi na kompromisy ;c
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-08-24 12:24 -0700 |
| Message-ID | <4b738d2e-7a45-457b-b278-603fd0ac9367@googlegroups.com> |
| In reply to | #30454 |
W dniu czwartek, 24 sierpnia 2017 18:10:55 UTC+2 użytkownik fir napisał: > W dniu czwartek, 24 sierpnia 2017 17:32:35 UTC+2 użytkownik M.M. napisał: > > > > Jakiś język programowania kompilowany do C można napisać :) > > > > org-asm juz prawi zrobiony tak ze > niedlugo bede mogl robic wlasne kompilatory kompilujace do exe, firr nie chodzi na kompromisy ;c ok no i oto ultrapierwsza wersja mojego asemblera zfinalizowana minddetonator.htw.pl/organic.zip na razie mie kompilowac prawie wylacznie to .code push note call msvcrt.printf push 0 push str_zero push hello push 0 call user32.MessageBoxA push 0 call kernel32.ExitProcess .data note: "assembled" 32 "by" 32 "fir" 0 0 0 0 str_zero: 0 hello: "hello" 32 "asm" 32 "world" 32 "!" 0 0 0 0 0 0 tj mozna dodawac dowolne wywolania z dowolnej dll-ki ale nie wpisalem innych menemonickow poza podstawowym push i call ;c jutro pewnie dodam pare podstawowych instrukcji i jakakolwiek obsluge bledow etc, bo na razie jestem chyba zbyt zmeczony ale ok ze dziala, rozszerzenie tego to juz pikus w porownanu z dlubaniem by to wogole zaczelo dzialac
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | pl.comp.programming
csiph-web