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 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | "AK" <nobody@nowhere.net> |
|---|---|
| Date | 2017-08-25 06:37 +0200 |
| Message-ID | <ono9ju$em$1@node2.news.atman.pl> |
| In reply to | #30454 |
Użytkownik "fir" <profesor.fir@gmail.com> 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 ...ale na manowce... Chopie, kompilator kompilujacy C do asm/exe to pikus _Dobry_ kompilator C to kupe roboty (juz przez innych zrobionej!) i nie starczy Ci (biblioteki systemowe w stylu WinAPI) zycia ! PS: chcesz to ci dam biblioteke standardowa C w asm86. Napisana w 87r "z musu". Pomoze Ci odzyskac troche czasu na normalne zycia miast na takie "idee" jak ta Twoja ... PS0: jeszcze biblioteke BGI-zgodna dorzuce (88r) w czystym asm. Warto. Bedziemy Cie miec na dluzej z glowy :))) AK
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-08-25 01:13 -0700 |
| Message-ID | <6cba4df6-a49f-41db-b367-0da8c288bc2d@googlegroups.com> |
| In reply to | #30469 |
W dniu piątek, 25 sierpnia 2017 06:38:23 UTC+2 użytkownik AK napisał: > Użytkownik "fir" <profesor.fir@gmail.com> 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 > > ...ale na manowce... > > Chopie, kompilator kompilujacy C do asm/exe to pikus > _Dobry_ kompilator C to kupe roboty (juz przez innych zrobionej!) i nie starczy Ci > (biblioteki systemowe w stylu WinAPI) zycia ! > > PS: chcesz to ci dam biblioteke standardowa C w asm86. Napisana w 87r "z musu". > Pomoze Ci odzyskac troche czasu na normalne zycia miast na takie "idee" jak ta Twoja ... > PS0: jeszcze biblioteke BGI-zgodna dorzuce (88r) w czystym asm. Warto. Bedziemy Cie > miec na dluzej z glowy :))) > > AK biblioteka c jest mi nie potrzebna bo w moim asemblerze piszesz z marszu call msvcrt.cokolwiek i od razu masz wywolanie dowolnej funkcji do tego asembler napisalem praktycznie w tydzien (chyba nawet niecaly) [pmijam maly 300 linijkowy krytyczny kawalek kodu z naglowkami pe ktory napisalem i przetestowalem z pol roku czy rok temu..] (rozcykiwanie formatu exe jest mulace ale jak o juz zrobic to reszte da sie napisac w tydzien) esencjalny okrojony kompilator c pewnie tez daloby sie napisac w mniej niz miesiac - biblioteka jak wspomnielem nie jest potrzebna bo dzis masz dll-ki - calkiem dobry wynalazek
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-24 12:32 -0700 |
| Message-ID | <5cbdccbd-8717-444b-bc7d-284dae755701@googlegroups.com> |
| In reply to | #30453 |
W dniu czwartek, 24 sierpnia 2017 17:32:35 UTC+2 użytkownik M.M. napisał: > > 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? Zależy do czego. Rzecz z bibliotekami ma się tak, że ich użyteczność ogranicza się zazwyczaj do celu, w jakim zostały zrobione. Mówiąc inaczej, to są przetarte szlaki, i do rozwiązania typowych problemów z reguły pewnie wystarczą. Dlatego jeżeli C++ pomaga Ci w osiąganiu Twoich celów, to jak najbardziej korzystaj z niego. Ale stąd jest jeszcze daleka droga do powiedzenia, że jest "najlepszy", tak jak niektóre osoby by chciały. Być może w niektórych sytuacjach rzeczywiście będzie najlepszy, ale nie w jakimś absolutnym sensie, tylko w sensie przygodnym -- bo akurat nikt nie zrobił lepszych bibliotek dla innych języków. C++ jako abstrakcyjna notacja do komunikowania i zapisywania idei raczej się nie nadaje. Nie jest dobrym narzędziem dla umysłu (choć może jest dobrym narzędziem dla przemysłu) > 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ę. Dziś rozmawiałem o tym z kolegą z pracy. Opowiadał, że na pierwszym roku studiów miał za zadanie zrobienie kalkulatora GUI na Windows. Powiedział, że męczył się z tym zadaniem 3 dni w C++, podczas gdy jego kolega przyszedł i zrobił w C# w 3 godziny. Z C++ jest taki problem, że to nie jest język, tylko worek różnych ficzerów, które czasem do siebie pasują, a czasem nie. Jeżeli chcesz pisać w C++ tak jakby był Javą, to możesz to zrobić. Jeżeli chcesz w nim pisać tak, jakby to było C, to też możesz. Niektórzy powiedzą, że to dobrze, bo "język daje wolność". Jednak ja nie uważam, że to jest dobra wolność, bo jeżeli masz w zespole programistów z różnym backgroundem, to każdy będzie mógł pisać po swojemu. Dla odmiany, wydaje mi się, że języki, które narzucają na programistę więcej ograniczeń, jak np. Clojure, w którym wszystko jest niemutowalne, w rezultacie dają kod dużo lepszej jakości. Ładnie to ujął Runar Bjarnason w swojej prezentacji, której tytuł mówi już dość wiele: "Constraints Liberate, Liberties Constrain": https://www.youtube.com/watch?v=GqmsQeSzMdw > > 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. Pytanie, skąd się uczyłeś C++a > > 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. I jeżeli im mają i im działa, to dobrze. Ale trzeba mieć świadomość, że to jest w dużej mierze owoc tego, co się im jako firmie udało wyrzeźbić z tego kloca, jakim jest C++. A jeśli rzeźbili, to podejrzewam, że było dużo prób i błędów. Pytanie, ile te próby i błędy kosztowały. > > 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. Ja jestem całkowicie przeciwny. Jedyną rzeczą, jaka powinna się liczyć przy pisaniu kodu, jest wygoda programisty i łatwość refaktoryzacji. Jeżeli wszystko ma działać szybko, powinniśmy tworzyć dobre narzędzia optymalizujące. > Potem niech komitet wykupi prawa do tej biblioteki i > ustali bibliotekę QT jako bibliotekę standardową. To też jest problem, że jak chcesz mieć kontener, to musisz wybrać, czy to jest kontener z STL, czy Qt. Ale tego problemu nie da się rozwiązać, zachowując kompatybilność wsteczną. > 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. Też nie wiem. Języki etniczne ciężko jest ze sobą porównywać, bo wszystkie są raczej złożone i idiosynkratyczne. > > > > 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 Tyle że programiści często myślą, że to, że C++ daje dużą kontrolę nad sprzętem, to dobra rzecz. Myślę, że jest dokładnie odwrotnie. Im mniej intymnych szczegółów język może wiedzieć o systemie, na którym jest uruchamiany, tym lepszą robotę mogą odwalić narzędzia uruchomieniowe. > > > 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ć :) Nawet nie tylko można, ale i się pisze. Całą masę. Zresztą C++ też tak zaczynał. > > > > 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ć. Dlaczego miałbyś chcieć język bez automatycznego zwalniania pamięci? > 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? Nie wiem, nie używałem nigdy (i wolałbym nie używać), ani nie implementowałem. Ostatnio implementowałem dużo algorytmów grafowych czysto funkcyjnie, ale niestety powodowało to narzut złożoności algorytmicznej w stosunku do wersji korzystających z mutacji. Stąd teraz mam taką zabawę, że wymyślam metody automatycznej transformacji programów napisanych funkcyjnie w wydajniejsze programy stosujące mutację.
[toc] | [prev] | [next] | [standalone]
| From | Adam M <amorawski@magna-power.com> |
|---|---|
| Date | 2017-08-24 14:48 -0700 |
| Message-ID | <00aa6bd9-ab13-46a8-8b02-95d02b230b93@googlegroups.com> |
| In reply to | #30457 |
On Thursday, August 24, 2017 at 3:32:50 PM UTC-4, godek....@gmail.com wrote: > W dniu czwartek, 24 sierpnia 2017 17:32:35 UTC+2 użytkownik M.M. napisał: > > > > 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? > > Zależy do czego. Rzecz z bibliotekami ma się tak, > że ich użyteczność ogranicza się zazwyczaj do celu, > w jakim zostały zrobione. Mówiąc inaczej, to są przetarte > szlaki, i do rozwiązania typowych problemów z reguły > pewnie wystarczą. > Dlatego jeżeli C++ pomaga Ci w osiąganiu Twoich celów, > to jak najbardziej korzystaj z niego. > Ale stąd jest jeszcze daleka droga do powiedzenia, że jest > "najlepszy", tak jak niektóre osoby by chciały. Być może > w niektórych sytuacjach rzeczywiście będzie najlepszy, > ale nie w jakimś absolutnym sensie, tylko w sensie przygodnym > -- bo akurat nikt nie zrobił lepszych bibliotek dla innych > języków. C++ jako abstrakcyjna notacja do komunikowania > i zapisywania idei raczej się nie nadaje. Nie jest dobrym > narzędziem dla umysłu (choć może jest dobrym narzędziem > dla przemysłu) > > > 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ę. > > Dziś rozmawiałem o tym z kolegą z pracy. Opowiadał, że > na pierwszym roku studiów miał za zadanie zrobienie kalkulatora > GUI na Windows. Powiedział, że męczył się z tym zadaniem > 3 dni w C++, podczas gdy jego kolega przyszedł i zrobił w C# > w 3 godziny. > > Z C++ jest taki problem, że to nie jest język, tylko > worek różnych ficzerów, które czasem do siebie pasują, > a czasem nie. Jeżeli chcesz pisać w C++ tak jakby był > Javą, to możesz to zrobić. Jeżeli chcesz w nim pisać > tak, jakby to było C, to też możesz. Niektórzy powiedzą, > że to dobrze, bo "język daje wolność". Jednak ja nie > uważam, że to jest dobra wolność, bo jeżeli masz w zespole > programistów z różnym backgroundem, to każdy będzie mógł > pisać po swojemu. > > Dla odmiany, wydaje mi się, że języki, które narzucają > na programistę więcej ograniczeń, jak np. Clojure, w którym > wszystko jest niemutowalne, w rezultacie dają kod dużo > lepszej jakości. Ładnie to ujął Runar Bjarnason w swojej > prezentacji, której tytuł mówi już dość wiele: "Constraints > Liberate, Liberties Constrain": > https://www.youtube.com/watch?v=GqmsQeSzMdw > > > > 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. > > Pytanie, skąd się uczyłeś C++a > > > > 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. > > I jeżeli im mają i im działa, to dobrze. Ale trzeba mieć > świadomość, że to jest w dużej mierze owoc tego, co się im > jako firmie udało wyrzeźbić z tego kloca, jakim jest C++. > A jeśli rzeźbili, to podejrzewam, że było dużo prób i błędów. > Pytanie, ile te próby i błędy kosztowały. > > > > 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. > > Ja jestem całkowicie przeciwny. Jedyną rzeczą, jaka powinna się liczyć > przy pisaniu kodu, jest wygoda programisty i łatwość refaktoryzacji. > Jeżeli wszystko ma działać szybko, powinniśmy tworzyć dobre narzędzia > optymalizujące. > > > Potem niech komitet wykupi prawa do tej biblioteki i > > ustali bibliotekę QT jako bibliotekę standardową. > > > To też jest problem, że jak chcesz mieć kontener, to musisz > wybrać, czy to jest kontener z STL, czy Qt. Ale tego problemu > nie da się rozwiązać, zachowując kompatybilność wsteczną. > > > 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. > > Też nie wiem. Języki etniczne ciężko jest ze sobą porównywać, > bo wszystkie są raczej złożone i idiosynkratyczne. > > > > > > 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 > > Tyle że programiści często myślą, że to, że C++ daje dużą kontrolę > nad sprzętem, to dobra rzecz. > Myślę, że jest dokładnie odwrotnie. Im mniej intymnych szczegółów > język może wiedzieć o systemie, na którym jest uruchamiany, tym > lepszą robotę mogą odwalić narzędzia uruchomieniowe. Widzę że wszyscy tutaj wieszaja psy na tych biednych krzyżowcach - ale jak mówi przsłowie - Jak trwoga to do Boga - i tak jeśli musisz napisac program który musi rozmawiac ze sprzętem to masz tak naprawdę tylko trzy jezyki popularne do dyspozycji: Macro Assembler (nazwywanie tego językiem to dość duże naciągniecie - ale niech bedzie), C lub C++ (przez miłosierdzie nie wspominam tu ADY ;-) ) Osobiście uważam ze ignorowanie sprzetu prowadzi braku zrozumienia dlaczego oprogramowanie zachowuje sie w ten a nie inny sposób. To tak jak by lekarz powiedzial po co mam uczyc sie calej anatomii czlowieka jesli bede okulista. > > > > > 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ć :) > > Nawet nie tylko można, ale i się pisze. Całą masę. Zresztą > C++ też tak zaczynał. > > > > > > 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ć. > > Dlaczego miałbyś chcieć język bez automatycznego zwalniania pamięci? Jeśli kolega zadaje takie pytanie to tutaj jest link który może się przydać aby zrozumieć za automatyczne zwalnianie i odśmiecanie nie zawsze jest dobrym rozwiązaniem: https://www.dynatrace.com/resources/ebooks/javabook/impact-of-garbage-collection-on-performance/ > > > 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? > > Nie wiem, nie używałem nigdy (i wolałbym nie używać), ani nie implementowałem. > Ostatnio implementowałem dużo algorytmów grafowych czysto funkcyjnie, > ale niestety powodowało to narzut złożoności algorytmicznej w stosunku > do wersji korzystających z mutacji. > Stąd teraz mam taką zabawę, że wymyślam metody automatycznej > transformacji programów napisanych funkcyjnie w wydajniejsze > programy stosujące mutację.
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-24 15:23 -0700 |
| Message-ID | <1123a78c-4885-42fc-9abc-23c2ee5bebfc@googlegroups.com> |
| In reply to | #30458 |
W dniu czwartek, 24 sierpnia 2017 23:48:16 UTC+2 użytkownik Adam M napisał: > > > > Tyle że programiści często myślą, że to, że C++ daje dużą kontrolę > > nad sprzętem, to dobra rzecz. > > Myślę, że jest dokładnie odwrotnie. Im mniej intymnych szczegółów > > język może wiedzieć o systemie, na którym jest uruchamiany, tym > > lepszą robotę mogą odwalić narzędzia uruchomieniowe. > > Widzę że wszyscy tutaj wieszaja psy na tych biednych krzyżowcach nie "wieszają psy", tylko używają argumentów. > - ale jak mówi przsłowie - Jak trwoga to do Boga > - i tak jeśli musisz napisac program który musi rozmawiac > ze sprzętem to masz tak naprawdę tylko trzy jezyki popularne > do dyspozycji: Macro Assembler (nazwywanie tego językiem to > dość duże naciągniecie - ale niech bedzie), C lub C++ > (przez miłosierdzie nie wspominam tu ADY ;-) ) > > Osobiście uważam ze ignorowanie sprzetu prowadzi braku > zrozumienia dlaczego oprogramowanie zachowuje sie w ten > a nie inny sposób. często właśnie ignorowanie sprzętu jest zbawienne dla twojego programu. dlatego jak uruchamiasz program napisany w clojure czy erlangu na 16-rdzeniowym komputerze, to działa prawie 16 razy szybciej niż na 1-rdzeniowym. A w C++, o ile nie użyjesz jakichś bibliotek, to raczej nie masz co liczyć na tego rodzaju przyspieszenie (a jeśli nawet użyjesz, to pewnie i tak masz błędy) > Jeśli kolega zadaje takie pytanie to tutaj jest link który > może się przydać aby zrozumieć za automatyczne zwalnianie > i odśmiecanie nie zawsze jest dobrym rozwiązaniem: > https://www.dynatrace.com/resources/ebooks/javabook/impact-of-garbage-collection-on-performance/ problem z tą lekturą jest taki, że niewiele z niej wynika. proponuję zerknąć np, tutaj https://scholarship.rice.edu/bitstream/handle/1911/16127/8900220.PDF?sequence=1&isAllowed=y albo tu https://www.scss.tcd.ie/Lucy.Hederman/LHMScDissertation.pdf albo tu http://www.pipeline.com/~hbaker1/Share-Unify.html albo tu https://pdfs.semanticscholar.org/5fe3/c770c0dfbb05a16fe1b969678c8ee3b1a461.pdf zasadniczo możliwością, którą brak automatycznego odśmiecania przed Tobą otwiera, jest możliwość robienia wycieków pamięci.
[toc] | [prev] | [next] | [standalone]
| From | Adam M <amorawski@magna-power.com> |
|---|---|
| Date | 2017-08-25 07:04 -0700 |
| Message-ID | <0121d84a-c564-49b6-a4b9-99832bcdafbf@googlegroups.com> |
| In reply to | #30459 |
On Thursday, August 24, 2017 at 6:23:30 PM UTC-4, godek....@gmail.com wrote: > W dniu czwartek, 24 sierpnia 2017 23:48:16 UTC+2 użytkownik Adam M napisał: > > > > > > > Tyle że programiści często myślą, że to, że C++ daje dużą kontrolę > > > nad sprzętem, to dobra rzecz. > > > Myślę, że jest dokładnie odwrotnie. Im mniej intymnych szczegółów > > > język może wiedzieć o systemie, na którym jest uruchamiany, tym > > > lepszą robotę mogą odwalić narzędzia uruchomieniowe. > > > > Widzę że wszyscy tutaj wieszaja psy na tych biednych krzyżowcach > > nie "wieszają psy", tylko używają argumentów. > > > - ale jak mówi przsłowie - Jak trwoga to do Boga > > - i tak jeśli musisz napisac program który musi rozmawiac > > ze sprzętem to masz tak naprawdę tylko trzy jezyki popularne > > do dyspozycji: Macro Assembler (nazwywanie tego językiem to > > dość duże naciągniecie - ale niech bedzie), C lub C++ > > (przez miłosierdzie nie wspominam tu ADY ;-) ) > > > > Osobiście uważam ze ignorowanie sprzetu prowadzi braku > > zrozumienia dlaczego oprogramowanie zachowuje sie w ten > > a nie inny sposób. > > często właśnie ignorowanie sprzętu jest zbawienne dla twojego programu. > dlatego jak uruchamiasz program napisany w clojure czy erlangu > na 16-rdzeniowym komputerze, to działa prawie 16 razy szybciej > niż na 1-rdzeniowym. A w C++, o ile nie użyjesz jakichś bibliotek, > to raczej nie masz co liczyć na tego rodzaju przyspieszenie (a jeśli > nawet użyjesz, to pewnie i tak masz błędy) To jest przyklad tzw. magicznego myslenia - napisze program w Erlangu (to nic ze dziadowski algorytm i jest tylko jedno-watkowy) ale uruchomie go na 16-to rdzeniowym procesorze i to spowoduje magiczne ulepszenie algorytmu i 16-kroty przyrost predkosci. Czysta magia. Amdahl sie w grobie przewraca jak slyszy takie nonsensy na temat przyrostu predkosci na systemach wieloprocesorowych. Dodakowo ten biedny Erlang wie w jakis magiczny sposob jak ma to uruchomic na tym 16-rdzeniowym procesorze. > > > Jeśli kolega zadaje takie pytanie to tutaj jest link który > > może się przydać aby zrozumieć za automatyczne zwalnianie > > i odśmiecanie nie zawsze jest dobrym rozwiązaniem: > > https://www.dynatrace.com/resources/ebooks/javabook/impact-of-garbage-collection-on-performance/ > > problem z tą lekturą jest taki, że niewiele z niej wynika. > proponuję zerknąć np, tutaj > https://scholarship.rice.edu/bitstream/handle/1911/16127/8900220.PDF?sequence=1&isAllowed=y > albo tu > https://www.scss.tcd.ie/Lucy.Hederman/LHMScDissertation.pdf > albo tu > http://www.pipeline.com/~hbaker1/Share-Unify.html > albo tu > https://pdfs.semanticscholar.org/5fe3/c770c0dfbb05a16fe1b969678c8ee3b1a461.pdf > > zasadniczo możliwością, którą brak automatycznego odśmiecania > przed Tobą otwiera, jest możliwość robienia wycieków pamięci. Nie uwazam że ośmiecanie jest całkowicie złe - w wielu przpadkach daje bezpieczeństwo (zwłaszcza niedoświadczonym programistom). Moim nawi ększym problemem jest podejście wszystko albo nic do automatycznego zwalniania pamięci i odśmiecania - zabiera to wolnosc programiscie w decydowaniu jak program ma sie zachowywac. Podjeście ze alternatywą do automatycznego zwalniania i odśmiecania sa wycieki pamięci jest jak proponowanie wprowadzenia zakazu sprzedazy nozy - no bo przecież można kogoś zadzgać.
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-25 07:27 -0700 |
| Message-ID | <0983cdd7-e3f8-451c-8fd2-6de093e620ad@googlegroups.com> |
| In reply to | #30485 |
W dniu piątek, 25 sierpnia 2017 16:04:09 UTC+2 użytkownik Adam M napisał: > To jest przyklad tzw. magicznego myslenia - napisze program > w Erlangu (to nic ze dziadowski algorytm i jest tylko jedno-watkowy) > ale uruchomie go na 16-to rdzeniowym procesorze i to spowoduje > magiczne ulepszenie algorytmu i 16-kroty przyrost predkosci. To jest przykład tzw. programowania deklaratywnego, w którym mówisz komputerowi co chcesz mieć, a nie -- jak chcesz to uzyskać, dzięki czemu twórcy narzędzi uruchomieniowych mają dużo większą swobodę w interpretacji twojego programu. > > > Jeśli kolega zadaje takie pytanie to tutaj jest link który > > > może się przydać aby zrozumieć za automatyczne zwalnianie > > > i odśmiecanie nie zawsze jest dobrym rozwiązaniem: > > > https://www.dynatrace.com/resources/ebooks/javabook/impact-of-garbage-collection-on-performance/ > > > > problem z tą lekturą jest taki, że niewiele z niej wynika. > > proponuję zerknąć np, tutaj > > https://scholarship.rice.edu/bitstream/handle/1911/16127/8900220.PDF?sequence=1&isAllowed=y > > albo tu > > https://www.scss.tcd.ie/Lucy.Hederman/LHMScDissertation.pdf > > albo tu > > http://www.pipeline.com/~hbaker1/Share-Unify.html > > albo tu > > https://pdfs.semanticscholar.org/5fe3/c770c0dfbb05a16fe1b969678c8ee3b1a461.pdf > > > > zasadniczo możliwością, którą brak automatycznego odśmiecania > > przed Tobą otwiera, jest możliwość robienia wycieków pamięci. > > Nie uwazam że ośmiecanie jest całkowicie złe - w wielu ? przpadkach daje bezpieczeństwo (zwłaszcza niedoświadczonym > programistom). Moim nawi ększym problemem jest podejście > wszystko albo nic do automatycznego zwalniania pamięci > i odśmiecania - zabiera to wolnosc programiscie w decydowaniu > jak program ma sie zachowywac. Tzn. czy ma mieć wyciek pamięci, czy nie mieć?
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-25 07:40 -0700 |
| Message-ID | <f50a9ac3-eaf7-4a0f-8cc4-ffced29a6cc4@googlegroups.com> |
| In reply to | #30487 |
W dniu piątek, 25 sierpnia 2017 16:28:00 UTC+2 użytkownik godek....@gmail.com napisał: > W dniu piątek, 25 sierpnia 2017 16:04:09 UTC+2 użytkownik Adam M napisał: > > > Nie uwazam że ośmiecanie jest całkowicie złe - w wielu > ? przpadkach daje bezpieczeństwo (zwłaszcza niedoświadczonym > > programistom). Moim nawi ększym problemem jest podejście > > wszystko albo nic do automatycznego zwalniania pamięci > > i odśmiecania - zabiera to wolnosc programiscie w decydowaniu > > jak program ma sie zachowywac. > > Tzn. czy ma mieć wyciek pamięci, czy nie mieć? Język C również zawiera pewną formę odśmiecania pamięci: po wyjściu z funkcji pamięć zajmowana przez zmienne automatyczne (utworzone na stosie) jest zwalniana poprzez przesunięcie wskaźnika stosu. Dlaczego programistom C odbiera się wolność w swobodnym operowaniu wskaźnikiem stosu? Przecież wiedzą co robią, i mogliby sami sobie przesuwać tyle, ile trzeba.
[toc] | [prev] | [next] | [standalone]
| From | slawek <fake@fakeemail.com> |
|---|---|
| Date | 2017-08-25 20:04 +0200 |
| Message-ID | <almarsoft.8734031538825731504@news.v.pl> |
| In reply to | #30485 |
On Fri, 25 Aug 2017 07:04:07 -0700 (PDT), Adam M <amorawski@magna-power.com> wrote: > Amdahl sie w grobie przewraca Amdahl jest przereklamowany. Zasadniczy kłopot to czy program ma robić "to samo", czy raczej "to co chcemy". Im więcej wątków tym możemy chcieć więcej. A w takim przypadku prawo Amdahla jest nieprzydatne.
[toc] | [prev] | [next] | [standalone]
| From | Adam M <amorawski@magna-power.com> |
|---|---|
| Date | 2017-08-25 11:57 -0700 |
| Message-ID | <08f4c514-e99d-4720-b4b9-bb195601e10d@googlegroups.com> |
| In reply to | #30499 |
On Friday, August 25, 2017 at 2:04:20 PM UTC-4, slawek wrote: > On Fri, 25 Aug 2017 07:04:07 -0700 (PDT), Adam M > > Amdahl sie w grobie przewraca > > Amdahl jest przereklamowany. To jest bardzo mocne stwierdzenie. Wiekszosc programistow is projektantow systemo ktorzy zajmoja sie projektowaniem systemow wspolbieznych raczej zgadzaja sie z Amdahlem. Pewnie zdaniem szanownego kolego rowniez Pitagoras tez jest przereklamowany - o biednym Einsteinie to juz nawet nie warto wspominac. > > Zasadniczy kłopot to czy program ma robić "to samo", czy raczej "to > co chcemy". Im więcej wątków tym możemy chcieć więcej. A w takim > przypadku prawo Amdahla jest nieprzydatne. Czy mozna poprosic o dokladniejsze wyjasnienie co tez kolega mial na mysli - tak na prosty chlopski rozum ;-) - zawsze mnie uczono ze program ma robic "to samo" - to znaczy ze przy takich samym zestawie danych wejsciowych powinnismy sie spodziewac takich samych rezultatow wyjsciowych (nie odnosi sie to do sieci neuronowych ale nie o nich tutaj ddyskutujemy).
[toc] | [prev] | [next] | [standalone]
| From | slawek <fake@fakeemail.com> |
|---|---|
| Date | 2017-08-25 22:52 +0200 |
| Message-ID | <almarsoft.3920898204989408734@news.v.pl> |
| In reply to | #30501 |
On Fri, 25 Aug 2017 11:57:45 -0700 (PDT), Adam M <amorawski@magna-power.com> wrote: > On Friday, August 25, 2017 at 2:04:20 PM UTC-4, slawek wrote: > > On Fri, 25 Aug 2017 07:04:07 -0700 (PDT), Adam M > > Amdahl jest przereklamowany. > To jest bardzo mocne stwierdzenie. Wiem. > Czy mozna poprosic o dokladniejsze wyjasnienie > co tez kolega mial na mysli Wyjaśnię to dwa razy: raz na chłopski rozum, raz na przykładzie pewnego programu. Wyobraź sobie że jesteś gospodarzem. Masz jakieś 20 morgów i 4 parobków. Prawo Ahmadla i zdrowy rozsądek podpowiadają że 4000 parobków nie zapewni 1000 krotnego wzrostu tempa żniw. True. A co byłoby, gdybyś miał nie 20 morgów, ale 20 tysięcy morgów? Nadal "zrównoleglenie" prac przez zatrudnienie armii tysięcy parobków nie miałoby sensu? Innymi słowy: gdyby kurczowo trzymać się prawa Ahmadla to nie istniałaby takie firmy jak MS, Intel, Google, Samsung itd. - każda zatrudnia olbrzymie ilości ludzi, a przecież z prawa Ahmadla wynika że to niepotrzebne. A teraz drugi przykład. Program czyta liczbę 64 bitową, wykonuje obliczenia, wypisuje wynik jako ułamek dziesiętny. Czytania i wpisywania nie da się zrównoleglić. Obliczenie każdej cyfry wyniku jest całkowicie niezależne. Program oblicza wynik z dokładnością do 4 cyfr po przecinku. Zgodnie z prawem Ahmadla nie ma sensu używać zbyt wielu procesorów. To oczywiste. Ale jeżeli zamiast 4 cyfr będziesz chciał mieć wynik z 40 cyframi (albo z 40 tysiącami cyfr), to prawo Ahmadla nie podważa sensowności zastosowania odpowiednio większej liczby procesorów. Czyli prawo Ahmadla nie jest do stosowania w ciemno, bez sprawdzania założeń przy jakich je sformułowano. Przecież nie używasz twierdzenia Pitagorasa do obliczania objętości kuli. Podobna sytuacja była ze słynnym "640 kilobajtów wystarczy każdemu". To była prawda... Ale tylko przy założeniu że PC będzie służył tylko do tego co robiono na Spectrum itp. A to założenie okazało się fałszywe.
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2017-08-26 03:57 -0700 |
| Message-ID | <2a1e1d39-a281-411f-a964-bf0c9511bc62@googlegroups.com> |
| In reply to | #30503 |
On Friday, August 25, 2017 at 10:52:15 PM UTC+2, slawek wrote: > Innymi słowy: gdyby kurczowo trzymać się prawa Ahmadla to nie > istniałaby takie firmy jak MS, Intel, Google, Samsung itd. - każda > zatrudnia olbrzymie ilości ludzi, a przecież z prawa Ahmadla wynika > że to niepotrzebne. True. Gdyby kurczowo trzymać się teorii, to nic by nie osiągnięto. Przykładowo nigdy by nie napisano dobrego programu do gry w szachy, nie wspominając o grze GO. Obie gry mają zbyt wiele stanów do zapamiętania/przeszukania, więc algorytm mini-max, ani nawet alpha-beta, nie może być zastosowany. Programy jedynie grałyby w warcaby 32-polowe i to tylko na super-komputerach, bo tylko tam są wystarczająco duże dyski. Tak to już jest z teoriami, są zbyt wyidealizowane aby je dosłownie stosować do rzeczywistości. Pozdrawiam
[toc] | [prev] | [next] | [standalone]
| From | Adam M <amorawski@magna-power.com> |
|---|---|
| Date | 2017-08-26 10:32 -0700 |
| Message-ID | <6dda1d84-7c8d-4a58-a516-00b81209fbf0@googlegroups.com> |
| In reply to | #30503 |
On Friday, August 25, 2017 at 4:52:15 PM UTC-4, slawek wrote: > On Fri, 25 Aug 2017 11:57:45 -0700 (PDT), Adam M > > On Friday, August 25, 2017 at 2:04:20 PM UTC-4, slawek wrote: > > > On Fri, 25 Aug 2017 07:04:07 -0700 (PDT), Adam M > > > Amdahl jest przereklamowany. > > > To jest bardzo mocne stwierdzenie. > > Wiem. > > > Czy mozna poprosic o dokladniejsze wyjasnienie > > co tez kolega mial na mysli > > Wyjaśnię to dwa razy: raz na chłopski rozum, raz na przykładzie > pewnego programu. > > Wyobraź sobie że jesteś gospodarzem. Masz jakieś 20 morgów i 4 > parobków. Prawo Ahmadla i zdrowy rozsądek podpowiadają że 4000 > parobków nie zapewni 1000 krotnego wzrostu tempa żniw. True. > > A co byłoby, gdybyś miał nie 20 morgów, ale 20 tysięcy morgów? Nadal > "zrównoleglenie" prac przez zatrudnienie armii tysięcy parobków nie > miałoby sensu? > > Innymi słowy: gdyby kurczowo trzymać się prawa Ahmadla to nie > istniałaby takie firmy jak MS, Intel, Google, Samsung itd. - każda > zatrudnia olbrzymie ilości ludzi, a przecież z prawa Ahmadla wynika > że to niepotrzebne. > > A teraz drugi przykład. Program czyta liczbę 64 bitową, wykonuje > obliczenia, wypisuje wynik jako ułamek dziesiętny. Czytania i > wpisywania nie da się zrównoleglić. Obliczenie każdej cyfry wyniku > jest całkowicie niezależne. Program oblicza wynik z dokładnością do 4 > cyfr po przecinku. > > Zgodnie z prawem Ahmadla nie ma sensu używać zbyt wielu procesorów. > To oczywiste. > > Ale jeżeli zamiast 4 cyfr będziesz chciał mieć wynik z 40 cyframi > (albo z 40 tysiącami cyfr), to prawo Ahmadla nie podważa sensowności > zastosowania odpowiednio większej liczby procesorów. > > Czyli prawo Ahmadla nie jest do stosowania w ciemno, bez sprawdzania > założeń przy jakich je sformułowano. Przecież nie używasz twierdzenia > Pitagorasa do obliczania objętości kuli. > > Podobna sytuacja była ze słynnym "640 kilobajtów wystarczy każdemu". > To była prawda... Ale tylko przy założeniu że PC będzie służył tylko > do tego co robiono na Spectrum itp. A to założenie okazało się > fałszywe. To bardzo ładne stwierdzenia - niestety nie do końca prawdziwe: - po pierwsze kolega myli problem szczegółowy z problemami ogólnym biorac przyklad kolegi z morgami - tak to jest prawda ze do 20tysiecy potrzeba znacznie wiecej parobkow - ale problem tych 20morgow dalej jest tak samo trudny - miałem niestety doczyniania wielokrotnie z takimi programistami/projektantami systmow - z punktu wiedzy byli nie do pobicia - znali wiele języków perfekcyjnie, znali algorytmy, cala teoria w jednym palcu - jednym slowem tytan wiedzy - gdy przyszlo do rozwiazania problemu to padali jak muchy bo nie potrafili sie zdecydowac jak zabrac sie za problem (widzieli drzewa ale nie las) - co do ilosci procesorow - niestety jest bardzo wiele problemow ktore sa niestety typowo jedno-watkowe - w tym przypadku zastosowanie nawet miliona procesorow nic nie pomoze dopuki toria algorytmow nie znadzie lepszego algorytmu - ktory da sie zrownoleglic. Nie jestem fundamentalista w dziedzinie programowania - ale slepa wiara ze da sie oderwac programowanie od sprzetu, ze mozna poprawnie programowac bez zrozumienia jak sprzet na ktorym program bedzie sie wykonywal dziala prowadzi do bardzo poprawnie i elegancko napisanych i bardzo nieefektywnie dzialajacych programow. I nie mam tu na mysli 100 linikowego programu pokazujacego wyzszosc np Erlang czy Rust nad C++ ale zlozonego systemu zaierajacego setk tysiecy lini kodu. Np. eie zycze napisania w Pytonie czegos wiekszego jak 10-15tys lini kodu: a) jest to zadanie dla masochisty b) wiekszosc czasu zostanie spedzona na wyszukiwani bledow spowodowanych zlymi nazwami zmiennych lub nieporawnymi konwersjami pomiedzy typami (ktore rzekomo w Pytnie nie powinny stanowic problemu). c) przez litosc nie wspomne tu nawet o wielowatkowosci w Pytonie
[toc] | [prev] | [next] | [standalone]
| From | slawek <fake@fakeemail.com> |
|---|---|
| Date | 2017-08-27 10:18 +0200 |
| Message-ID | <almarsoft.5504829321148157803@news.v.pl> |
| In reply to | #30522 |
On Sat, 26 Aug 2017 10:32:20 -0700 (PDT), Adam M <amorawski@magna-power.com> wrote: > To bardzo ładne stwierdzenia > - niestety nie do końca prawdziwe Tłumacząc na zwykły język: "to prawda z którą nie potrafię się pogodzić". Przypominam - wyśmiewałeś tezę że prawo Ahmadla ma zastosowania ograniczone przez założenia przy jakich zostało sformułowane. > - co do ilosci procesorów > - niestety jest bardzo wiele problemow > ktore sa niestety typowo jedno-watkowe Istnieje więcej niż jeden problem którego rozwiązanie nie zyskuje na zwiększaniu liczby wątków. Istnieje więcej niż jeden problem dla którego zwiększanie liczby wątków jest dobre. Stąd logiczne wnioski: istnieje wiele problemów jednowątkowych; istnieje wiele problemów wielowątkowych. Co z tego wynika? Programowanie wielowątkowe jest potrzebne. To tak jak z gwoździkami i śrubkami. Ja twierdzę że niekiedy śruby są potrzebne. Ty upierasz się że wszystko da się zmontować przy pomocy gwoździ (programów jednowątkowych). Co ciekawsze: wydaje mi się (ale wymagałoby to głębszego rozplanowania), że wielowątkowość jest sensowniejszym sposobem modelowania, bo świat jako taki jest massive parallel.
[toc] | [prev] | [next] | [standalone]
| From | slawek <fake@fakeemail.com> |
|---|---|
| Date | 2017-08-25 23:04 +0200 |
| Message-ID | <almarsoft.2830232802918409874@news.v.pl> |
| In reply to | #30501 |
On Fri, 25 Aug 2017 11:57:45 -0700 (PDT), Adam M <amorawski@magna-power.com> wrote: > zawsze mnie uczono ze program ma robic= > "to samo" - to znaczy ze przy takich samym > zestawie danych wejsciowych pow= Problem z "to samo" jest głębszy niż Rów Mariański. Jeżeli np. program A przynosi takie same zyski producentowi jak program B, to z punktu widzenia księgowego robi "to samo". Jeżeli program A to gra i program B to gra, to oba mogą robić "to samo": zapewniają jakąś formę rozrywki. Choć jeden to np. M&M9 a drugi to Wiedźmin 3. (Albo Angry Birds) Jeżeli A to program sterujący lądownika Apollo, a B to program sterujący wahadłowcem, to w zasadzie robią "to samo" - sterują załogowym pojazdem kosmicznym. Itp. Itd.
[toc] | [prev] | [next] | [standalone]
| From | Wojciech Muła <wojtek.mula@gmail.com> |
|---|---|
| Date | 2017-08-25 13:22 -0700 |
| Message-ID | <177b3d56-d93a-425d-b71b-b6dc031164d2@googlegroups.com> |
| In reply to | #30499 |
On Friday, August 25, 2017 at 8:04:20 PM UTC+2, slawek wrote: > On Fri, 25 Aug 2017 07:04:07 -0700 (PDT), Adam M > <amorawski@magna-power.com> wrote: > > Amdahl sie w grobie przewraca > > Amdahl jest przereklamowany. > > Zasadniczy kłopot to czy program ma robić "to samo", czy raczej "to > co chcemy". Im więcej wątków tym możemy chcieć więcej. A w takim > przypadku prawo Amdahla jest nieprzydatne. Ja pierdzielę, to tak jakby ktoś napisał, że prawo Ohma jest nieprzydatne... Prawo Amdhala stwierdza wyłączenie, że istnieje górna granica przyspieszenia dla przetwarzania jakiegoś zadania na n procesach. w.
[toc] | [prev] | [next] | [standalone]
| From | slawek <fake@fakeemail.com> |
|---|---|
| Date | 2017-08-25 23:09 +0200 |
| Message-ID | <almarsoft.1935874101479063439@news.v.pl> |
| In reply to | #30502 |
On Fri, 25 Aug 2017 13:22:23 -0700 (PDT), Wojciech Muła<wojtek.mula@gmail.com> wrote: > Ja pierdzielę, to tak jakby ktoś napisał, > że prawo Ohma jest nieprzydatne... A co ci kiciuś pomoże prawo Ohma dla nadprzewodnika? Nawet dla półprzewodnika (zjawiska nieliniowe) prawo Ohma niespecjalnie wystarcza. I drobiazg: prawo Ohma jest empiryczne.
[toc] | [prev] | [next] | [standalone]
| From | "AK" <nobody@nowhere.net> |
|---|---|
| Date | 2017-08-25 07:08 +0200 |
| Message-ID | <onobf3$54c$1@gioia.aioe.org> |
| In reply to | #30458 |
Użytkownik "Adam M" <amorawski@magna-power.com> napisał: >> Dlaczego miałbyś chcieć język bez automatycznego zwalniania pamięci? > > Jeśli kolega zadaje takie pytanie to tutaj jest link który może się przydać aby zrozumieć > za automatyczne zwalnianie i odśmiecanie nie zawsze jest dobrym rozwiązaniem: https://www.dynatrace.com/resources/ebooks/javabook/impact-of-garbage-collection-on-performance/ Taaaa. Nie zawsze. W 1% programowania to faktycznie nie jest dobre rozwiazanie :) AK
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2017-08-24 16:12 -0700 |
| Message-ID | <a2290ed7-8c7a-4523-8181-5b3af762b142@googlegroups.com> |
| In reply to | #30457 |
W dniu czwartek, 24 sierpnia 2017 17:32:35 UTC+2 użytkownik M.M. napisał: > Zależy do czego. Rzecz z bibliotekami ma się tak, > że ich użyteczność ogranicza się zazwyczaj do celu, > w jakim zostały zrobione. Mówiąc inaczej, to są przetarte > szlaki, i do rozwiązania typowych problemów z reguły > pewnie wystarczą. No tak. Ale, o ile się nie mylę, podobnie jest w każdym języku. Część zadań rozwiązuje się przy pomocy środków jakie są dostarczane na poziomie języka, a drugą część na poziomie środków z bibliotek. Jeśli jest więcej na poziomie języka i język umożliwia bardziej zwartą składnię, to można odnieść wrażenie, że język jest lepszy do danego zadania. Lepszy w sensie że trzeba mniej kodu wpisać, zapewne jest. Poza tym to nie wiem... Napisałeś kilka postów powyżej, że niektóre języki nie są tylko językami programowania, ale językami myślenia. Jeśli się myśli algorytmami, to pewnie masz rację, chociaż... napiszę poniżej coś o pewnym programie do gry w szachy. Ale jeśli myśli się optymalnym rozwiązaniem danego problemu, to może język C++ jest językiem myślenia? > Dlatego jeżeli C++ pomaga Ci w osiąganiu Twoich celów, > to jak najbardziej korzystaj z niego. > Ale stąd jest jeszcze daleka droga do powiedzenia, że jest > "najlepszy", Bez kontekstu powiedzenie o czymś że jest najlepsze w ogóle nie ma sensu. > tak jak niektóre osoby by chciały. Być może > w niektórych sytuacjach rzeczywiście będzie najlepszy, > ale nie w jakimś absolutnym sensie, tylko w sensie przygodnym > -- bo akurat nikt nie zrobił lepszych bibliotek dla innych > języków. C++ jako abstrakcyjna notacja do komunikowania > i zapisywania idei raczej się nie nadaje. Pewnie że nie, bo do tego celu najlepszy jest metakod. Miałem napisać coś o programie do gry w szachy. Otóż był on napisany w C++ i procedura alpha-beta nie odbiegała dużo od meta-kodu - ale oczywiście metakodem nie była. > Nie jest dobrym > narzędziem dla umysłu (choć może jest dobrym narzędziem > dla przemysłu) Może zależy jaki umysł? Jeśli umysł jest nastawiony na optymalizację kodu, to może jest dobrym językiem dla umysłu? > Dziś rozmawiałem o tym z kolegą z pracy. Opowiadał, że > na pierwszym roku studiów miał za zadanie zrobienie kalkulatora > GUI na Windows. Powiedział, że męczył się z tym zadaniem > 3 dni w C++, podczas gdy jego kolega przyszedł i zrobił w C# > w 3 godziny. Jeden wygenerował kod GUI, a drugi wklepał - stąd różnice. Jeśli trzeba szybko napisać program, to C++ nie jest dobrym wyborem, poza sytuacją gdy do danego problemu są dobre biblioteki. Do C++ dziś jest wiele dobrych bibliotek, co powoduje, że C++ do wielu zadań jest w miarę dobrym wyborem nawet jeśli kryterium jest czas utworzenia programu. W QT też zdarzało mi się wyklikać w 3 dni dużą aplikację, której czas wykonania był szacowany na 1-2 miesiące. Fakt że to zdarzało się bardzo rzadko. > Z C++ jest taki problem, że to nie jest język, tylko > worek różnych ficzerów, które czasem do siebie pasują, > a czasem nie. Jeżeli chcesz pisać w C++ tak jakby był > Javą, to możesz to zrobić. Jeżeli chcesz w nim pisać > tak, jakby to było C, to też możesz. Niektórzy powiedzą, > że to dobrze, bo "język daje wolność". Jednak ja nie > uważam, że to jest dobra wolność, bo jeżeli masz w zespole > programistów z różnym backgroundem, to każdy będzie mógł > pisać po swojemu. Ja się wykłócałem i to w innych językach o sposób nazywania zmiennych, pól, metod i klas. I to nie o to że nazwa jest zbyt skrótowa i za mało mówi, czy zbyt rozwlekła i odciąga uwagę od istoty kodu, tylko o to, kiedy duża litera, kiedy znak podkreślenia. Każdy ma jakiś swój background. W zespole trzeba przyjąć jakieś zasady. Ja z reguły nastawiałem się solidny szkielet aplikacji, w ramach szkieletu były moduły, a moduł oznaczał cokolwiek. W ramach modułu była duża wolność, ryzyko wywalenia całego modułu było akceptowalne, natomiast zazębianie się modułu z całą aplikacją było według bardzo rygorystycznych zasad. > Dla odmiany, wydaje mi się, że języki, które narzucają > na programistę więcej ograniczeń, jak np. Clojure, w którym > wszystko jest niemutowalne, w rezultacie dają kod dużo > lepszej jakości. Ładnie to ujął Runar Bjarnason w swojej > prezentacji, której tytuł mówi już dość wiele: "Constraints > Liberate, Liberties Constrain": > https://www.youtube.com/watch?v=GqmsQeSzMdw Żałuję teraz że nie znam tego języka, byśmy porozmawiali. > Pytanie, skąd się uczyłeś C++a Z literatury. > I jeżeli im mają i im działa, to dobrze. Ale trzeba mieć > świadomość, że to jest w dużej mierze owoc tego, co się im > jako firmie udało wyrzeźbić z tego kloca, jakim jest C++. > A jeśli rzeźbili, to podejrzewam, że było dużo prób i błędów. > Pytanie, ile te próby i błędy kosztowały. Ja się zgadzam, że C++, za wyjątkiem sytuacji gdy już są gotowe biblioteki, nie jest najlepszym języku do szybkiego wykonania aplikacji. Natomiast jak "rzeźbiłem z tego kloca" aplikację która obsługiwała bazę ram 1TB, to w C++ chociaż mogłem wyrzeźbić, a we wszelkich innych językach/narzędziach by padło przy 100GB, a może przy 20GB. W rozwiązaniu pilotażowym opartym o PHP + JS + PgSQL nawet nie ruszyło. > Ja jestem całkowicie przeciwny. Jedyną rzeczą, jaka powinna się liczyć > przy pisaniu kodu, jest wygoda programisty i łatwość refaktoryzacji. > Jeżeli wszystko ma działać szybko, powinniśmy tworzyć dobre narzędzia > optymalizujące. Mi też tak mówili wiele razy, wiele osób, w wielu sytuacjach. A potem narzędzi optymalizacyjnych nie było i dupa. Pewnie że ja też bym chciał programować tylko w Javie, bo się zakochałem w tym języku. Gdy wydajność nie jest ważna, to powinno się sięgać po takie języki. > To też jest problem, że jak chcesz mieć kontener, to musisz > wybrać, czy to jest kontener z STL, czy Qt. Ale tego problemu > nie da się rozwiązać, zachowując kompatybilność wsteczną. Gdy wydajność nie jest ważna, to się bierze pierwszy z brzegu i potem konwertuje, jeśli np. biblioteka gui nie akceptuje std::vector. Gdy jest ważna, to szablon się parametryzuje szablonem sparametryzowanym przez jeszcze trzy inne szablony i sprawdza każdy wariant - i mamy typową sieczkę optymalizacyjną, a nie kod podatny na refaktoryzację i rozwój. > Też nie wiem. Języki etniczne ciężko jest ze sobą porównywać, > bo wszystkie są raczej złożone i idiosynkratyczne. hmmm > Tyle że programiści często myślą, że to, że C++ daje dużą kontrolę > nad sprzętem, to dobra rzecz. > Myślę, że jest dokładnie odwrotnie. Im mniej intymnych szczegółów > język może wiedzieć o systemie, na którym jest uruchamiany, tym > lepszą robotę mogą odwalić narzędzia uruchomieniowe. Taka jest teoria. W praktyce byśmy musieli mieć sztuczną inteligencję do kompilowania kodu w językach wysokiego poziomu. Kompilator musiałby wiedzieć jakiej puli algorytmów może użyć aby zapewnić poprawne wyjście dla wszystkich dozwolonych wejść. > Nawet nie tylko można, ale i się pisze. Całą masę. Zresztą > C++ też tak zaczynał. No tak. > Dlaczego miałbyś chcieć język bez automatycznego zwalniania pamięci? Dlatego że wierzę, że dla takiego języka i sposobu programowania jaki taki język pociąga za sobą, można w praktyce jeszcze napisać kompilator generujący bardzo efektywny kod. A programowanie byłoby wygodniejsze niż w C++. > Nie wiem, nie używałem nigdy (i wolałbym nie używać), ani nie implementowałem. Ok. > Ostatnio implementowałem dużo algorytmów grafowych czysto funkcyjnie, > ale niestety powodowało to narzut złożoności algorytmicznej w stosunku > do wersji korzystających z mutacji. > Stąd teraz mam taką zabawę, że wymyślam metody automatycznej > transformacji programów napisanych funkcyjnie w wydajniejsze > programy stosujące mutację. Nie wiem co to jest mutacja. Jak to się zachowuje po optymalizacji, spadła złożoność algorytmiczna? Jakby to działało, gdybyś od razu w C++ lub Javie napisał? Pozdrawiam
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2017-08-25 02:35 -0700 |
| Message-ID | <4d444712-a009-492c-8ff0-dea6f2647c63@googlegroups.com> |
| In reply to | #30461 |
W dniu piątek, 25 sierpnia 2017 01:12:43 UTC+2 użytkownik M.M. napisał:
> W dniu czwartek, 24 sierpnia 2017 17:32:35 UTC+2 użytkownik M.M. napisał:
>
> > Zależy do czego. Rzecz z bibliotekami ma się tak,
> > że ich użyteczność ogranicza się zazwyczaj do celu,
> > w jakim zostały zrobione. Mówiąc inaczej, to są przetarte
> > szlaki, i do rozwiązania typowych problemów z reguły
> > pewnie wystarczą.
> No tak. Ale, o ile się nie mylę, podobnie jest w każdym języku.
> Część zadań rozwiązuje się przy pomocy środków jakie są
> dostarczane na poziomie języka, a drugą część na poziomie
> środków z bibliotek. Jeśli jest więcej na poziomie
> języka i język umożliwia bardziej zwartą składnię, to
> można odnieść wrażenie, że język jest lepszy do danego
> zadania. Lepszy w sensie że trzeba mniej kodu wpisać,
> zapewne jest. Poza tym to nie wiem... Napisałeś kilka
> postów powyżej, że niektóre języki nie są tylko językami
> programowania, ale językami myślenia. Jeśli się myśli
> algorytmami, to pewnie masz rację, chociaż... napiszę poniżej
> coś o pewnym programie do gry w szachy. Ale jeśli myśli się
> optymalnym rozwiązaniem danego problemu, to może język
> C++ jest językiem myślenia?
Nie wiem. Ja nie myślę algorytmami, tylko relacjami
między pojęciami. W moim odczuciu myślenie, którego
uczy C++, jest raczej dość kulawe, co bierze się stąd,
że jest w nim dużo niespójności i przypadkowych decyzji.
W rezultacie tego rodzaju wzorzec może podszeptywać
programistom, że "z niespójnościami da się żyć" i że
"przypadkowe decyzje są nie do uniknięcia". Nawet jeśli
z niespójnościami da się żyć, a przypadkowe decyzje są
nie do uniknięcia, wydaje mi się, że to nie jest dobra
nauka.
> > Dlatego jeżeli C++ pomaga Ci w osiąganiu Twoich celów,
> > to jak najbardziej korzystaj z niego.
> > Ale stąd jest jeszcze daleka droga do powiedzenia, że jest
> > "najlepszy",
> Bez kontekstu powiedzenie o czymś że jest najlepsze w ogóle
> nie ma sensu.
Zgadzam się.
> > tak jak niektóre osoby by chciały. Być może
> > w niektórych sytuacjach rzeczywiście będzie najlepszy,
> > ale nie w jakimś absolutnym sensie, tylko w sensie przygodnym
> > -- bo akurat nikt nie zrobił lepszych bibliotek dla innych
> > języków. C++ jako abstrakcyjna notacja do komunikowania
> > i zapisywania idei raczej się nie nadaje.
> Pewnie że nie, bo do tego celu najlepszy jest metakod.
Nie znam takiego słowa. Może masz na myśli to, co określa
się mianem pseudokodu?
Ale skoro tak, to dlaczego ów "metakod" nie miałby być
językiem, który od razu można wykonać na komputerze?
> > Nie jest dobrym
> > narzędziem dla umysłu (choć może jest dobrym narzędziem
> > dla przemysłu)
> Może zależy jaki umysł? Jeśli umysł jest nastawiony na
> optymalizację kodu, to może jest dobrym językiem dla
> umysłu?
Wrócę do tego wątku mniej więcej za miesiąc, proszę
o cierpliwość :)
> > Z C++ jest taki problem, że to nie jest język, tylko
> > worek różnych ficzerów, które czasem do siebie pasują,
> > a czasem nie. Jeżeli chcesz pisać w C++ tak jakby był
> > Javą, to możesz to zrobić. Jeżeli chcesz w nim pisać
> > tak, jakby to było C, to też możesz. Niektórzy powiedzą,
> > że to dobrze, bo "język daje wolność". Jednak ja nie
> > uważam, że to jest dobra wolność, bo jeżeli masz w zespole
> > programistów z różnym backgroundem, to każdy będzie mógł
> > pisać po swojemu.
>
> Ja się wykłócałem i to w innych językach o sposób nazywania
> zmiennych, pól, metod i klas. I to nie o to że nazwa jest
> zbyt skrótowa i za mało mówi, czy zbyt rozwlekła i odciąga
> uwagę od istoty kodu, tylko o to, kiedy duża litera, kiedy
> znak podkreślenia. Każdy ma jakiś swój background. W zespole
> trzeba przyjąć jakieś zasady.
Jasne, zdecydowanie tak.
To jest też powód, dla którego cenię Pythona -- bo daje wskazówki
odnośnie tego, jak należy w nim programować. Z tego też względu
wolę Scheme'a, bo nie stawia dziwacznych ograniczeń na nazewnictwo
zmiennych.
> > Dla odmiany, wydaje mi się, że języki, które narzucają
> > na programistę więcej ograniczeń, jak np. Clojure, w którym
> > wszystko jest niemutowalne, w rezultacie dają kod dużo
> > lepszej jakości. Ładnie to ujął Runar Bjarnason w swojej
> > prezentacji, której tytuł mówi już dość wiele: "Constraints
> > Liberate, Liberties Constrain":
> > https://www.youtube.com/watch?v=GqmsQeSzMdw
> Żałuję teraz że nie znam tego języka, byśmy porozmawiali.
Masz na myśli Scalę, czy angielski? :)
Jeżeli idzie o Scalę, to przyznam, że nie do końca rozumiem
fenomen, ale chyba zamysł był taki, żeby ułatwić programistom
Javy wejście w świat programowania funkcyjnego.
> > Pytanie, skąd się uczyłeś C++a
> Z literatury.
No jo. Tyle że książek jest dużo.
Jak wspominałem, ja się uczyłem z "Język C++" Stroustrupa.
To może nie być zbyt dobra książka do nauki.
> > I jeżeli im mają i im działa, to dobrze. Ale trzeba mieć
> > świadomość, że to jest w dużej mierze owoc tego, co się im
> > jako firmie udało wyrzeźbić z tego kloca, jakim jest C++.
> > A jeśli rzeźbili, to podejrzewam, że było dużo prób i błędów.
> > Pytanie, ile te próby i błędy kosztowały.
>
> Ja się zgadzam, że C++, za wyjątkiem sytuacji gdy już są
> gotowe biblioteki, nie jest najlepszym języku do szybkiego
> wykonania aplikacji. Natomiast jak "rzeźbiłem z tego kloca"
> aplikację która obsługiwała bazę ram 1TB, to w C++ chociaż
> mogłem wyrzeźbić, a we wszelkich innych językach/narzędziach
> by padło przy 100GB, a może przy 20GB. W rozwiązaniu
> pilotażowym opartym o PHP + JS + PgSQL nawet nie ruszyło.
Nie wiem, czy we wszystkich. Myślę że Clojure albo Scala
mogłyby spokojnie pociągnąć. Kiedyś też zdarzało mi się przetwarzać
wielkie zbiory danych w Perlu, i radził sobie doskonale.
> > Ja jestem całkowicie przeciwny. Jedyną rzeczą, jaka powinna się liczyć
> > przy pisaniu kodu, jest wygoda programisty i łatwość refaktoryzacji.
> > Jeżeli wszystko ma działać szybko, powinniśmy tworzyć dobre narzędzia
> > optymalizujące.
> Mi też tak mówili wiele razy, wiele osób, w wielu sytuacjach.
> A potem narzędzi optymalizacyjnych nie było i dupa.
Zgadzam się, że to jest w praktyce wielki problem, dlatego
moim zdaniem powinniśmy się skupić na opracowywaniu tego rodzaju
narzędzi. Pewnie "linia najmniejszego oporu" przebiega przez ręczne
optymalizowanie aplikacji w C++, ale z punktu widzenia "rozwoju ludzkości"
bardziej racjonalne wydaje się wykonanie optymalizacji tylko raz
dla wszystkich programów, a nie tyle razy, ile jest programów.
Ale zgodzę się, że z dobrymi narzędziami jest taki problem,
że albo ich nie ma, albo nie wiemy o tym, że są.
> Pewnie że
> ja też bym chciał programować tylko w Javie, bo się zakochałem w
> tym języku. Gdy wydajność nie jest ważna, to powinno się sięgać
> po takie języki.
Nie rozumiem jak można się zakochać w Javie :)
> > To też jest problem, że jak chcesz mieć kontener, to musisz
> > wybrać, czy to jest kontener z STL, czy Qt. Ale tego problemu
> > nie da się rozwiązać, zachowując kompatybilność wsteczną.
> Gdy wydajność nie jest ważna, to się bierze pierwszy z
> brzegu i potem konwertuje, jeśli np. biblioteka gui nie
> akceptuje std::vector. Gdy jest ważna, to szablon się
> parametryzuje szablonem sparametryzowanym przez jeszcze trzy
> inne szablony i sprawdza każdy wariant - i mamy typową
> sieczkę optymalizacyjną, a nie kod podatny na refaktoryzację i
> rozwój.
To jest akurat najprostsza rzecz: jeżeli masz program w C++ korzystający
z STLowych kolekcji, to łatwo powinno być napisać np. algorytm genetyczny,
który zadany zbiór przypadków testowych bada na różnych konfiguracjach
kolekcji.
> > Tyle że programiści często myślą, że to, że C++ daje dużą kontrolę
> > nad sprzętem, to dobra rzecz.
> > Myślę, że jest dokładnie odwrotnie. Im mniej intymnych szczegółów
> > język może wiedzieć o systemie, na którym jest uruchamiany, tym
> > lepszą robotę mogą odwalić narzędzia uruchomieniowe.
> Taka jest teoria. W praktyce byśmy musieli mieć sztuczną inteligencję
> do kompilowania kodu w językach wysokiego poziomu. Kompilator
> musiałby wiedzieć jakiej puli algorytmów może użyć aby zapewnić
> poprawne wyjście dla wszystkich dozwolonych wejść.
Tak.
> > Dlaczego miałbyś chcieć język bez automatycznego zwalniania pamięci?
> Dlatego że wierzę, że dla takiego języka i sposobu programowania
> jaki taki język pociąga za sobą, można w praktyce jeszcze napisać
> kompilator generujący bardzo efektywny kod. A programowanie byłoby
> wygodniejsze niż w C++.
Naprawdę, jedyne, co brak automatycznego zwalniania pamięci umożliwia,
to pisanie programów z wyciekami pamięci.
> > Nie wiem, nie używałem nigdy (i wolałbym nie używać), ani nie implementowałem.
> Ok.
>
> > Ostatnio implementowałem dużo algorytmów grafowych czysto funkcyjnie,
> > ale niestety powodowało to narzut złożoności algorytmicznej w stosunku
> > do wersji korzystających z mutacji.
> > Stąd teraz mam taką zabawę, że wymyślam metody automatycznej
> > transformacji programów napisanych funkcyjnie w wydajniejsze
> > programy stosujące mutację.
> Nie wiem co to jest mutacja. Jak to się zachowuje po optymalizacji,
> spadła złożoność algorytmiczna?
Mutacja, czyli modyfikacja istniejącego obiektu.
Na przykład takie coś, co wyszło w rozmowie z AK, w Pythonie:
a = [1,2,3]
b = [4,5,6]
a += b
w trzeciej linijce tablica "a" została zmodyfikowana, czy też
doszło do "mutacji". faktycznie może "mutacja" nie ma w języku polskim
najlepszej konotacji, ale często mówi się np. o obiektach albo zmiennych
niemutowalnych.
przykład, którym na razie się zajmowałem, to haskellowy wariant
quicksorta:
qsort [] = []
qsort (pivot:rest) = (qsort below) ++ [pivot] ++ (qsort above)
where below = [x | x <- rest, x < pivot]
above = [x | x <- rest, x >= pivot]
problem z tym, że ta funkcja nie jest "quick", i że -- tak jak
oryginalny Quicksort Hoare'a działał podstawiając elementy tablicy
w miejscu (czyli mutując tablicę), tak ten generuje bardzo dużo
śmieci. Ale istotę jego działania widać jak na dłoni.
> Jakby to działało, gdybyś od razu w C++ lub Javie napisał?
Za mniej więcej miesiąc podeślę, to będziesz mógł sam ocenić,
ale podejrzewam, że raczej bym czegoś takiego nie napisał w C++
ani w Javie
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | pl.comp.programming
csiph-web