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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-03-14 09:56 +0000 |
| Message-ID | <tupgd6$9gtp$1@dont-email.me> |
| In reply to | #89740 |
On Tue, 14 Mar 2023 09:51:08 -0000 (UTC) kalevi@kolttonen.fi (Kalevi Kolttonen) wrote: >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. Possibly, but I'm just naturally suspicious of any provider who boasts of 24/7/365 uptime because in the real world that simply isn't possible. Whether its erlang, Tandom NonStop or cloud, eventually things go wrong and the services goes offline even if only for a short time.
[toc] | [prev] | [next] | [standalone]
| From | kalevi@kolttonen.fi (Kalevi Kolttonen) |
|---|---|
| Date | 2023-03-14 10:30 +0000 |
| Message-ID | <tupibu$9pa7$1@dont-email.me> |
| In reply to | #89741 |
Muttley@dastardlyhq.com wrote: > Possibly, but I'm just naturally suspicious of any provider who boasts of > 24/7/365 uptime because in the real world that simply isn't possible. Whether > its erlang, Tandom NonStop or cloud, eventually things go wrong and the > services goes offline even if only for a short time. VMS operating system has had stable clustering available for decades now, and I suppose the initial releases were long before Unix had any kind of clustering. Check this out: https://en.wikipedia.org/wiki/VMScluster "Cluster uptimes are frequently measured in years with the current longest uptime being at least sixteen years" Whether the services running on top of VMS were also continuously up is not clear based on that article. br, KK
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-14 13:41 +0100 |
| Message-ID | <tupq2h$b454$2@dont-email.me> |
| In reply to | #89739 |
On 14/03/2023 10:31, Muttley@dastardlyhq.com wrote: > 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. No. You can't change a variable declared "const" after initialisation. (There are undefined behaviours that can appear to change the value, such as via pointer casts, but then it's still easy to reason about the code correctness - it is incorrect.) > >>> 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. > I can't answer for Java, but Erlang's code replacement works if you write your code in the appropriate manner - as people do, for serious Erlang applications.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-03-14 14:50 -0700 |
| Message-ID | <86jzzj6lzn.fsf@linuxsc.com> |
| In reply to | #89711 |
kalevi@kolttonen.fi (Kalevi Kolttonen) writes: > Muttley@dastardlyhq.com wrote: > >> Its functional isn't it? Functional languages are interesting as >> they do polymorphism by value rather than by type IME. This generalization is wrong. No doubt there are some functional languages that use dynamic typing to accomplish value-based polymorphism, but these days most functional language use static typing with parametric polymorphism to allow the writing of polymorphic code. ML is the canonical example, and of course Haskell is more recent. ML has been around for 50 years. > Yes, it is functional. I would say Erlang is mostly functional, but also has some key features that are imperative in nature. > There are no for or while loops in Erlang, but you > have to use recursion instead. That's true, but it's pretty easy to write a recursive while() function that takes a closure or two, and such functions offer much of the flavor of while/for loops. An obvious difference is that in Erlang there are no 'break' statements. > 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". Variables are immutable, but a variable can be destroyed (or is it deleted?) and then recreated. Also there are Maps, which allow their contents to be changed in an imperative fashion. Disclaimer: I am not an Erlang expert. I did take the time to read a complete Erlang tutorial, so I think my statements above are right, but it's possible I misunderstood or that there are some subtleties that I missed. > In so many other programming languages, we take it for granted > that the values of variables can change during the program > execution. I think that's true only for people who haven't been exposed to modern functional languages such as OCaml or Haskell (or some other exotic languages that are not used very widely). It's interesting to note that C++ is inching slowly in the directions pioneered in the ML-inspired languages.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-03-14 14:13 -0700 |
| Message-ID | <86o7ov6noo.fsf@linuxsc.com> |
| In reply to | #89707 |
kalevi@kolttonen.fi (Kalevi Kolttonen) writes: > There is this saying "You can write C in any language", [...] I don't remember hearing that saying before, but it is way off the mark. How C deals with indexing and pointer arithmetic causes almost every other language to be a poor venue for writing C.
[toc] | [prev] | [next] | [standalone]
| From | kalevi@kolttonen.fi (Kalevi Kolttonen) |
|---|---|
| Date | 2023-03-14 21:53 +0000 |
| Message-ID | <tuqqbt$h90r$1@dont-email.me> |
| In reply to | #89765 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > kalevi@kolttonen.fi (Kalevi Kolttonen) writes: > >> There is this saying "You can write C in any language", [...] > > I don't remember hearing that saying before, but it is way off > the mark. How C deals with indexing and pointer arithmetic > causes almost every other language to be a poor venue for > writing C. I guess the main point there is just that you can do *traditional procedural* programming in many languages. The intention is not to suggest that you can use all the features of C in other languages. As far as I understand it, you could as well say "You can write Pascal in any language" and the core meaning of this saying would not change. If you want to write in Erlang, the procedural paradigm does not get you very far at all. Of course any programming background helps, since all programming depends on analytical and logical thinking. br, KK
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-04 23:21 -0700 |
| Message-ID | <867cuq7st5.fsf@linuxsc.com> |
| In reply to | #89768 |
kalevi@kolttonen.fi (Kalevi Kolttonen) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> kalevi@kolttonen.fi (Kalevi Kolttonen) writes: >> >>> There is this saying "You can write C in any language", [...] >> >> I don't remember hearing that saying before, but it is way off >> the mark. How C deals with indexing and pointer arithmetic >> causes almost every other language to be a poor venue for >> writing C. > > I guess the main point there is just that you can do > *traditional procedural* programming in many languages. > > The intention is not to suggest that you can use all > the features of C in other languages. As far as I understand > it, you could as well say "You can write Pascal in any language" > and the core meaning of this saying would not change. > > If you want to write in Erlang, the procedural paradigm does > not get you very far at all. Of course any programming > background helps, since all programming depends on analytical > and logical thinking. Back in the day the saying was "You can write FORTRAN in any language." This epigram does have a nice ring to it, but it wasn't true even in the 1960s, e.g., Lisp or APL, among others. Regarding Erlang, AFAICT the biggest impediment to writing FORTRAN in Erlang is that Erlang doesn't have arrays. Erlang also doesn't have the common procedural iterative control structures, but it isn't hard to emulate those by writing functions that take closures. Simple assignment can be done using Erlang's imperative map/dictionary (don't recall what name Erlang uses for this) facility. I think it isn't too hard to think and write procedurally in Erlang, if one chooses to do so. Granted, most people writing Erlang don't do that, but that is not due to inherent limitations in the language. It would be harder, for example, to think and write procedurally in APL.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-05 08:44 -0700 |
| Message-ID | <7782d85c-eefd-430b-a8ab-a6879486890cn@googlegroups.com> |
| In reply to | #89915 |
On Wednesday, April 5, 2023 at 2:21:46 AM UTC-4, Tim Rentsch wrote: ... > not due to inherent limitations in the language. It would be > harder, for example, to think and write procedurally in APL. I'm curious about your basis for making that statement. APL was my second computer language, after Fortran I (sic), in the mid 1970's. I was hired for my first full-time job in the early 80's because of my knowledge of APL (though I made negligible use of that knowledge, since I could never extract from my boss a sufficiently detailed explanation of what the APL project was supposed to do - I ended up spending most of my time there on non-APL projects). I haven't used it much since then, but contrary to APL's reputation as a write-only computer language, I can still read with understanding programs that I wrote at that time. And what I remember about how APL works was basically procedural. I'm curious - has APL changed significantly from what I learned, or did I not even notice it's non- procedural features?
[toc] | [prev] | [next] | [standalone]
| From | legalize+jeeves@mail.xmission.com (Richard) |
|---|---|
| Date | 2023-04-05 15:47 +0000 |
| Message-ID | <u0k57c$20flr$1@news.xmission.com> |
| In reply to | #89923 |
[Please do not mail me a copy of your followup]
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> spake the secret code
<7782d85c-eefd-430b-a8ab-a6879486890cn@googlegroups.com> thusly:
>I haven't used it much since then, but contrary to APL's reputation as
>a write-only computer language, [...]
There is only one true write-only language.
TECO macros :-)
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-04-05 16:33 +0000 |
| Message-ID | <pphXL.1286065$gGD7.421597@fx11.iad> |
| In reply to | #89925 |
legalize+jeeves@mail.xmission.com (Richard) writes: >[Please do not mail me a copy of your followup] > >"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> spake the secret code ><7782d85c-eefd-430b-a8ab-a6879486890cn@googlegroups.com> thusly: > >>I haven't used it much since then, but contrary to APL's reputation as >>a write-only computer language, [...] > >There is only one true write-only language. > >TECO macros :-) I nominate perl.
[toc] | [prev] | [next] | [standalone]
| From | richardthiebaud <thiebauddick2@aol.com> |
|---|---|
| Date | 2023-04-05 12:53 -0400 |
| Message-ID | <u0k92d$3v96l$1@dont-email.me> |
| In reply to | #89927 |
On 4/5/23 12:33, Scott Lurndal wrote: > legalize+jeeves@mail.xmission.com (Richard) writes: >> [Please do not mail me a copy of your followup] >> >> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> spake the secret code >> <7782d85c-eefd-430b-a8ab-a6879486890cn@googlegroups.com> thusly: >> >>> I haven't used it much since then, but contrary to APL's reputation as >>> a write-only computer language, [...] >> >> There is only one true write-only language. >> >> TECO macros :-) > > I nominate perl. Perl can be written to be quite readable.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-04-05 17:19 +0000 |
| Message-ID | <_4iXL.1286068$gGD7.382229@fx11.iad> |
| In reply to | #89928 |
richardthiebaud <thiebauddick2@aol.com> writes: >On 4/5/23 12:33, Scott Lurndal wrote: >> legalize+jeeves@mail.xmission.com (Richard) writes: >>> [Please do not mail me a copy of your followup] >>> >>> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> spake the secret code >>> <7782d85c-eefd-430b-a8ab-a6879486890cn@googlegroups.com> thusly: >>> >>>> I haven't used it much since then, but contrary to APL's reputation as >>>> a write-only computer language, [...] >>> >>> There is only one true write-only language. >>> >>> TECO macros :-) >> >> I nominate perl. > >Perl can be written to be quite readable. can != is.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-04-05 13:47 -0700 |
| Message-ID | <ec66ca6f-45ba-4e03-944c-cfd670eeda5en@googlegroups.com> |
| In reply to | #89928 |
On Wednesday, 5 April 2023 at 17:53:53 UTC+1, richardthiebaud wrote: > On 4/5/23 12:33, Scott Lurndal wrote: > > legaliz...@mail.xmission.com (Richard) writes: > >> [Please do not mail me a copy of your followup] > >> > >> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> spake the secret code > >> <7782d85c-eefd-430b...@googlegroups.com> thusly: > >> > >>> I haven't used it much since then, but contrary to APL's reputation as > >>> a write-only computer language, [...] > >> > >> There is only one true write-only language. > >> > >> TECO macros :-) > > > > I nominate perl. > Perl can be written to be quite readable. > You don't have to use regular expressions in your Perl scripts. But you're going against the genius of the language if you don't. And regular expressions can rapidly become too complicated to read easily.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-04-06 08:12 +0000 |
| Message-ID | <u0lusj$9hsq$1@dont-email.me> |
| In reply to | #89932 |
On Wed, 5 Apr 2023 13:47:55 -0700 (PDT) Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: >On Wednesday, 5 April 2023 at 17:53:53 UTC+1, richardthiebaud wrote: >> On 4/5/23 12:33, Scott Lurndal wrote: >> > legaliz...@mail.xmission.com (Richard) writes: >> >> [Please do not mail me a copy of your followup] >> >> >> >> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> spake the >secret code >> >> <7782d85c-eefd-430b...@googlegroups.com> thusly: >> >> >> >>> I haven't used it much since then, but contrary to APL's reputation as >> >>> a write-only computer language, [...] >> >> >> >> There is only one true write-only language. >> >> >> >> TECO macros :-) >> > >> > I nominate perl. >> Perl can be written to be quite readable. >> >You don't have to use regular expressions in your Perl scripts. >But you're going against the genius of the language if you don't. >And regular expressions can rapidly become too complicated to read >easily. And rather brittle IME. I'd sooner see a few lines of code than a complicated regex as its easier to debug when things go wrong.
[toc] | [prev] | [next] | [standalone]
| From | Daniel <danielaparker@gmail.com> |
|---|---|
| Date | 2023-04-06 05:23 -0700 |
| Message-ID | <354c37de-7e72-47b7-9ba1-a7201babad40n@googlegroups.com> |
| In reply to | #89936 |
On Thursday, April 6, 2023 at 4:12:17 AM UTC-4, Mut...@dastardlyhq.com wrote: > And rather brittle IME. I'd sooner see a few lines of code than a complicated > regex as its easier to debug when things go wrong. Agreed. For instance, I don't see the attraction of using regex's to validate things like phone numbers, IPv4 addresses, email addresses, and the like. If validation fails, you don't get a precise error message. If you implement a validation function as a simple state machine that follows the spec, it's much easier to be certain that you've covered off all the states, and should validation fail, you have the exact position in the string where validation failed. Daniel
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-04-06 08:09 +0000 |
| Message-ID | <u0luon$9h84$1@dont-email.me> |
| In reply to | #89927 |
On Wed, 05 Apr 2023 16:33:25 GMT scott@slp53.sl.home (Scott Lurndal) wrote: >legalize+jeeves@mail.xmission.com (Richard) writes: >>[Please do not mail me a copy of your followup] >> >>"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> spake the >secret code >><7782d85c-eefd-430b-a8ab-a6879486890cn@googlegroups.com> thusly: >> >>>I haven't used it much since then, but contrary to APL's reputation as >>>a write-only computer language, [...] >> >>There is only one true write-only language. >> >>TECO macros :-) > >I nominate perl. Especially when someone has gone nuts with the regex's.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-07-20 10:02 -0700 |
| Message-ID | <86lefazfbx.fsf@linuxsc.com> |
| In reply to | #89923 |
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes: > On Wednesday, April 5, 2023 at 2:21:46?AM UTC-4, Tim Rentsch wrote: > ... > >> not due to inherent limitations in the language. It would be >> harder, for example, to think and write procedurally in APL. > > I'm curious about your basis for making that statement. APL was my > second computer language, after Fortran I (sic), in the mid 1970's. I > was hired for my first full-time job in the early 80's because of my > knowledge of APL (though I made negligible use of that knowledge, > since I could never extract from my boss a sufficiently detailed > explanation of what the APL project was supposed to do - I ended up > spending most of my time there on non-APL projects). > I haven't used it much since then, but contrary to APL's reputation as > a write-only computer language, I can still read with understanding > programs that I wrote at that time. And what I remember about how > APL works was basically procedural. I'm curious - has APL changed > significantly from what I learned, or did I not even notice it's non- > procedural features? APL is definitely an imperative language. On the other hand, APL is not very good for writing programs in the way that they would be written in, for example, C. Imperative is not the same as procedural. Assembly language, for example, is certainly an imperative language, but not really suited to procedural programming. APL does have procedures, but they are not up to even the level of procedural programming offered by Pascal. It isn't that it's impossible to do procedural programming in APL, but the impedance mismatch makes it feel like swimming in molasses. Further explanation in my response to Ben Bacarisse in this thread.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-04-05 21:04 +0100 |
| Message-ID | <87ttxu5c4h.fsf@bsb.me.uk> |
| In reply to | #89915 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > ... I think it isn't too hard to > think and write procedurally in Erlang, if one chooses to do so. > Granted, most people writing Erlang don't do that, but that is > not due to inherent limitations in the language. It would be > harder, for example, to think and write procedurally in APL. Sounds odd, but then I don't know Erlang at all well. APL has assignable variables and branching. What is the major barrier to writing procedurally in APL? I'm not disputing that one could think and write procedurally in Erlang (I really don't know), but I'd say that Haskell would a better example of a language that makes it hard. I think you'd have to code up the denotational semantics of small procedural language to write procedural in Haskell. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-07-20 09:52 -0700 |
| Message-ID | <86pm4mzft2.fsf@linuxsc.com> |
| In reply to | #89931 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> ... I think it isn't too hard to >> think and write procedurally in Erlang, if one chooses to do so. >> Granted, most people writing Erlang don't do that, but that is >> not due to inherent limitations in the language. It would be >> harder, for example, to think and write procedurally in APL. > > Sounds odd, but then I don't know Erlang at all well. APL has > assignable variables and branching. What is the major barrier to > writing procedurally in APL? > > I'm not disputing that one could think and write procedurally in Erlang > (I really don't know), but I'd say that Haskell would a better example > of a language that makes it hard. I think you'd have to code up the > denotational semantics of small procedural language to write procedural > in Haskell. Disclaimer: I have some experience programming in both APL and Haskell, but am by no means an expert in either language. I'm not sure whether it would be harder to write procedural-style code in Haskell than in APL. Whether it is or not, my intention was only to offer one example, not necessarily the best example. As to why APL is hard to write in procedurally, I would say it has poor support for some of the important elements of procedural languages. Control flow in APL is clumsy. APL does allow procedures, but they are limited compared to, for example, functions in C. Much of the programming done in procedural languages is used to operate on data structures, but APL doesn't have good facilities for general data structures. To explain this another way, consider any moderately sized C program (1500 lines or more, just to pick a number), and imagine trying to re-write it in APL. Chances are the program would need to be not just re-written but completely re-designed. And the resulting program would very likely not look very procedural-ish. Does this explanation help clarify my statement?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-07-20 21:01 +0100 |
| Message-ID | <87mszqpd1l.fsf@bsb.me.uk> |
| In reply to | #91164 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> ... I think it isn't too hard to >>> think and write procedurally in Erlang, if one chooses to do so. >>> Granted, most people writing Erlang don't do that, but that is >>> not due to inherent limitations in the language. It would be >>> harder, for example, to think and write procedurally in APL. >> >> Sounds odd, but then I don't know Erlang at all well. APL has >> assignable variables and branching. What is the major barrier to >> writing procedurally in APL? >> >> I'm not disputing that one could think and write procedurally in Erlang >> (I really don't know), but I'd say that Haskell would a better example >> of a language that makes it hard. I think you'd have to code up the >> denotational semantics of small procedural language to write procedural >> in Haskell. > > Disclaimer: I have some experience programming in both APL and > Haskell, but am by no means an expert in either language. > > I'm not sure whether it would be harder to write procedural-style > code in Haskell than in APL. Whether it is or not, my intention was > only to offer one example, not necessarily the best example. > > As to why APL is hard to write in procedurally, I would say it has > poor support for some of the important elements of procedural > languages. Control flow in APL is clumsy. APL does allow procedures, > but they are limited compared to, for example, functions in C. Much > of the programming done in procedural languages is used to operate on > data structures, but APL doesn't have good facilities for general data > structures. > > To explain this another way, consider any moderately sized C program > (1500 lines or more, just to pick a number), and imagine trying to > re-write it in APL. Chances are the program would need to be not just > re-written but completely re-designed. And the resulting program > would very likely not look very procedural-ish. > > Does this explanation help clarify my statement? Yes. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c++
csiph-web