Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #89514 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2023-03-07 15:38 -0600 |
| Last post | 2023-04-06 00:42 -0700 |
| Articles | 20 on this page of 146 — 22 participants |
Back to article view | Back to comp.lang.c++
"C++ on the Move" by Darryl K. Taft Lynn McGuire <lynnmcguire5@gmail.com> - 2023-03-07 15:38 -0600
Re: "C++ on the Move" by Darryl K. Taft legalize+jeeves@mail.xmission.com (Richard) - 2023-03-07 22:08 +0000
Re: "C++ on the Move" by Darryl K. Taft Lynn McGuire <lynnmcguire5@gmail.com> - 2023-03-07 16:25 -0600
Re: "C++ on the Move" by Darryl K. Taft legalize+jeeves@mail.xmission.com (Richard) - 2023-03-07 23:10 +0000
Re: "C++ on the Move" by Darryl K. Taft Paavo Helde <eesnimi@osa.pri.ee> - 2023-03-08 08:40 +0200
Re: "C++ on the Move" by Darryl K. Taft Lynn McGuire <lynnmcguire5@gmail.com> - 2023-04-05 19:30 -0500
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-07 23:21 -0800
Re: "C++ on the Move" by Darryl K. Taft scott@slp53.sl.home (Scott Lurndal) - 2023-03-08 16:10 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-08 19:47 +0100
Re: "C++ on the Move" by Darryl K. Taft Michael S <already5chosen@yahoo.com> - 2023-03-08 11:21 -0800
Re: "C++ on the Move" by Darryl K. Taft scott@slp53.sl.home (Scott Lurndal) - 2023-03-08 19:49 +0000
Re: "C++ on the Move" by Darryl K. Taft Michael S <already5chosen@yahoo.com> - 2023-03-08 12:08 -0800
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-08 09:52 -0800
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-08 10:18 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-08 20:45 +0100
Re: "C++ on the Move" by Darryl K. Taft "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-03-08 19:20 +0100
Re: "C++ on the Move" by Darryl K. Taft James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-03-08 14:10 -0500
Re: "C++ on the Move" by Darryl K. Taft "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-03-08 22:34 +0100
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-08 14:29 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-09 00:59 +0100
Re: "C++ on the Move" by Darryl K. Taft James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-03-08 18:11 -0500
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-08 12:28 -0800
Re: "C++ on the Move" by Darryl K. Taft Michael S <already5chosen@yahoo.com> - 2023-03-08 12:48 -0800
Re: "C++ on the Move" by Darryl K. Taft "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-03-08 22:40 +0100
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-09 01:12 +0100
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-08 16:27 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-09 13:52 +0100
Re: "C++ on the Move" by Darryl K. Taft Michael S <already5chosen@yahoo.com> - 2023-03-09 12:47 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-09 01:08 +0100
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-09 02:08 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-09 14:06 +0100
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-09 07:14 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-09 20:32 +0100
Re: "C++ on the Move" by Darryl K. Taft Michael S <already5chosen@yahoo.com> - 2023-03-09 12:42 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 00:30 +0100
Re: "C++ on the Move" by Darryl K. Taft scott@slp53.sl.home (Scott Lurndal) - 2023-03-10 15:01 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 16:38 +0100
Re: "C++ on the Move" by Darryl K. Taft scott@slp53.sl.home (Scott Lurndal) - 2023-03-10 16:36 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-11 10:43 +0100
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-08 12:59 -0800
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-09 03:03 -0800
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-09 12:12 -0800
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-09 19:20 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 10:36 +0100
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-10 04:27 -0800
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-10 05:13 -0800
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-10 06:05 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 15:59 +0100
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-10 15:14 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 16:45 +0100
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-10 16:02 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-13 11:45 +0100
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-13 12:00 +0000
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-13 12:26 +0000
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-13 15:00 +0000
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-13 15:18 +0000
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-13 16:00 +0000
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-13 18:43 +0000
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-14 09:26 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-14 13:30 +0100
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-14 16:16 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-14 17:49 +0100
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-14 17:14 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-14 23:05 +0100
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-15 08:39 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-15 17:31 +0100
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-15 17:11 +0000
Re: "C++ on the Move" by Darryl K. Taft Ben Bacarisse <ben.lists@bsb.me.uk> - 2023-03-15 00:10 +0000
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 14:52 -0700
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-13 20:17 +0100
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-13 19:31 +0000
Re: "C++ on the Move" by Darryl K. Taft Paavo Helde <eesnimi@osa.pri.ee> - 2023-03-14 00:01 +0200
Re: "C++ on the Move" by Darryl K. Taft gst <g.starck@gmail.com> - 2023-03-13 23:49 -0700
Re: "C++ on the Move" by Darryl K. Taft "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-03-14 11:04 +0100
Re: "C++ on the Move" by Darryl K. Taft gst <g.starck@gmail.com> - 2023-03-14 03:26 -0700
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-14 09:08 +0100
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 01:21 -0700
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 15:12 -0700
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-14 09:31 +0000
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-14 09:51 +0000
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-14 09:56 +0000
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-14 10:30 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-14 13:41 +0100
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 14:50 -0700
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 14:13 -0700
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-14 21:53 +0000
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-04 23:21 -0700
Re: "C++ on the Move" by Darryl K. Taft "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-04-05 08:44 -0700
Re: "C++ on the Move" by Darryl K. Taft legalize+jeeves@mail.xmission.com (Richard) - 2023-04-05 15:47 +0000
Re: "C++ on the Move" by Darryl K. Taft scott@slp53.sl.home (Scott Lurndal) - 2023-04-05 16:33 +0000
Re: "C++ on the Move" by Darryl K. Taft richardthiebaud <thiebauddick2@aol.com> - 2023-04-05 12:53 -0400
Re: "C++ on the Move" by Darryl K. Taft scott@slp53.sl.home (Scott Lurndal) - 2023-04-05 17:19 +0000
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-04-05 13:47 -0700
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-04-06 08:12 +0000
Re: "C++ on the Move" by Darryl K. Taft Daniel <danielaparker@gmail.com> - 2023-04-06 05:23 -0700
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-04-06 08:09 +0000
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 10:02 -0700
Re: "C++ on the Move" by Darryl K. Taft Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-05 21:04 +0100
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 09:52 -0700
Re: "C++ on the Move" by Darryl K. Taft Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-20 21:01 +0100
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 08:57 -0700
Re: "C++ on the Move" by Darryl K. Taft Muttley@dastardlyhq.com - 2023-03-14 16:20 +0000
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-10 07:23 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 16:48 +0100
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 15:54 +0100
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-10 07:12 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 16:53 +0100
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-10 08:20 -0800
Re: "C++ on the Move" by Darryl K. Taft kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-03-10 16:48 +0000
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-12 11:54 +0100
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-12 09:29 -0700
Re: "C++ on the Move" by Darryl K. Taft Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-12 09:57 -0700
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-12 10:26 -0700
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-13 14:40 +0100
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-13 08:59 -0700
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-12 14:17 -0700
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-12 16:18 -0700
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-13 14:30 +0100
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-13 08:25 -0700
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-13 17:54 +0100
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-14 13:27 -0700
Re: "C++ on the Move" by Darryl K. Taft Paavo Helde <eesnimi@osa.pri.ee> - 2023-03-13 20:37 +0200
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-14 13:30 -0700
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-13 10:02 -0700
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-13 20:21 +0100
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-13 12:53 -0700
Re: "C++ on the Move" by Darryl K. Taft Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 01:17 -0700
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-14 09:55 +0100
Re: "C++ on the Move" by Darryl K. Taft scott@slp53.sl.home (Scott Lurndal) - 2023-03-10 16:27 +0000
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-10 11:33 -0800
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-10 11:14 -0800
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-11 04:10 -0800
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-12 12:06 +0100
Re: "C++ on the Move" by Darryl K. Taft Öö Tiib <ootiib@hot.ee> - 2023-03-12 09:29 -0700
Re: "C++ on the Move" by Darryl K. Taft Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-09 15:26 +0100
Re: "C++ on the Move" by Darryl K. Taft Lynn McGuire <lynnmcguire5@gmail.com> - 2023-03-09 16:59 -0600
Re: "C++ on the Move" by Darryl K. Taft Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-10 05:59 +0100
Re: "C++ on the Move" by Darryl K. Taft "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-03-10 09:17 +0100
Re: "C++ on the Move" by Darryl K. Taft Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-10 13:38 +0100
Re: "C++ on the Move" by Darryl K. Taft Michael S <already5chosen@yahoo.com> - 2023-03-10 05:10 -0800
Re: "C++ on the Move" by Darryl K. Taft Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-10 15:20 +0100
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 16:13 +0100
Re: "C++ on the Move" by Darryl K. Taft David Brown <david.brown@hesbynett.no> - 2023-03-10 10:44 +0100
Re: "C++ on the Move" by Darryl K. Taft Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-10 11:08 -0800
Re: "C++ on the Move" by Darryl K. Taft "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-03-12 11:42 +0100
Re: "C++ on the Move" by Darryl K. Taft "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-04-06 00:42 -0700
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-03-14 16:16 +0000 |
| Message-ID | <tuq6lj$di5r$1@dont-email.me> |
| In reply to | #89745 |
On Tue, 14 Mar 2023 13:30:15 +0100 David Brown <david.brown@hesbynett.no> wrote: >On 14/03/2023 10:26, Muttley@dastardlyhq.com wrote: >> On Mon, 13 Mar 2023 18:43:11 -0000 (UTC) >> Quite possibly, but recursion has its own issues. The main one being that >> the dev forgets to code in the correct stop checks and one day it recurses >> forever. Sure that can happen with a standard for loop, but its more likely >to >> be spotted. >> > >It is rarely difficult to be sure your recursion ends - you just have to >make sure you have a loop variant that gets smaller with each round, and >ends at 0. Very often you are looping over a data structure (such as a >list), and this happens naturally. Its not that simple especially when head vs tail recursion matters. >Of course, you might /want/ infinite recursion. Many (not all) >functional programming languages support lazy evaluation, and so >infinite lists are commonly used. If you can infinite recursion then its not recursion, its a disguised loop. >considering. Message passing can give you lock-free algorithms, or >close to lock-free, and can significantly simplify a lot of the rest of >the code in comparison to shared memory systems. It can scale better, >and work smoothly across different levels of parallelism (light-weight >fibres, threads, processes, multiple cores, multiple computers). But it >can be costly if you need to share large blocks of data back and forth >between multiple actors. Generally its more complex and slower than a monolithic approach which is why despite all the endless academic papers and books written about the wonders of message passing kernels, few actually exist in the wild. >> to how people think. Eg "Add 1 to this, go around again. Put this value in a >> box and put the box in that other box" etc. > >It is far more natural to think "Do this for each box", or "Do this for >the first box. Then do the same for all the other boxes" than to think Except its not that. Its do this for the first box, then jump in the box and do it for the 2nd box. Then jump in that box. And when you get to the end you have to jump out of all the boxes in reverse russian doll style. Whereas iterating through some kind of list is done in everyday life. >I think that the more experienced you are with one style, the more it >will feel "natural" for you and the harder it is to get used to an >alternative. That applies to all sorts of things, not just programming. > >But there's little doubt that some kinds of algorithms or programming >problems are easier and clearer in one style of programming language, >while others are easier in a different style. No doubt true.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-14 17:49 +0100 |
| Message-ID | <tuq8ig$dq70$1@dont-email.me> |
| In reply to | #89751 |
On 14/03/2023 17:16, Muttley@dastardlyhq.com wrote: > On Tue, 14 Mar 2023 13:30:15 +0100 > David Brown <david.brown@hesbynett.no> wrote: >> On 14/03/2023 10:26, Muttley@dastardlyhq.com wrote: >>> On Mon, 13 Mar 2023 18:43:11 -0000 (UTC) >>> Quite possibly, but recursion has its own issues. The main one being that >>> the dev forgets to code in the correct stop checks and one day it recurses >>> forever. Sure that can happen with a standard for loop, but its more likely >> to >>> be spotted. >>> >> >> It is rarely difficult to be sure your recursion ends - you just have to >> make sure you have a loop variant that gets smaller with each round, and >> ends at 0. Very often you are looping over a data structure (such as a >> list), and this happens naturally. > > Its not that simple especially when head vs tail recursion matters. "Tail recursion" is when the end of a function is a recursive call that can be replaced by a jump to the start (or near the start) of the function. It's an optimisation which is extremely important to efficiently implementing linear recursive code. I'm not sure what you mean by "head recursion", nor why you think optimisation affects the likelihood of a developer accidentally writing unbounded recursion. Maybe you mean something different by the terms? > >> Of course, you might /want/ infinite recursion. Many (not all) >> functional programming languages support lazy evaluation, and so >> infinite lists are commonly used. > > If you can infinite recursion then its not recursion, its a disguised loop. In terms of computational theory, all loops are disguised recursion - loops can /always/ be re-written in terms of recursion. And /simple/ recursion can be re-written in terms of loops (but more complicated cases cannot). A functional programming definition such as : nums = 1 : map (+1) nums is infinite recursion, generating an infinite list. It doesn't matter if it could be replaced by a loop or not - it is still infinite recursion. Or you could write : data T = Branch T T ts = Branch ts ts That defines an infinite recursive binary tree structure - not a useful one, but if that is a disguised loop, it is well disguised! > >> considering. Message passing can give you lock-free algorithms, or >> close to lock-free, and can significantly simplify a lot of the rest of >> the code in comparison to shared memory systems. It can scale better, >> and work smoothly across different levels of parallelism (light-weight >> fibres, threads, processes, multiple cores, multiple computers). But it >> can be costly if you need to share large blocks of data back and forth >> between multiple actors. > > Generally its more complex and slower than a monolithic approach which is why > despite all the endless academic papers and books written about the wonders of > message passing kernels, few actually exist in the wild. > What, exactly, is a "monolithic approach" to synchronisation of actors, or to sharing of data? Message passing systems of many kinds are found all over the place - it is not a concept for kernels. Some languages (like Erlang, Go, occam) have it as fundamental aspects of the language. There are libraries and frameworks using it. There is hardware that is based around message passing (such as XMOS devices). There are OS kernels build around it - it is the foundation for FreeRTOS, the most popular real-time OS. Pretty much everything that is considered "distributed" works by message passing. I suspect you are thinking of a few specific use-cases where shared memory with locks is more efficient than message passing might be (and such cases certainly exist), and generalising from there. >>> to how people think. Eg "Add 1 to this, go around again. Put this value in a >>> box and put the box in that other box" etc. >> >> It is far more natural to think "Do this for each box", or "Do this for >> the first box. Then do the same for all the other boxes" than to think > > Except its not that. Its do this for the first box, then jump in the box and > do it for the 2nd box. Then jump in that box. And when you get to the end you > have to jump out of all the boxes in reverse russian doll style. Whereas > iterating through some kind of list is done in everyday life. You are seriously abusing the analogies here. Perhaps you should have spent more than 10 minutes looking at functional programming languages, because you seem a bit confused. > >> I think that the more experienced you are with one style, the more it >> will feel "natural" for you and the harder it is to get used to an >> alternative. That applies to all sorts of things, not just programming. >> >> But there's little doubt that some kinds of algorithms or programming >> problems are easier and clearer in one style of programming language, >> while others are easier in a different style. > > No doubt true. > There's always /something/ we can agree on :-)
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-03-14 17:14 +0000 |
| Message-ID | <tuqa28$e5ib$1@dont-email.me> |
| In reply to | #89754 |
On Tue, 14 Mar 2023 17:49:20 +0100
David Brown <david.brown@hesbynett.no> wrote:
>On 14/03/2023 17:16, Muttley@dastardlyhq.com wrote:
>> Its not that simple especially when head vs tail recursion matters.
>
>"Tail recursion" is when the end of a function is a recursive call that
>can be replaced by a jump to the start (or near the start) of the
>function. It's an optimisation which is extremely important to
>efficiently implementing linear recursive code. I'm not sure what you
>mean by "head recursion", nor why you think optimisation affects the
Head recursion:
int func(int val)
{
ret = func(val);
.. do something ..
return ret;
}
Tail recursion:
int func(int val)
{
... do something ...
return func(val);
}
I'm sure there are plenty of examples in google.
>loops can /always/ be re-written in terms of recursion. And /simple/
>recursion can be re-written in terms of loops (but more complicated
>cases cannot).
Sounds unlikely. All recursion AFAIK can be emulated using a loop and one or
more stacks.
>A functional programming definition such as :
>
> nums = 1 : map (+1) nums
No idea what thats doing.
>Or you could write :
>
> data T = Branch T T
> ts = Branch ts ts
>
>That defines an infinite recursive binary tree structure - not a useful
>one, but if that is a disguised loop, it is well disguised!
I imagine the interpreter is looping internally so unless it uses magic how
does it do it?
>> Generally its more complex and slower than a monolithic approach which is why
>
>> despite all the endless academic papers and books written about the wonders
>of
>> message passing kernels, few actually exist in the wild.
>>
>
>What, exactly, is a "monolithic approach" to synchronisation of actors,
>or to sharing of data?
Shared memory and locking obv.
>Message passing systems of many kinds are found all over the place - it
>is not a concept for kernels. Some languages (like Erlang, Go, occam)
Occam was a joke though sadly it lived long enough to give Guido bad ideas
about whitespace.
>passing (such as XMOS devices). There are OS kernels build around it -
>it is the foundation for FreeRTOS, the most popular real-time OS.
If you say so. Every embedded OS I've ever worked on has been linux, usually
BusyBox.
>Pretty much everything that is considered "distributed" works by message
>passing.
Err yes, but they're generally not in a single application binary are they
which is what we're discussing.
>> do it for the 2nd box. Then jump in that box. And when you get to the end you
>
>> have to jump out of all the boxes in reverse russian doll style. Whereas
>> iterating through some kind of list is done in everyday life.
>
>You are seriously abusing the analogies here. Perhaps you should have
>spent more than 10 minutes looking at functional programming languages,
>because you seem a bit confused.
I'm not confused at all. I know how recursion works thanks. Perhaps you don't?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-14 23:05 +0100 |
| Message-ID | <tuqr45$hfsb$1@dont-email.me> |
| In reply to | #89755 |
On 14/03/2023 18:14, Muttley@dastardlyhq.com wrote:
> On Tue, 14 Mar 2023 17:49:20 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>> On 14/03/2023 17:16, Muttley@dastardlyhq.com wrote:
>>> Its not that simple especially when head vs tail recursion matters.
>>
>> "Tail recursion" is when the end of a function is a recursive call that
>> can be replaced by a jump to the start (or near the start) of the
>> function. It's an optimisation which is extremely important to
>> efficiently implementing linear recursive code. I'm not sure what you
>> mean by "head recursion", nor why you think optimisation affects the
>
> Head recursion:
>
> int func(int val)
> {
> ret = func(val);
> .. do something ..
> return ret;
> }
>
>
> Tail recursion:
> int func(int val)
> {
> ... do something ...
> return func(val);
> }
>
>
> I'm sure there are plenty of examples in google.
"Tail recursion" is an important classification because of the
optimisation opportunities. "Head recursion" is just something made up
by people who mistakenly think it is somehow the opposite of tail recursion.
The distinction is irrelevant to correctness.
int sum_square_head(list xs) {
if (xs.empty()) return 0;
int x = xs.pop();
int t = sum__square_head(xs);
int sq = x * x; // Do something
return sq + t;
}
int sum_square_tail(list xs) {
if (xs.empty()) return 0;
int x = xs.pop();
int sq = x * x; // Do something
int t = sum__square_head(xs);
return sq + t;
}
Why would you think it is easier to get the recursion size right in one
of these than the other?
>
>> loops can /always/ be re-written in terms of recursion. And /simple/
>> recursion can be re-written in terms of loops (but more complicated
>> cases cannot).
>
> Sounds unlikely. All recursion AFAIK can be emulated using a loop and one or
> more stacks.
>
If you are including multiple stacks which can grow unbounded, then you
are not talking about "disguised loops". (But then yes, you can emulate
the recursion.)
>> A functional programming definition such as :
>>
>> nums = 1 : map (+1) nums
>
> No idea what thats doing.
"nums" is the list you get when you put a 1 on the front of the result
of taking the list "nums" and adding 1 to each element in the list. It
is a recursive definition of an infinite list.
In Python, it is roughly equivalent to :
def nums() :
yield 1
rest = nums()
while True :
yield 1 + rest.next()
>
>> Or you could write :
>>
>> data T = Branch T T
>> ts = Branch ts ts
>>
>> That defines an infinite recursive binary tree structure - not a useful
>> one, but if that is a disguised loop, it is well disguised!
>
> I imagine the interpreter is looping internally so unless it uses magic how
> does it do it?
>
Lazy evaluation - the values in a list or other structures are not
calculated until you need them. "take 10 nums" will calculate and
return the first 10 elements in the list "nums", but won't bother
calculating any more. (The "ts" example has an infinite structure but
no content, so as far as I know there's not much you can actually do
with it.)
>>> Generally its more complex and slower than a monolithic approach which is why
>>
>>> despite all the endless academic papers and books written about the wonders
>> of
>>> message passing kernels, few actually exist in the wild.
>>>
>>
>> What, exactly, is a "monolithic approach" to synchronisation of actors,
>> or to sharing of data?
>
> Shared memory and locking obv.
>
Then why not say "shared memory and locking" ? "Monolithic" means
something completely different and unrelated.
>> Message passing systems of many kinds are found all over the place - it
>> is not a concept for kernels. Some languages (like Erlang, Go, occam)
>
> Occam was a joke though sadly it lived long enough to give Guido bad ideas
> about whitespace.
It was experimental, it was not a joke, and along with the transputer
(the language and the device were intertwined) was an important step
towards a lot of modern languages, devices, and system architectures.
>
>> passing (such as XMOS devices). There are OS kernels build around it -
>> it is the foundation for FreeRTOS, the most popular real-time OS.
>
> If you say so. Every embedded OS I've ever worked on has been linux, usually
> BusyBox.
Experiences vary. You've experienced a tiny part of the embedded world.
That's fine, and there's lots happening in embedded Linux, but far
smaller embedded OS's and RTOS's outnumber it hugely.
>
>> Pretty much everything that is considered "distributed" works by message
>> passing.
>
> Err yes, but they're generally not in a single application binary are they
> which is what we're discussing.
>
When you are dealing with scalable distributed systems, the distinctions
get blurred.
>>> do it for the 2nd box. Then jump in that box. And when you get to the end you
>>
>>> have to jump out of all the boxes in reverse russian doll style. Whereas
>>> iterating through some kind of list is done in everyday life.
>>
>> You are seriously abusing the analogies here. Perhaps you should have
>> spent more than 10 minutes looking at functional programming languages,
>> because you seem a bit confused.
>
> I'm not confused at all. I know how recursion works thanks. Perhaps you don't?
>
If you think you understand, then perhaps you might reconsider your
jumbled "Russian doll" idea.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-03-15 08:39 +0000 |
| Message-ID | <tus079$q82i$1@dont-email.me> |
| In reply to | #89770 |
On Tue, 14 Mar 2023 23:05:57 +0100 David Brown <david.brown@hesbynett.no> wrote: >"Tail recursion" is an important classification because of the >optimisation opportunities. "Head recursion" is just something made up >by people who mistakenly think it is somehow the opposite of tail recursion. Rubbish. But you go argue it out with generations of computer scientists if you like. >> Sounds unlikely. All recursion AFAIK can be emulated using a loop and one or >> more stacks. >> > >If you are including multiple stacks which can grow unbounded, then you >are not talking about "disguised loops". (But then yes, you can emulate >the recursion.) So if I use std::stack in a loop, suddenly its not a loop? Wtf? >> I imagine the interpreter is looping internally so unless it uses magic how >> does it do it? >> > >Lazy evaluation - the values in a list or other structures are not >calculated until you need them. "take 10 nums" will calculate and >return the first 10 elements in the list "nums", but won't bother >calculating any more. (The "ts" example has an infinite structure but >no content, so as far as I know there's not much you can actually do >with it.) I'll ask again - how does the interpreter do recursion internally? I think we both know the answer but you seem to be dodging it. Curious. >>> What, exactly, is a "monolithic approach" to synchronisation of actors, >>> or to sharing of data? >> >> Shared memory and locking obv. >> > >Then why not say "shared memory and locking" ? "Monolithic" means >something completely different and unrelated. No, monolithic in this sense means sharing of inter thread communication resources within the binary. Ie not message passing. >It was experimental, it was not a joke, and along with the transputer >(the language and the device were intertwined) was an important step >towards a lot of modern languages, devices, and system architectures. Yet both vanished without trace in a fairly short space of time. Turns out manufacturers prefered standard CPUs that weren't a bitch to program and didn't require a special, rather odd language to do it. Who'd have guessed. >> If you say so. Every embedded OS I've ever worked on has been linux, usually >> BusyBox. > >Experiences vary. You've experienced a tiny part of the embedded world. > That's fine, and there's lots happening in embedded Linux, but far >smaller embedded OS's and RTOS's outnumber it hugely. I wonder how many android phones running a linux kernel there are in the world... >> Err yes, but they're generally not in a single application binary are they >> which is what we're discussing. >> > >When you are dealing with scalable distributed systems, the distinctions >get blurred. They certainly are in your argument but moving the goalposts isn't doing it any favours. >> I'm not confused at all. I know how recursion works thanks. Perhaps you >don't? >> > >If you think you understand, then perhaps you might reconsider your >jumbled "Russian doll" idea. I don't think, I know thank you. You might want to redefine it to suit your argument but thats neither here nor there.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-15 17:31 +0100 |
| Message-ID | <tusrts$v7m7$1@dont-email.me> |
| In reply to | #89784 |
On 15/03/2023 09:39, Muttley@dastardlyhq.com wrote: > On Tue, 14 Mar 2023 23:05:57 +0100 > David Brown <david.brown@hesbynett.no> wrote: >> "Tail recursion" is an important classification because of the >> optimisation opportunities. "Head recursion" is just something made up >> by people who mistakenly think it is somehow the opposite of tail recursion. > > Rubbish. But you go argue it out with generations of computer scientists if > you like. > >>> Sounds unlikely. All recursion AFAIK can be emulated using a loop and one or >>> more stacks. >>> >> >> If you are including multiple stacks which can grow unbounded, then you >> are not talking about "disguised loops". (But then yes, you can emulate >> the recursion.) > > So if I use std::stack in a loop, suddenly its not a loop? Wtf? > Your claim was that infinite recursion is just a disguised loop, which was silly. Saying that you can get the effect of the infinite recursion by using loops with stacks is true, but does not relate to your claim. > >>>> What, exactly, is a "monolithic approach" to synchronisation of actors, >>>> or to sharing of data? >>> >>> Shared memory and locking obv. >>> >> >> Then why not say "shared memory and locking" ? "Monolithic" means >> something completely different and unrelated. > > No, monolithic in this sense means sharing of inter thread communication > resources within the binary. Ie not message passing. > So "monolithic" in the sense of having nothing whatsoever to do with the usual use of the word "monolithic" ? I appreciate that you meant shared memory with locking, and I agree that it can sometimes be more efficient than message passing - but "monolithic" is not the right term. >> It was experimental, it was not a joke, and along with the transputer >> (the language and the device were intertwined) was an important step >> towards a lot of modern languages, devices, and system architectures. > > Yet both vanished without trace in a fairly short space of time. Turns out > manufacturers prefered standard CPUs that weren't a bitch to program and didn't > require a special, rather odd language to do it. Who'd have guessed. No, they didn't vanish without a trace - lots of hardware, software and languages have been influenced by them and taken the good ideas from them. The things that didn't work so well in practice, disappeared. That's how progress works. For better or for worse, the most popular programming model for processors is "like C". Under the hood, however, the concepts of "Communicating Sequential Processes" are massively important. The transputer and occam, as early hardware and software implementations, have gone - but not without a trace. But you'll only see the effects if you look around. If you have the time, I would recommend looking at XMOS devices and their tools. They are not the biggest selling devices (ARM cores are totally dominant), but they are some of the most innovative and fun, and their CSP/transputer/occam roots are much clearer than in most devices that hide away their message passing internally. > >>> If you say so. Every embedded OS I've ever worked on has been linux, usually >>> BusyBox. >> >> Experiences vary. You've experienced a tiny part of the embedded world. >> That's fine, and there's lots happening in embedded Linux, but far >> smaller embedded OS's and RTOS's outnumber it hugely. > > I wonder how many android phones running a linux kernel there are in the > world... > There are something like 1.5 billion embedded Linux devices shipped every year, such as phones, tablets, routers, etc. There are over twenty times as many microcontrollers shipped, with something like half of them having an RTOS of some kind. Even your phone probably has a dozen microcontrollers in addition to the processor running Linux.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-03-15 17:11 +0000 |
| Message-ID | <tusu8i$vlh3$1@dont-email.me> |
| In reply to | #89789 |
On Wed, 15 Mar 2023 17:31:55 +0100 David Brown <david.brown@hesbynett.no> wrote: >On 15/03/2023 09:39, Muttley@dastardlyhq.com wrote: >> On Tue, 14 Mar 2023 23:05:57 +0100 >> David Brown <david.brown@hesbynett.no> wrote: >>> "Tail recursion" is an important classification because of the >>> optimisation opportunities. "Head recursion" is just something made up >>> by people who mistakenly think it is somehow the opposite of tail recursion. > >> >> Rubbish. But you go argue it out with generations of computer scientists if >> you like. >> >>>> Sounds unlikely. All recursion AFAIK can be emulated using a loop and one >or >>>> more stacks. >>>> >>> >>> If you are including multiple stacks which can grow unbounded, then you >>> are not talking about "disguised loops". (But then yes, you can emulate >>> the recursion.) >> >> So if I use std::stack in a loop, suddenly its not a loop? Wtf? >> > >Your claim was that infinite recursion is just a disguised loop, which >was silly. Saying that you can get the effect of the infinite recursion >by using loops with stacks is true, but does not relate to your claim. You can't have infinite recursion in this universe. If you do then it IS a disguised loop because it cannot be storing any return stack and would therefore immediately exit upon the first return at the bottom. Either it recurses N levels down then unwinds N levels back up or it doesn't bother unwinding in which case its not proper recursion, its a loop. >> Yet both vanished without trace in a fairly short space of time. Turns out >> manufacturers prefered standard CPUs that weren't a bitch to program and >didn't >> require a special, rather odd language to do it. Who'd have guessed. > >No, they didn't vanish without a trace - lots of hardware, software and >languages have been influenced by them and taken the good ideas from >them. The things that didn't work so well in practice, disappeared. Or not in the case of significant whitespace. They may have had some minor influence on hardware and software, but Occam and transputers are long gone and not many people will have heard of either. >totally dominant), but they are some of the most innovative and fun, and Innovative doesn't always mean useful except in maybe a few niche areas.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.lists@bsb.me.uk> |
|---|---|
| Date | 2023-03-15 00:10 +0000 |
| Message-ID | <87a60e98o4.fsf@bsb.me.uk> |
| In reply to | #89754 |
David Brown <david.brown@hesbynett.no> writes: > On 14/03/2023 17:16, Muttley@dastardlyhq.com wrote: >> On Tue, 14 Mar 2023 13:30:15 +0100 >> David Brown <david.brown@hesbynett.no> wrote: <cut> >>> Of course, you might /want/ infinite recursion. Many (not all) >>> functional programming languages support lazy evaluation, and so >>> infinite lists are commonly used. >> If you can infinite recursion then its not recursion, its a disguised >> loop. > > In terms of computational theory, all loops are disguised recursion - loops > can /always/ be re-written in terms of recursion. And /simple/ recursion > can be re-written in terms of loops (but more complicated cases cannot). > > A functional programming definition such as : > > nums = 1 : map (+1) nums > > is infinite recursion, generating an infinite list. This discussion is going to go off the rails (if it hasn't already) without some better terms. "Infinite recursion", if it means anything at all, should imply an unending computation. In a lazy language, nums is not "infinite recursion", it's just a recursive definition. Lazy evaluation just moves the place where the recursion is (usually!) made finite somewhere higher-up in the program. Likewise p n = if n == 0 then 1 else n * p (n-1) is just a recursive definition. It's not finite (or not "infinite recursion") just because it has an if in it! My point is that lazy evaluation is a red herring. Infinite recursion (like "sum nums" and "p (-1)") is always bad in this sort of context, just as it sometimes good in the context of never-ending programs like servers. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-03-14 14:52 -0700 |
| Message-ID | <86fsa76lvp.fsf@linuxsc.com> |
| In reply to | #89720 |
kalevi@kolttonen.fi (Kalevi Kolttonen) writes: > Muttley@dastardlyhq.com wrote: > >> Sounds like its one of those languages thats theoretically "pure" >> at the expense of making it hard to learn and write basic >> algorithms. Make a language too obtuse and few people will both >> to learn it as IBM found out with APL. > > I guess that many of Erlang's features are supposed to make it > easier to reason about the code's correctness. For example, > concerning recursion, I have heard arguments that claim it helps > to avoid off-by-one mistakes that can happen pretty easily in > languages such as C. Erlang doesn't have arrays, right? The absence of arrays by itself tends to eliminate off-by-one errors.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-13 20:17 +0100 |
| Message-ID | <tunssm$3t5ek$1@dont-email.me> |
| In reply to | #89711 |
On 13/03/2023 16:18, Kalevi Kolttonen wrote: > Muttley@dastardlyhq.com wrote: >> Its functional isn't it? Functional languages are interesting as they do >> polymorphism by value rather than by type IME. > > Yes, it is functional. > > There are no for or while loops in Erlang, but you > have to use recursion instead. That's standard for functional programming languages. > > Variables are immutable, so you assign a value to them once > and they retain it. To me, this feature is probably the > trickiest or "craziest". In so many other programming languages, > we take it for granted that the values of variables can change > during the program execution. Again, that is the norm for functional programming languages. It is even becoming common in non-functional languages for immutable "variables" to be the default. A high proportion of variables in C or C++ never need to be changed after their initialisation or first assignment, and it is much easier to reason about the correctness of the code if the values of variables never changes. But it is certainly the case that functional programming involves thinking about things in a somewhat different fashion from imperative programming. And some tasks are easier in one style, others in a different style. > > The following is taken straight from Wikipedia. The information > is based on Joe Armstrong's (one of language creators) PhD > Thesis: > > Everything is a process. > Processes are strongly isolated. > Process creation and destruction is a lightweight operation. > Message passing is the only way for processes to interact. > Processes have unique names. > If you know the name of a process you can send it a message. > Processes share no resources. > Error handling is non-local. > Processes do what they are supposed to do or fail. > >>> They use Erlang in some mobile phone networks, and with >> >> IIRC thats why ericsson wrote it. > > Correct. The motto for Erlang is "write once, run forever". It's most fun feature, IMHO, is the extent to which you can replace code while everything is still running. The idea is that you don't have to stop your entire mobile phone network just because you want to update the software. > > I just quickly glanced through the Wikipedia article > and it says there is one notable new application written > in Erlang: WhatsApp. Maybe the client code is not Erlang, > but the server infrastructure is. > There's a lot more software written in Erlang than just WhatsApp. As well as being vital to many mobile phone and telecommunications networks, it is used in a lot of server systems that require high reliability and massive scalability. Of course it depends on what you call "notable". There is also Elixir that builds on Erlang, running on the same virtual machine.
[toc] | [prev] | [next] | [standalone]
| From | kalevi@kolttonen.fi (Kalevi Kolttonen) |
|---|---|
| Date | 2023-03-13 19:31 +0000 |
| Message-ID | <tuntlm$3t77t$1@dont-email.me> |
| In reply to | #89723 |
David Brown <david.brown@hesbynett.no> wrote: >> There are no for or while loops in Erlang, but you >> have to use recursion instead. > > That's standard for functional programming languages. I know. >> Variables are immutable, so you assign a value to them once >> and they retain it. To me, this feature is probably the >> trickiest or "craziest". In so many other programming languages, >> we take it for granted that the values of variables can change >> during the program execution. > > Again, that is the norm for functional programming languages. It is > even becoming common in non-functional languages for immutable > "variables" to be the default. A high proportion of variables in C or > C++ never need to be changed after their initialisation or first > assignment, and it is much easier to reason about the correctness of the > code if the values of variables never changes. That I didn't know. I thought immutable variables were a pretty unique part of Erlang. > But it is certainly the case that functional programming involves > thinking about things in a somewhat different fashion from imperative > programming. And some tasks are easier in one style, others in a > different style. Yes, the mental model is different. > The motto for Erlang is "write once, run forever". It's most fun > feature, IMHO, is the extent to which you can replace code while > everything is still running. The idea is that you don't have to stop > your entire mobile phone network just because you want to update the > software. I agree that it is a fantastic feature to have. I know of no other language that has it. >> I just quickly glanced through the Wikipedia article >> and it says there is one notable new application written >> in Erlang: WhatsApp. Maybe the client code is not Erlang, >> but the server infrastructure is. >> > > There's a lot more software written in Erlang than just WhatsApp. As > well as being vital to many mobile phone and telecommunications > networks, it is used in a lot of server systems that require high > reliability and massive scalability. Of course it depends on what you > call "notable". Right, the definition of "notable" is important here, but without doubt WhatsApp qualifies with flying colors. It still has lots of users worldwide despite emerging competition. > There is also Elixir that builds on Erlang, running on the same virtual > machine. Yes, I noticed that when reading the Wikipedia article. They also have programming language Lua running on BEAM virtual machine. br, KK
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2023-03-14 00:01 +0200 |
| Message-ID | <tuo6fu$3up1v$1@dont-email.me> |
| In reply to | #89725 |
13.03.2023 21:31 Kalevi Kolttonen kirjutas: > David Brown <david.brown@hesbynett.no> wrote: >> Again, that is the norm for functional programming languages. It is >> even becoming common in non-functional languages for immutable >> "variables" to be the default. A high proportion of variables in C or >> C++ never need to be changed after their initialisation or first >> assignment, and it is much easier to reason about the correctness of the >> code if the values of variables never changes. > > That I didn't know. I thought immutable variables were a pretty > unique part of Erlang. For example, a string variable in Python is kind of immutable AFAIK. You can replace it, but you cannot change it. If there are multiple references to the string, the other references will continue to point to the old string even if some path pointing to it is replaced by a new string, in a COW fashion. So the string acts like an immutable atomic/scalar value and any references to it only serve as a tool for memory optimization and cannot be used for modification of data visible via other references. At least that's what I've gathered, I'm no expert in Python.
[toc] | [prev] | [next] | [standalone]
| From | gst <g.starck@gmail.com> |
|---|---|
| Date | 2023-03-13 23:49 -0700 |
| Message-ID | <d3cdc411-7f39-4586-8137-431154fc8b4bn@googlegroups.com> |
| In reply to | #89730 |
Le lundi 13 mars 2023 à 18:02:00 UTC-4, Paavo Helde a écrit : > For example, a string variable in Python is kind of immutable AFAIK. Pure strings, as floats, ints,.. in Python *are* totally immutable. not kind of. totally. > .. it is replaced by a new string, in a COW fashion. So the string acts like an immutable > atomic/scalar value and any references to it only serve as a tool for > memory optimization and cannot be used for modification of data visible > via other references. they don't acts like immutable, they are. You cannot modify a string/immutabe objects. they do not have any method with side effect. you can assign a string to something, then that thing can be passed down the line/anywhere, the same string can be assigned to many different things/names by many assignements (many references to them yes). But you cannot, never, modify a string in-place, with any reference to it. It has no such method (even private)/feature/possibility. You could only (try to) modify it by accessing C low level internal of CPython say, the implementation, not the language. but by then it's not anymore Python you're doing and that could/would break at some point your/any Python code obviously.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2023-03-14 11:04 +0100 |
| Message-ID | <tupgs0$9i9k$1@dont-email.me> |
| In reply to | #89731 |
On 2023-03-14 7:49 AM, gst wrote: > Le lundi 13 mars 2023 à 18:02:00 UTC-4, Paavo Helde a écrit : > >> For example, a string variable in Python is kind of immutable AFAIK. > > Pure strings, as floats, ints,.. in Python *are* totally immutable. not kind of. totally. > >> .. it is replaced by a new string, in a COW fashion. So the string acts like an immutable >> atomic/scalar value and any references to it only serve as a tool for >> memory optimization and cannot be used for modification of data visible >> via other references. > > they don't acts like immutable, they are. You cannot modify a string/immutabe objects. they do not have any method with side effect. Oh they do. In particular CPython concatenation modifies the string's buffer when it is exclusively owned, reference count 1. That reduces n concatenations from O(n^2) to O(n), which every Python programmer should know about, not to mention programmers in general. > you can assign a string to something, then that thing can be passed down the line/anywhere, the same string can be assigned to many different things/names by many assignements (many references to them yes). But you cannot, never, modify a string in-place, with any reference to it. It has no such method (even private)/feature/possibility. See above. But if you modify your assertions just a little, and talk about /observable buffer changes/, i.e. not even time consumption, then they could be OK. > You could only (try to) modify it by accessing C low level internal > of CPython say, the implementation, not the language. but by then > it's not anymore Python you're doing and that could/would break at > some point your/any Python code obviously. That's right, but that's not necessary; ordinary concatenation will do. - Alf
[toc] | [prev] | [next] | [standalone]
| From | gst <g.starck@gmail.com> |
|---|---|
| Date | 2023-03-14 03:26 -0700 |
| Message-ID | <73411acd-0f8e-492f-8e41-60d288f82076n@googlegroups.com> |
| In reply to | #89742 |
Le mardi 14 mars 2023 à 06:05:04 UTC-4, Alf P. Steinbach a écrit : > On 2023-03-14 7:49 AM, gst wrote: > > Le lundi 13 mars 2023 à 18:02:00 UTC-4, Paavo Helde a écrit : > > > >> For example, a string variable in Python is kind of immutable AFAIK. > > > > Pure strings, as floats, ints,.. in Python *are* totally immutable. not kind of. totally. > > > >> .. it is replaced by a new string, in a COW fashion. So the string acts like an immutable > >> atomic/scalar value and any references to it only serve as a tool for > >> memory optimization and cannot be used for modification of data visible > >> via other references. > > > > they don't acts like immutable, they are. You cannot modify a string/immutabe objects. they do not have any method with side effect. > > Oh they do. In particular CPython concatenation modifies the string's > buffer when it is exclusively owned, reference count 1. That reduces n > concatenations from O(n^2) to O(n), which every Python programmer should > know about, not to mention programmers in general. heuh yes, ok, but this an implementation detail of CPython which does not allow/enable you to modify an already assigned string. > > > > you can assign a string to something, then that thing can be passed down the line/anywhere, the same string can be assigned to many different things/names by many assignements (many references to them yes). But you cannot, never, modify a string in-place, with any reference to it. It has no such method (even private)/feature/possibility. > > See above. > > But if you modify your assertions just a little, and talk about > /observable buffer changes/, i.e. not even time consumption, then they > could be OK. what could be ok ? I don't modify any of the above assertions, there will be never buffer changes to any Python assigned string : ``` orig_ref = "foobar" any_function(orig_ref) assert orig_ref == "foobar" # always ``` > > > > You could only (try to) modify it by accessing C low level internal > > of CPython say, the implementation, not the language. but by then > > it's not anymore Python you're doing and that could/would break at > > some point your/any Python code obviously. > That's right, but that's not necessary; ordinary concatenation will do. > > > - Alf
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-14 09:08 +0100 |
| Message-ID | <tupa1c$8eth$1@dont-email.me> |
| In reply to | #89730 |
On 13/03/2023 23:01, Paavo Helde wrote: > 13.03.2023 21:31 Kalevi Kolttonen kirjutas: >> David Brown <david.brown@hesbynett.no> wrote: > >>> Again, that is the norm for functional programming languages. It is >>> even becoming common in non-functional languages for immutable >>> "variables" to be the default. A high proportion of variables in C or >>> C++ never need to be changed after their initialisation or first >>> assignment, and it is much easier to reason about the correctness of the >>> code if the values of variables never changes. >> >> That I didn't know. I thought immutable variables were a pretty >> unique part of Erlang. No. It is like mathematics - a mathematician will be happy with "x = 1", but get really upset if you say "x = x + 1" :-) Keeping things immutable makes it far easier to reason about what code does, and what transformations or optimisations are safe. You get to move things around, do things in parallel, and get much more structured and modularised code when you can't have different bits of the code all affecting the values of bits of data. Of course it also leads to limitations if you can never change the value of a variable. Applied to C++ programming, it is often good to aim where possible to have your data and your methods "const", or even "constexpr". But C++ supports a wide range of programming paradigms, so use what suits best for the task in hand. (There are "impure" functional languages, like ocaml, that allow mutable variables.) > > For example, a string variable in Python is kind of immutable AFAIK. You > can replace it, but you cannot change it. If there are multiple > references to the string, the other references will continue to point to > the old string even if some path pointing to it is replaced by a new > string, in a COW fashion. So the string acts like an immutable > atomic/scalar value and any references to it only serve as a tool for > memory optimization and cannot be used for modification of data visible > via other references. > > At least that's what I've gathered, I'm no expert in Python. > The key to understanding Python, IMHO, is to realise that there are no variables. There are only named references - and most of the things they point to, are immutable. So in Python, if you write : x = 1 you are /not/ creating an integer variable "x". You are creating an immutable object with type "integer" and value "1", unless such an object already exists (in which case you are increasing its reference count). You then have the reference named "x" that points to it. When you then write : x += 1 you are not changing "x". You are (roughly speaking) applying the methods x.__assign__(x.__add__(1)). This results in an object of integer type and value 2 being created, and "x" is now pointed to it. The reference count of the object "1" is decreased - if it is 0, the object can be garbage collected.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-03-14 01:21 -0700 |
| Message-ID | <865yb39204.fsf@linuxsc.com> |
| In reply to | #89730 |
Paavo Helde <eesnimi@osa.pri.ee> writes: > 13.03.2023 21:31 Kalevi Kolttonen kirjutas: > >> David Brown <david.brown@hesbynett.no> wrote: >> >>> Again, that is the norm for functional programming languages. It is >>> even becoming common in non-functional languages for immutable >>> "variables" to be the default. A high proportion of variables in C or >>> C++ never need to be changed after their initialisation or first >>> assignment, and it is much easier to reason about the correctness of the >>> code if the values of variables never changes. >> >> That I didn't know. I thought immutable variables were a pretty >> unique part of Erlang. > > For example, a string variable in Python is kind of immutable > AFAIK. You can replace it, but you cannot change it. If there are > multiple references to the string, the other references will continue > to point to the old string even if some path pointing to it is > replaced by a new string, in a COW fashion. So the string acts like an > immutable atomic/scalar value and any references to it only serve as a > tool for memory optimization and cannot be used for modification of > data visible via other references. String values are immutable, but a string value is not a variable. The variable can be changed, only the string value is immutable. > At least that's what I've gathered, I'm no expert in Python. Ditto.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-03-14 15:12 -0700 |
| Message-ID | <86bkkv6kzp.fsf@linuxsc.com> |
| In reply to | #89725 |
kalevi@kolttonen.fi (Kalevi Kolttonen) writes: > David Brown <david.brown@hesbynett.no> wrote: [...] >> The motto for Erlang is "write once, run forever". It's most fun >> feature, IMHO, is the extent to which you can replace code while >> everything is still running. The idea is that you don't have to >> stop your entire mobile phone network just because you want to >> update the software. > > I agree that it is a fantastic feature to have. I know of no > other language that has it. The internet, originally known as ARPAnet, started running in the late 1960s, and has run continuously without stopping ever since. During the time it has been running, every single atom of the original ARPAnet has been replaced, and of course there have been software changes as well. Meanwhile the phone network has hiccups every now and then for "upgrades", like when old phones stop working because they don't do 5G. What the mobile phone network does isn't anywhere near the kind of continuous running provided by the internet, which also doesn't need any particular language environment.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-03-14 09:31 +0000 |
| Message-ID | <tupesv$9989$1@dont-email.me> |
| In reply to | #89723 |
On Mon, 13 Mar 2023 20:17:41 +0100 David Brown <david.brown@hesbynett.no> wrote: >On 13/03/2023 16:18, Kalevi Kolttonen wrote: >> Variables are immutable, so you assign a value to them once >> and they retain it. To me, this feature is probably the >> trickiest or "craziest". In so many other programming languages, >> we take it for granted that the values of variables can change >> during the program execution. > >Again, that is the norm for functional programming languages. It is >even becoming common in non-functional languages for immutable >"variables" to be the default. A high proportion of variables in C or >C++ never need to be changed after their initialisation or first >assignment, and it is much easier to reason about the correctness of the >code if the values of variables never changes. One argument in favour of using #define over const vars. >> Correct. > >The motto for Erlang is "write once, run forever". It's most fun >feature, IMHO, is the extent to which you can replace code while >everything is still running. The idea is that you don't have to stop Which is probably about as accurate as javas write once run everywhere motto.
[toc] | [prev] | [next] | [standalone]
| From | kalevi@kolttonen.fi (Kalevi Kolttonen) |
|---|---|
| Date | 2023-03-14 09:51 +0000 |
| Message-ID | <tupg2c$9f9t$1@dont-email.me> |
| In reply to | #89739 |
Muttley@dastardlyhq.com wrote: >>The motto for Erlang is "write once, run forever". It's most fun >>feature, IMHO, is the extent to which you can replace code while >>everything is still running. The idea is that you don't have to stop > > Which is probably about as accurate as javas write once run everywhere motto. Concerning "write once": if we are realists, we must admit that no large program can be written "once" without any need for later bugfixes or enhancements. So "once" in this context cannot be taken quite literally. However, hot code updating feature certainly contributes to the latter part of the motto. Concerning "run forever": I tried to find evidence, but did not find any. Anyway, I have heard a rumour of some Erlang service being available for 10 years straight. br, KK
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c++
csiph-web