Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #85804 > unrolled thread
| Started by | NOSPAM.Alan.Beck@darkrealms.ca (Alan Beck) |
|---|---|
| First post | 2022-08-08 09:43 +0000 |
| Last post | 2022-08-27 23:15 -0700 |
| Articles | 20 on this page of 114 — 19 participants |
Back to article view | Back to comp.lang.c++
To C or not to C++ NOSPAM.Alan.Beck@darkrealms.ca (Alan Beck) - 2022-08-08 09:43 +0000
Re: To C or not to C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-08 20:02 +0300
Re: To C or not to C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-09 05:38 +0000
Re: To C or not to C++ Ralf Fassel <ralfixx@gmx.de> - 2022-08-09 11:07 +0200
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-10 02:25 +0200
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-09 17:52 -0700
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-09 21:39 -0700
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-10 07:45 +0000
Re: To C or not to C++ scott@slp53.sl.home (Scott Lurndal) - 2022-08-10 19:50 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-10 13:13 -0700
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-11 04:29 +0200
Re: To C or not to C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-10 02:41 +0000
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-10 07:39 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-10 10:11 -0700
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-12 08:23 +0000
Re: To C or not to C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-12 12:12 +0000
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-12 14:41 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-12 12:09 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-13 10:28 +0200
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-13 09:37 +0000
Re: To C or not to C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-12 15:55 +0300
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-12 14:43 +0000
Re: To C or not to C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-12 18:07 +0300
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-12 15:14 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-12 12:11 -0700
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-13 09:38 +0000
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-13 17:56 +0200
Re: To C or not to C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-24 11:32 +0300
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-24 11:33 +0100
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-24 04:37 -0700
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-24 13:31 +0100
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-24 14:09 +0000
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-24 15:31 +0100
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-24 14:38 +0000
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-24 15:57 +0100
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-24 10:41 -0700
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-24 21:48 +0100
Re: To C or not to C++ "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-08-25 07:34 +0200
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-25 11:29 +0100
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-25 04:14 -0700
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-25 12:36 +0100
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-25 05:16 -0700
Re: To C or not to C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-25 17:16 +0100
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-25 20:35 +0200
[OT] Bad CS course, no cookie (Was: To C or not to C++) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-25 21:32 +0100
Re: [OT] Bad CS course, no cookie (Was: To C or not to C++) David Brown <david.brown@hesbynett.no> - 2022-08-25 23:16 +0200
Re: [OT] Bad CS course, no cookie Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-26 00:33 +0100
Re: [OT] Bad CS course, no cookie David Brown <david.brown@hesbynett.no> - 2022-08-26 10:39 +0200
Re: [OT] Bad CS course, no cookie Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-26 10:57 +0100
Re: [OT] Bad CS course, no cookie David Brown <david.brown@hesbynett.no> - 2022-08-26 12:49 +0200
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-25 19:56 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-26 10:47 +0200
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-26 02:48 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-26 13:02 +0200
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-26 04:57 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-26 14:55 +0200
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-26 06:20 -0700
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-27 18:44 +0200
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-28 11:30 +0200
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 10:06 -0700
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-25 10:32 -0700
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 11:36 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-25 20:47 +0200
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-26 03:11 +0200
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-25 09:21 +0200
Re: To C or not to C++ scott@slp53.sl.home (Scott Lurndal) - 2022-08-25 12:58 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 10:23 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-25 20:51 +0200
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 12:14 -0700
Re: To C or not to C++ scott@slp53.sl.home (Scott Lurndal) - 2022-08-24 13:56 +0000
Re: To C or not to C++ Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-24 17:18 +0300
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-24 14:25 +0000
Re: To C or not to C++ scott@slp53.sl.home (Scott Lurndal) - 2022-08-12 16:46 +0000
Re: To C or not to C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-15 06:16 +0000
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-15 19:01 +0000
Re: To C or not to C++ Bo Persson <bo@bo-persson.se> - 2022-08-15 22:22 +0200
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-16 08:48 +0200
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-16 19:19 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-16 12:56 -0700
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-17 18:47 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-17 14:49 -0700
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-18 14:49 +0000
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-19 03:10 +0200
Re: To C or not to C++ d thiebaud <thiebauddick2@aol.com> - 2022-08-18 22:12 -0400
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-18 20:08 -0700
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-19 10:39 +0000
Re: To C or not to C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-17 06:45 +0000
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-17 18:48 +0000
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-16 19:16 +0000
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-12 12:03 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-10 10:13 +0200
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-11 04:25 +0200
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-11 01:03 -0700
Re: To C or not to C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-11 08:11 +0000
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-11 13:53 +0200
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-13 04:13 +0200
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-13 21:13 +0200
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-13 12:29 -0700
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-13 13:12 -0700
Re: To C or not to C++ David Brown <david.brown@hesbynett.no> - 2022-08-14 00:44 +0200
Re: To C or not to C++ Öö Tiib <ootiib@hot.ee> - 2022-08-12 02:54 -0700
Re: To C or not to C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-12 12:12 -0700
Re: To C or not to C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-12 16:22 -0700
Re: To C or not to C++ Öö Tiib <ootiib@hot.ee> - 2022-08-12 17:49 -0700
Re: To C or not to C++ Manfred <noname@add.invalid> - 2022-08-13 03:16 +0200
Re: To C or not to C++ Öö Tiib <ootiib@hot.ee> - 2022-08-13 09:08 -0700
Re: To C or not to C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-15 14:44 -0700
Re: To C or not to C++ Ralf Fassel <ralfixx@gmx.de> - 2022-08-10 12:06 +0200
Re: To C or not to C++ Juha Nieminen <nospam@thanks.invalid> - 2022-08-11 07:04 +0000
Re: To C or not to C++ Bonita Montero <Bonita.Montero@gmail.com> - 2022-08-09 12:31 +0200
Re: To C or not to C++ Muttley@dastardlyhq.com - 2022-08-09 15:59 +0000
Re: To C or not to C++ Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-08-19 04:09 -0700
Re: To C or not to C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-08-13 12:17 -0700
Re: To C or not to C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-08-27 23:15 -0700
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-25 12:36 +0100 |
| Message-ID | <87y1vcwo4q.fsf@bsb.me.uk> |
| In reply to | #86057 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Thursday, 25 August 2022 at 11:29:26 UTC+1, Ben Bacarisse wrote: >> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes: >> >> > On 24 Aug 2022 22:48, Ben Bacarisse wrote: >> >> Keith Thompson <Keith.S.T...@gmail.com> writes: >> >> >>> C23 will make bool, false, and true keywords. >> >>> >> >>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf >> >> I didn't know that, but I am not surprised because of the new course C >> >> is taking. I hope it does not run aground... >> > >> > It's apparently the same as with C++: not very practical academics in >> > charge, >> Who, in particular, do you mean? >> >> > expressing their academic ideals. >> >> In what way is making bool a type keyword expressing an academic ideal? >> My thoughts were the reverse: the "purist" route -- of only using >> already reserved identifiers -- has been ditched. >> > Low level, practical programmers tend to think of programming in terms > of manipulating bits in memory. Are you equating the two or just ignoring high-level practical programmers? Anyway, as always, I am curious about how you know this. > Academic computer science people tend to think of programming in terms > of manipulating symbols. I suspect this is simply self-defining. Any academic CS person who, say, designs a RISK architecture or a low-level network protocol, will be excused and be deemed to be practical, yes? > So a practical programmer will tend to say "set that bit to indicate > the light is on", a computer scientist will say "bind that variable to > true/false to indicate the status of the light". I think you are making this us. CS people who set bits to indicate things just like everyone else. Does any of this have anything to do with the C standards apparent change of direct to incorporate C++ features at the expense of old code? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-08-25 05:16 -0700 |
| Message-ID | <6aeee22b-9030-481e-86cb-4a47c6746f0bn@googlegroups.com> |
| In reply to | #86058 |
On Thursday, 25 August 2022 at 12:37:11 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > On Thursday, 25 August 2022 at 11:29:26 UTC+1, Ben Bacarisse wrote: > >> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes: > >> > >> > On 24 Aug 2022 22:48, Ben Bacarisse wrote: > >> >> Keith Thompson <Keith.S.T...@gmail.com> writes: > >> > >> >>> C23 will make bool, false, and true keywords. > >> >>> > >> >>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf > >> >> I didn't know that, but I am not surprised because of the new course C > >> >> is taking. I hope it does not run aground... > >> > > >> > It's apparently the same as with C++: not very practical academics in > >> > charge, > >> Who, in particular, do you mean? > >> > >> > expressing their academic ideals. > >> > >> In what way is making bool a type keyword expressing an academic ideal? > >> My thoughts were the reverse: the "purist" route -- of only using > >> already reserved identifiers -- has been ditched. > >> > > Low level, practical programmers tend to think of programming in terms > > of manipulating bits in memory. > Are you equating the two or just ignoring high-level practical > programmers? > > Anyway, as always, I am curious about how you know this. > I used to be a games programmer. I gave it up to do a degree which led to a PhD. Whilst I didn't do computer science, and the PhD was in protein folding, it did involve quite a bit of interaction with computer scientists. So I'm reasonably familiar with both worlds. > > > Academic computer science people tend to think of programming in terms > > of manipulating symbols. > I suspect this is simply self-defining. Any academic CS person who, > say, designs a RISK architecture or a low-level network protocol, will > be excused and be deemed to be practical, yes? > There's an overlap between computer science, practical programming, and electronic engineering. But they're not the same. > > Does any of this have anything to do with the C standards apparent > change of direct to incorporate C++ features at the expense of old code? > Computer science people would tend to think that it's important to have a boolean type, because a lot of logic works on values which are inherently true or false. Practical programmers would tend to say that it's not, because most hardware won't support it. You will of course find exceptions.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-25 17:16 +0100 |
| Message-ID | <871qt4wb6l.fsf@bsb.me.uk> |
| In reply to | #86060 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Thursday, 25 August 2022 at 12:37:11 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >> > On Thursday, 25 August 2022 at 11:29:26 UTC+1, Ben Bacarisse wrote: >> >> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes: >> >> >> >> > On 24 Aug 2022 22:48, Ben Bacarisse wrote: >> >> >> Keith Thompson <Keith.S.T...@gmail.com> writes: >> >> >> >> >>> C23 will make bool, false, and true keywords. >> >> >>> >> >> >>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf >> >> >> I didn't know that, but I am not surprised because of the new course C >> >> >> is taking. I hope it does not run aground... >> >> > >> >> > It's apparently the same as with C++: not very practical academics in >> >> > charge, >> >> Who, in particular, do you mean? >> >> >> >> > expressing their academic ideals. >> >> >> >> In what way is making bool a type keyword expressing an academic ideal? >> >> My thoughts were the reverse: the "purist" route -- of only using >> >> already reserved identifiers -- has been ditched. >> >> >> > Low level, practical programmers tend to think of programming in terms >> > of manipulating bits in memory. >> Are you equating the two or just ignoring high-level practical >> programmers? >> >> Anyway, as always, I am curious about how you know this. >> > I used to be a games programmer. I gave it up to do a degree which led > to a PhD. Whilst I didn't do computer science, and the PhD was in > protein folding, it did involve quite a bit of interaction with > computer scientists. So I'm reasonably familiar with both worlds. OK. So it's your based on your experience. My experience is different. >> > Academic computer science people tend to think of programming in terms >> > of manipulating symbols. >> I suspect this is simply self-defining. Any academic CS person who, >> say, designs a RISK architecture or a low-level network protocol, will >> be excused and be deemed to be practical, yes? >> > There's an overlap between computer science, practical programming, and > electronic engineering. But they're not the same. Sure. In fact, any academic who may /think/ they are a computer scientist will be excluded from your definition if they lean towards something you think is practical. You can't really be wrong, can you? >> Does any of this have anything to do with the C standards apparent >> change of direct to incorporate C++ features at the expense of old code? >> > Computer science people would tend to think that it's important to have > a boolean type, because a lot of logic works on values which are inherently > true or false. C already has a Boolean type. The question was whether renaming it bool is the result of fanatical academic interference in the standard. That's what I was asking about. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-25 20:35 +0200 |
| Message-ID | <te8fea$3n8bn$1@dont-email.me> |
| In reply to | #86064 |
On 25/08/2022 18:16, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Thursday, 25 August 2022 at 12:37:11 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Thursday, 25 August 2022 at 11:29:26 UTC+1, Ben Bacarisse wrote:
>>>>> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes:
>>>>>
>>>>>> On 24 Aug 2022 22:48, Ben Bacarisse wrote:
>>>>>>> Keith Thompson <Keith.S.T...@gmail.com> writes:
>>>>>
>>>>>>>> C23 will make bool, false, and true keywords.
>>>>>>>>
>>>>>>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf
>>>>>>> I didn't know that, but I am not surprised because of the new course C
>>>>>>> is taking. I hope it does not run aground...
>>>>>>
>>>>>> It's apparently the same as with C++: not very practical academics in
>>>>>> charge,
>>>>> Who, in particular, do you mean?
>>>>>
A large proportion of the new features in C23 seem to have originated
with or been promoted by one person - Jens Gustedt. I don't know if he
should be considered an "academic", or a "practical programmer", or
both, or neither. But while most of the C standards committee tend to
be quite anonymous and avoid making changes to the standard (they all
have day jobs, after all), he seems to be working hard to change C and
bring it forward. People can have different opinions on whether that's
a good idea or not, and about the particular changes he has proposed,
but I think he is due a large share of the credit for C23.
>> Computer science people would tend to think that it's important to have
>> a boolean type, because a lot of logic works on values which are inherently
>> true or false.
>
When I did theoretical computer science at university, we used whatever
type was convenient and appropriate for the task at hand (and more often
than not it was "alpha" or "A", rather than any specific type). And
that was for "there's no need to test the code, because we prove it is
correct on the blackboard" programming, which is as academic as it comes.
In my job as a practical programmer - mostly low-level, but sometimes
high-level (however those terms might be defined), I use whatever type
is convenient and appropriate for the task at hand. And "bool" is one
of the most common types I use.
For my own coding, I don't really care whether "bool" is a typedef for
"_Bool" or a keyword in itself, nor do I care if "true" and "false" are
keywords, macros, enums, or whatever, as long as they work correctly.
However, if these are all keywords in a language, then it gives me a
guarantee that code from elsewhere uses these types and values in
exactly the same way. I don't need to check that the code I import has
defined "typedef enum { uninitialised, true, false } bool;", or some
other incompatible fun. So from that viewpoint, having these as
keywords can be helpful in practice.
But that's /my/ experience - Malcolm's is apparently different.
> C already has a Boolean type. The question was whether renaming it bool
> is the result of fanatical academic interference in the standard.
> That's what I was asking about.
>
I would have thought there were other changes in C23 (and even more so,
some of the proposals that didn't make it into the standard) were better
candidates for the title of "fanatical academic interference". But
perhaps Malcolm sees things differently.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-25 21:32 +0100 |
| Subject | [OT] Bad CS course, no cookie (Was: To C or not to C++) |
| Message-ID | <87pmgoukrd.fsf_-_@bsb.me.uk> |
| In reply to | #86072 |
David Brown <david.brown@hesbynett.no> writes: > When I did theoretical computer science at university, we used > whatever type was convenient and appropriate for the task at hand (and > more often than not it was "alpha" or "A", rather than any specific > type). And that was for "there's no need to test the code, because we > prove it is correct on the blackboard" programming, which is as > academic as it comes. Care to name and shame? That's an extraordinary thing to say (if it was not a joke)? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-25 23:16 +0200 |
| Subject | Re: [OT] Bad CS course, no cookie (Was: To C or not to C++) |
| Message-ID | <te8os1$3o329$1@dont-email.me> |
| In reply to | #86080 |
On 25/08/2022 22:32, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> When I did theoretical computer science at university, we used >> whatever type was convenient and appropriate for the task at hand (and >> more often than not it was "alpha" or "A", rather than any specific >> type). And that was for "there's no need to test the code, because we >> prove it is correct on the blackboard" programming, which is as >> academic as it comes. > > Care to name and shame? That's an extraordinary thing to say (if it was > not a joke)? > "Beware of bugs in the above code; I have only proved it correct, not tried it." (Donald Knuth) Several of our courses covered provable code, with mathematical derivation from specifications through to code. The "programming" language was somewhat idealised and limited and had no implementation - the idea was that if you wanted to use the code, you'd translate the derived algorithm into a practical real language. So if you want to look at sorting algorithms, for example, you start with a list of items of some type (the type does not matter), and a post condition that the list is sorted. You work through step by step, with each step justified mathematically, until you have "executable" code at the end. If you have made no mistakes underway, you have a proven correct implementation of the specifications - not just one that has passed some test cases. (You can look up the book "Programming from Specifications" by Carroll Morgan, which is freely available.) I think the only programming language that we were actually taught was a functional programming language very much like Haskell. When we had practical work that involved actual programming on computers, we were expected to learn whatever language the course tutor thought appropriate for the task - C, Modula 2, and Occam, perhaps more.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-26 00:33 +0100 |
| Subject | Re: [OT] Bad CS course, no cookie |
| Message-ID | <87fshjaof5.fsf@bsb.me.uk> |
| In reply to | #86081 |
David Brown <david.brown@hesbynett.no> writes: > On 25/08/2022 22:32, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> When I did theoretical computer science at university, we used >>> whatever type was convenient and appropriate for the task at hand (and >>> more often than not it was "alpha" or "A", rather than any specific >>> type). And that was for "there's no need to test the code, because we >>> prove it is correct on the blackboard" programming, which is as >>> academic as it comes. >> >> Care to name and shame? That's an extraordinary thing to say (if it was >> not a joke)? > > "Beware of bugs in the above code; I have only proved it correct, not > tried it." (Donald Knuth) A well-known quote meaning pretty much the opposite of the remark that piqued my interest. > Several of our courses covered provable code, with mathematical > derivation from specifications through to code. The "programming" > language was somewhat idealised and limited and had no implementation > - the idea was that if you wanted to use the code, you'd translate the > derived algorithm into a practical real language. > > So if you want to look at sorting algorithms, for example, you start > with a list of items of some type (the type does not matter), and a > post condition that the list is sorted. You work through step by > step, with each step justified mathematically, until you have > "executable" code at the end. If you have made no mistakes underway, > you have a proven correct implementation of the specifications - not > just one that has passed some test cases. > > (You can look up the book "Programming from Specifications" by Carroll > Morgan, which is freely available.) There are few books on that sort of topic. Hoare's comes to mind. > I think the only programming language that we were actually taught was > a functional programming language very much like Haskell. When we had > practical work that involved actual programming on computers, we were > expected to learn whatever language the course tutor thought > appropriate for the task - C, Modula 2, and Occam, perhaps more. You could just have said "no"! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-26 10:39 +0200 |
| Subject | Re: [OT] Bad CS course, no cookie |
| Message-ID | <tea0r9$3u9hj$1@dont-email.me> |
| In reply to | #86082 |
On 26/08/2022 01:33, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 25/08/2022 22:32, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> When I did theoretical computer science at university, we used >>>> whatever type was convenient and appropriate for the task at hand (and >>>> more often than not it was "alpha" or "A", rather than any specific >>>> type). And that was for "there's no need to test the code, because we >>>> prove it is correct on the blackboard" programming, which is as >>>> academic as it comes. >>> >>> Care to name and shame? That's an extraordinary thing to say (if it was >>> not a joke)? >> >> "Beware of bugs in the above code; I have only proved it correct, not >> tried it." (Donald Knuth) > > A well-known quote meaning pretty much the opposite of the remark that > piqued my interest. Knuth's comment was (AFAIUI) intended to provoke thought - it is not so much a warning specifically against untested code, as a reminder that there is no simple answer to knowing when code is correct. Proof of correctness alone is not enough, as people can make mistakes or invalid assumptions in their proof (especially in non-trivial cases where proofs are necessarily long and complex). There is also the real risk that there are problems in the original specification, which are not noticed until testing the code. On the other hand, testing is not enough - it can only prove the existence of bugs, not their absence. My remark was not a joke as such - it was intended in the same manner as Knuth's quotation. > >> Several of our courses covered provable code, with mathematical >> derivation from specifications through to code. The "programming" >> language was somewhat idealised and limited and had no implementation >> - the idea was that if you wanted to use the code, you'd translate the >> derived algorithm into a practical real language. >> >> So if you want to look at sorting algorithms, for example, you start >> with a list of items of some type (the type does not matter), and a >> post condition that the list is sorted. You work through step by >> step, with each step justified mathematically, until you have >> "executable" code at the end. If you have made no mistakes underway, >> you have a proven correct implementation of the specifications - not >> just one that has passed some test cases. >> >> (You can look up the book "Programming from Specifications" by Carroll >> Morgan, which is freely available.) > > There are few books on that sort of topic. Hoare's comes to mind. Yes, he has written a few. "Communicating Sequential Processes" was another on our required reading list. The lecturers rarely recommended their own books directly, but they were very fond of recommending each other's books! > >> I think the only programming language that we were actually taught was >> a functional programming language very much like Haskell. When we had >> practical work that involved actual programming on computers, we were >> expected to learn whatever language the course tutor thought >> appropriate for the task - C, Modula 2, and Occam, perhaps more. > > You could just have said "no"! > You've known me on Usenet for quite some time - when have I ever been able to give a one word answer? :-)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-08-26 10:57 +0100 |
| Subject | Re: [OT] Bad CS course, no cookie |
| Message-ID | <87k06v8gzp.fsf@bsb.me.uk> |
| In reply to | #86090 |
David Brown <david.brown@hesbynett.no> writes: > On 26/08/2022 01:33, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 25/08/2022 22:32, Ben Bacarisse wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>> >>>>> When I did theoretical computer science at university, we used >>>>> whatever type was convenient and appropriate for the task at hand (and >>>>> more often than not it was "alpha" or "A", rather than any specific >>>>> type). And that was for "there's no need to test the code, because we >>>>> prove it is correct on the blackboard" programming, which is as >>>>> academic as it comes. > Knuth's comment was (AFAIUI) intended to provoke thought <...> > My remark was not a joke as such - it was intended in the same manner > as Knuth's quotation. Then I misunderstood. I thought your remark was intended to characterise or at least suggest an attitude that was common or accepted in the instituting you attended. Hence my curiosity as to which. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-26 12:49 +0200 |
| Subject | Re: [OT] Bad CS course, no cookie |
| Message-ID | <tea8g3$3uvq1$1@dont-email.me> |
| In reply to | #86094 |
On 26/08/2022 11:57, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 26/08/2022 01:33, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 25/08/2022 22:32, Ben Bacarisse wrote: >>>>> David Brown <david.brown@hesbynett.no> writes: >>>>> >>>>>> When I did theoretical computer science at university, we used >>>>>> whatever type was convenient and appropriate for the task at hand (and >>>>>> more often than not it was "alpha" or "A", rather than any specific >>>>>> type). And that was for "there's no need to test the code, because we >>>>>> prove it is correct on the blackboard" programming, which is as >>>>>> academic as it comes. > >> Knuth's comment was (AFAIUI) intended to provoke thought > <...> >> My remark was not a joke as such - it was intended in the same manner >> as Knuth's quotation. > > Then I misunderstood. I thought your remark was intended to > characterise or at least suggest an attitude that was common or accepted > in the instituting you attended. Hence my curiosity as to which. > Ah, you thought I was taught coding by people who didn't believe code should be tested? I see your point now. The degree was "Mathematics and computation" - it was not a programming course, or course in any one language, or even a "software engineering" course. So there was a strong emphasis on viewing the programming as mathematics, and applying mathematical styles to code development. The aim was to have an understanding of how code relates to specifications and how you can be sure it is correct. Then details such as programming languages, structure, testing methodology, etc., are just practical details to fill in later as appropriate.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-08-25 19:56 -0700 |
| Message-ID | <bb5029bf-012e-45e7-ae2a-3eae95b0668en@googlegroups.com> |
| In reply to | #86072 |
On Thursday, 25 August 2022 at 19:36:10 UTC+1, David Brown wrote: > On 25/08/2022 18:16, Ben Bacarisse wrote: > > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > A large proportion of the new features in C23 seem to have originated > with or been promoted by one person - Jens Gustedt. I don't know if he > should be considered an "academic", or a "practical programmer", or > both, or neither. > I looked him up. He's very clearly what I would call an academic rather than a practical programmer. That doesn't mean that he's never produced a piece of code that has run "for real" in his life. But I cannot find a single reference to any commercial software he has worked on. I don't think he's ever held a job as programmer. He has produced some hydrological software (determining where the water goes when it rains). I haven't looked at it in detail and I don't know much about the field. But I don't think the software is designed to be downloaded by the civil engineer and used to help build reservoirs. It's more a proof of concept. The algorithms can be taken by someone else, reimplemented, and used as the core of a commercial hydrology package. Of course he's a more highly educated, and more able man than the average commercial programmer. I'm not trying to say "academic bad, practical good". But it's not the same thing.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-26 10:47 +0200 |
| Message-ID | <tea1al$3uasj$1@dont-email.me> |
| In reply to | #86087 |
On 26/08/2022 04:56, Malcolm McLean wrote: > On Thursday, 25 August 2022 at 19:36:10 UTC+1, David Brown wrote: >> On 25/08/2022 18:16, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>> >> A large proportion of the new features in C23 seem to have originated >> with or been promoted by one person - Jens Gustedt. I don't know if he >> should be considered an "academic", or a "practical programmer", or >> both, or neither. >> > I looked him up. He's very clearly what I would call an academic rather than a > practical programmer. That doesn't mean that he's never produced a piece of > code that has run "for real" in his life. But I cannot find a single reference to > any commercial software he has worked on. I don't think he's ever held a job > as programmer. > If you look me up (and good luck with that - my name is so common I might as well be anonymous) you'll find no references to commercial software that I have worked on, and probably no more than obscure references in a local Norwegian newspaper concerning what jobs I have had. Yet I have over 25 years of professional software development practice. So your search results have almost no worth at all, as far as I can see. > He has produced some hydrological software (determining where the water goes > when it rains). I haven't looked at it in detail and I don't know much about the field. > But I don't think the software is designed to be downloaded by the civil engineer > and used to help build reservoirs. It's more a proof of concept. The algorithms can > be taken by someone else, reimplemented, and used as the core of a commercial > hydrology package. > > Of course he's a more highly educated, and more able man than the average > commercial programmer. I'm not trying to say "academic bad, practical good". > But it's not the same thing. You do seem to be making a distinction here that others (myself, at least) do not see. I've known people who work as "practical" programmers who are interesting in the theory, academics who do practical work, and all sorts of mixes - there is so much "grey area" that there is no black or white. All you can really say is that since C is a very practical language, and so completely unsuited to purely theoretical computer science, that anyone interested in the C language is interested in the practical use in real programs. If you want more information on Jens Gustedt, read his blog.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-08-26 02:48 -0700 |
| Message-ID | <8f7e6693-8001-4e30-b502-94883ae308c3n@googlegroups.com> |
| In reply to | #86091 |
On Friday, 26 August 2022 at 09:47:36 UTC+1, David Brown wrote: > On 26/08/2022 04:56, Malcolm McLean wrote: > > On Thursday, 25 August 2022 at 19:36:10 UTC+1, David Brown wrote: > >> On 25/08/2022 18:16, Ben Bacarisse wrote: > >>> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >>> > >> A large proportion of the new features in C23 seem to have originated > >> with or been promoted by one person - Jens Gustedt. I don't know if he > >> should be considered an "academic", or a "practical programmer", or > >> both, or neither. > >> > > I looked him up. He's very clearly what I would call an academic rather than a > > practical programmer. That doesn't mean that he's never produced a piece of > > code that has run "for real" in his life. But I cannot find a single reference to > > any commercial software he has worked on. I don't think he's ever held a job > > as programmer. > > > If you look me up (and good luck with that - my name is so common I > might as well be anonymous) you'll find no references to commercial > software that I have worked on, and probably no more than obscure > references in a local Norwegian newspaper concerning what jobs I have > had. Yet I have over 25 years of professional software development > practice. > You don't hold an academic post at a university. Pretty much everybody who holds an academic post at university puts up online some bit of information listing their research interests, and a bit of biographical detail. > > So your search results have almost no worth at all, as far as I can see. > If Gustedt had done significant work on commercial software, I would have expected it to be listed. You can't prove 100% that he did such work but didn't think it was interesting enough to mention, but it's not likely. > > You do seem to be making a distinction here that others (myself, at > least) do not see. I've known people who work as "practical" > programmers who are interesting in the theory, academics who do > practical work, and all sorts of mixes - there is so much "grey area" > that there is no black or white. > There are grey areas, because problems which are theoretically interesting are also sometimes of practical use. However one fairly unambiguous test is "is someone paying money for the right to execute this piece of code?". If the answer is "yes", it must be practical code. If the answer is "no", it might still be practical, because not every activity that adds value involves economic exchange, but likely it's not. > > All you can really say is that since C is a very practical language, and > so completely unsuited to purely theoretical computer science, that > anyone interested in the C language is interested in the practical use > in real programs. > That is another rule of thumb. If you use C, the code can be deployed in a program designed for mass market release. If you use a language like Scheme, it's much harder to get the code out into real world use. However, as you say, there are grey areas, and not all C is intended for deployment in commercial programs. > > If you want more information on Jens Gustedt, read his blog. > I've had a look at it. He's an impressive person. I don't want to say anything as crude as "theoretical work bad, practical work good".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-26 13:02 +0200 |
| Message-ID | <tea990$3v29f$1@dont-email.me> |
| In reply to | #86093 |
On 26/08/2022 11:48, Malcolm McLean wrote: > On Friday, 26 August 2022 at 09:47:36 UTC+1, David Brown wrote: >> On 26/08/2022 04:56, Malcolm McLean wrote: >>> On Thursday, 25 August 2022 at 19:36:10 UTC+1, David Brown wrote: >>>> On 25/08/2022 18:16, Ben Bacarisse wrote: >>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>> >>>> A large proportion of the new features in C23 seem to have originated >>>> with or been promoted by one person - Jens Gustedt. I don't know if he >>>> should be considered an "academic", or a "practical programmer", or >>>> both, or neither. >>>> >>> I looked him up. He's very clearly what I would call an academic rather than a >>> practical programmer. That doesn't mean that he's never produced a piece of >>> code that has run "for real" in his life. But I cannot find a single reference to >>> any commercial software he has worked on. I don't think he's ever held a job >>> as programmer. >>> >> If you look me up (and good luck with that - my name is so common I >> might as well be anonymous) you'll find no references to commercial >> software that I have worked on, and probably no more than obscure >> references in a local Norwegian newspaper concerning what jobs I have >> had. Yet I have over 25 years of professional software development >> practice. >> > You don't hold an academic post at a university. Pretty much everybody who > holds an academic post at university puts up online some bit of information > listing their research interests, and a bit of biographical detail. True. But even if someone has such information available, that does not tell you about what they have or have not done outside of this information. >> >> So your search results have almost no worth at all, as far as I can see. >> > If Gustedt had done significant work on commercial software, I would have > expected it to be listed. You can't prove 100% that he did such work but didn't > think it was interesting enough to mention, but it's not likely. If he has done significant work on commercial software, I would expect it to be extremely likely that it is /not/ mentioned. If he is working as a researcher (at a university or in a research institute of some kind), I expect his interests to be listed and perhaps involvement in research-related software, especially if publicly funded. But work done on commercial software is usually a matter between you and the company, and no one else - it is not information that is publicised. /Sometimes/ work on commercial software is publicised, perhaps for particular key roles or because the person has particular interest in taking the credit. But in the great majority of cases, work on software is pretty anonymous. As so often happens, you are extrapolating your somewhat niche personal experience in a way that is not at all justified on a wider scale. >> >> You do seem to be making a distinction here that others (myself, at >> least) do not see. I've known people who work as "practical" >> programmers who are interesting in the theory, academics who do >> practical work, and all sorts of mixes - there is so much "grey area" >> that there is no black or white. >> > There are grey areas, because problems which are theoretically interesting > are also sometimes of practical use. However one fairly unambiguous test > is "is someone paying money for the right to execute this piece of code?". > If the answer is "yes", it must be practical code. If the answer is "no", it might > still be practical, because not every activity that adds value involves economic > exchange, but likely it's not. Even if that test was appropriate (and I would classify it as "possibly vaguely relevant", rather than "fairly unambiguous"), it is not information you would normally have about someone. >> >> All you can really say is that since C is a very practical language, and >> so completely unsuited to purely theoretical computer science, that >> anyone interested in the C language is interested in the practical use >> in real programs. >> > That is another rule of thumb. If you use C, the code can be deployed in a > program designed for mass market release. Nonsense. Plenty of C code is written for small audiences. None of the C code I have ever written has been or ever could be a "mass market release". Equally, mass market software can be and is written in a vast number of programming languages. You are making a pointless and non-existent division. > If you use a language like Scheme, > it's much harder to get the code out into real world use. However, as you say, > there are grey areas, and not all C is intended for deployment in commercial > programs. >> >> If you want more information on Jens Gustedt, read his blog. >> > I've had a look at it. He's an impressive person. I don't want to say anything as > crude as "theoretical work bad, practical work good". It is not a matter of being good or bad, it is a question of whether it is even /relevant/.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-08-26 04:57 -0700 |
| Message-ID | <63c367cc-c2ac-41ec-a65a-622161ecd58dn@googlegroups.com> |
| In reply to | #86097 |
On Friday, 26 August 2022 at 12:03:20 UTC+1, David Brown wrote: > On 26/08/2022 11:48, Malcolm McLean wrote: > > On Friday, 26 August 2022 at 09:47:36 UTC+1, David Brown wrote: > >> On 26/08/2022 04:56, Malcolm McLean wrote: > >>> On Thursday, 25 August 2022 at 19:36:10 UTC+1, David Brown wrote: > >>>> On 25/08/2022 18:16, Ben Bacarisse wrote: > >>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >>>>> > >>>> A large proportion of the new features in C23 seem to have originated > >>>> with or been promoted by one person - Jens Gustedt. I don't know if he > >>>> should be considered an "academic", or a "practical programmer", or > >>>> both, or neither. > >>>> > >>> I looked him up. He's very clearly what I would call an academic rather than a > >>> practical programmer. That doesn't mean that he's never produced a piece of > >>> code that has run "for real" in his life. But I cannot find a single reference to > >>> any commercial software he has worked on. I don't think he's ever held a job > >>> as programmer. > >>> > >> If you look me up (and good luck with that - my name is so common I > >> might as well be anonymous) you'll find no references to commercial > >> software that I have worked on, and probably no more than obscure > >> references in a local Norwegian newspaper concerning what jobs I have > >> had. Yet I have over 25 years of professional software development > >> practice. > >> > > You don't hold an academic post at a university. Pretty much everybody who > > holds an academic post at university puts up online some bit of information > > listing their research interests, and a bit of biographical detail. > True. But even if someone has such information available, that does not > tell you about what they have or have not done outside of this information. > >> > >> So your search results have almost no worth at all, as far as I can see. > >> > > If Gustedt had done significant work on commercial software, I would have > > expected it to be listed. You can't prove 100% that he did such work but didn't > > think it was interesting enough to mention, but it's not likely. > If he has done significant work on commercial software, I would expect > it to be extremely likely that it is /not/ mentioned. If he is working > as a researcher (at a university or in a research institute of some > kind), I expect his interests to be listed and perhaps involvement in > research-related software, especially if publicly funded. But work done > on commercial software is usually a matter between you and the company, > and no one else - it is not information that is publicised. /Sometimes/ > work on commercial software is publicised, perhaps for particular key > roles or because the person has particular interest in taking the > credit. But in the great majority of cases, work on software is pretty > anonymous. > > As so often happens, you are extrapolating your somewhat niche personal > experience in a way that is not at all justified on a wider scale. > >> > >> You do seem to be making a distinction here that others (myself, at > >> least) do not see. I've known people who work as "practical" > >> programmers who are interesting in the theory, academics who do > >> practical work, and all sorts of mixes - there is so much "grey area" > >> that there is no black or white. > >> > > There are grey areas, because problems which are theoretically interesting > > are also sometimes of practical use. However one fairly unambiguous test > > is "is someone paying money for the right to execute this piece of code?". > > If the answer is "yes", it must be practical code. If the answer is "no", it might > > still be practical, because not every activity that adds value involves economic > > exchange, but likely it's not. > Even if that test was appropriate (and I would classify it as "possibly > vaguely relevant", rather than "fairly unambiguous"), it is not > information you would normally have about someone. > You don't normally go up to someone in the street and quiz them about their career. However if you meet someone socially, then it's fairly normal to ask "what do you do for a living?". If they say "I'm a software developer", then you'd say "I'm also in the software business." Then that would lead on to which programs they work on. If they are a games programmer, for example, you'd almost always get a list of titles they have contributed to. If they develop software for a bank, you'd probably leave it, unless they really want to tell you all about the big systems integration project they are engaged in. But they wouldn't be developing code for the bank for free, and the bank wouldn't normally pay for code that didn't achieve commercial objectives.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-26 14:55 +0200 |
| Message-ID | <teafro$3vlpc$1@dont-email.me> |
| In reply to | #86098 |
On 26/08/2022 13:57, Malcolm McLean wrote: > On Friday, 26 August 2022 at 12:03:20 UTC+1, David Brown wrote: >> On 26/08/2022 11:48, Malcolm McLean wrote: >>> On Friday, 26 August 2022 at 09:47:36 UTC+1, David Brown wrote: >>>> On 26/08/2022 04:56, Malcolm McLean wrote: >>>>> On Thursday, 25 August 2022 at 19:36:10 UTC+1, David Brown wrote: >>>>>> On 25/08/2022 18:16, Ben Bacarisse wrote: >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: >>>>>>> >>>>>> A large proportion of the new features in C23 seem to have originated >>>>>> with or been promoted by one person - Jens Gustedt. I don't know if he >>>>>> should be considered an "academic", or a "practical programmer", or >>>>>> both, or neither. >>>>>> >>>>> I looked him up. He's very clearly what I would call an academic rather than a >>>>> practical programmer. That doesn't mean that he's never produced a piece of >>>>> code that has run "for real" in his life. But I cannot find a single reference to >>>>> any commercial software he has worked on. I don't think he's ever held a job >>>>> as programmer. >>>>> >>>> If you look me up (and good luck with that - my name is so common I >>>> might as well be anonymous) you'll find no references to commercial >>>> software that I have worked on, and probably no more than obscure >>>> references in a local Norwegian newspaper concerning what jobs I have >>>> had. Yet I have over 25 years of professional software development >>>> practice. >>>> >>> You don't hold an academic post at a university. Pretty much everybody who >>> holds an academic post at university puts up online some bit of information >>> listing their research interests, and a bit of biographical detail. >> True. But even if someone has such information available, that does not >> tell you about what they have or have not done outside of this information. >>>> >>>> So your search results have almost no worth at all, as far as I can see. >>>> >>> If Gustedt had done significant work on commercial software, I would have >>> expected it to be listed. You can't prove 100% that he did such work but didn't >>> think it was interesting enough to mention, but it's not likely. >> If he has done significant work on commercial software, I would expect >> it to be extremely likely that it is /not/ mentioned. If he is working >> as a researcher (at a university or in a research institute of some >> kind), I expect his interests to be listed and perhaps involvement in >> research-related software, especially if publicly funded. But work done >> on commercial software is usually a matter between you and the company, >> and no one else - it is not information that is publicised. /Sometimes/ >> work on commercial software is publicised, perhaps for particular key >> roles or because the person has particular interest in taking the >> credit. But in the great majority of cases, work on software is pretty >> anonymous. >> >> As so often happens, you are extrapolating your somewhat niche personal >> experience in a way that is not at all justified on a wider scale. >>>> >>>> You do seem to be making a distinction here that others (myself, at >>>> least) do not see. I've known people who work as "practical" >>>> programmers who are interesting in the theory, academics who do >>>> practical work, and all sorts of mixes - there is so much "grey area" >>>> that there is no black or white. >>>> >>> There are grey areas, because problems which are theoretically interesting >>> are also sometimes of practical use. However one fairly unambiguous test >>> is "is someone paying money for the right to execute this piece of code?". >>> If the answer is "yes", it must be practical code. If the answer is "no", it might >>> still be practical, because not every activity that adds value involves economic >>> exchange, but likely it's not. >> Even if that test was appropriate (and I would classify it as "possibly >> vaguely relevant", rather than "fairly unambiguous"), it is not >> information you would normally have about someone. >> > You don't normally go up to someone in the street and quiz them about their career. > > However if you meet someone socially, then it's fairly normal to ask "what do you do > for a living?". If they say "I'm a software developer", then you'd say "I'm also in the > software business." Then that would lead on to which programs they work on. If they > are a games programmer, for example, you'd almost always get a list of titles they > have contributed to. If they develop software for a bank, you'd probably leave it, > unless they really want to tell you all about the big systems integration project they > are engaged in. But they wouldn't be developing code for the bank for free, and the > bank wouldn't normally pay for code that didn't achieve commercial objectives. > You do understand there is a difference between what you say to a friend, colleague or relative socially, and what you publish for the world to see in an biography page? If we were talking in person, and I felt I could trust you with confidential information, I could well tell you about particular customers of mine. But neither I nor anyone else can publishing details about who I worked with, what programs I worked on, or for which customers, without explicit permission from myself, my employer, and the relevant customer(s). Details of commercial agreements are confidential by default, and something like the connection between developers and customers usually remains confidential because it is rarely in anyone's interest to know the details. I think this thread should probably end here.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2022-08-26 06:20 -0700 |
| Message-ID | <84a6e91a-07a3-454b-ac13-baa24ce97a1cn@googlegroups.com> |
| In reply to | #86100 |
On Friday, 26 August 2022 at 13:55:38 UTC+1, David Brown wrote: > On 26/08/2022 13:57, Malcolm McLean wrote: > > On Friday, 26 August 2022 at 12:03:20 UTC+1, David Brown wrote: > >> On 26/08/2022 11:48, Malcolm McLean wrote: > >>> On Friday, 26 August 2022 at 09:47:36 UTC+1, David Brown wrote: > >>>> On 26/08/2022 04:56, Malcolm McLean wrote: > >>>>> On Thursday, 25 August 2022 at 19:36:10 UTC+1, David Brown wrote: > >>>>>> On 25/08/2022 18:16, Ben Bacarisse wrote: > >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes: > >>>>>>> > >>>>>> A large proportion of the new features in C23 seem to have originated > >>>>>> with or been promoted by one person - Jens Gustedt. I don't know if he > >>>>>> should be considered an "academic", or a "practical programmer", or > >>>>>> both, or neither. > >>>>>> > >>>>> I looked him up. He's very clearly what I would call an academic rather than a > >>>>> practical programmer. That doesn't mean that he's never produced a piece of > >>>>> code that has run "for real" in his life. But I cannot find a single reference to > >>>>> any commercial software he has worked on. I don't think he's ever held a job > >>>>> as programmer. > >>>>> > >>>> If you look me up (and good luck with that - my name is so common I > >>>> might as well be anonymous) you'll find no references to commercial > >>>> software that I have worked on, and probably no more than obscure > >>>> references in a local Norwegian newspaper concerning what jobs I have > >>>> had. Yet I have over 25 years of professional software development > >>>> practice. > >>>> > >>> You don't hold an academic post at a university. Pretty much everybody who > >>> holds an academic post at university puts up online some bit of information > >>> listing their research interests, and a bit of biographical detail. > >> True. But even if someone has such information available, that does not > >> tell you about what they have or have not done outside of this information. > >>>> > >>>> So your search results have almost no worth at all, as far as I can see. > >>>> > >>> If Gustedt had done significant work on commercial software, I would have > >>> expected it to be listed. You can't prove 100% that he did such work but didn't > >>> think it was interesting enough to mention, but it's not likely. > >> If he has done significant work on commercial software, I would expect > >> it to be extremely likely that it is /not/ mentioned. If he is working > >> as a researcher (at a university or in a research institute of some > >> kind), I expect his interests to be listed and perhaps involvement in > >> research-related software, especially if publicly funded. But work done > >> on commercial software is usually a matter between you and the company, > >> and no one else - it is not information that is publicised. /Sometimes/ > >> work on commercial software is publicised, perhaps for particular key > >> roles or because the person has particular interest in taking the > >> credit. But in the great majority of cases, work on software is pretty > >> anonymous. > >> > >> As so often happens, you are extrapolating your somewhat niche personal > >> experience in a way that is not at all justified on a wider scale. > >>>> > >>>> You do seem to be making a distinction here that others (myself, at > >>>> least) do not see. I've known people who work as "practical" > >>>> programmers who are interesting in the theory, academics who do > >>>> practical work, and all sorts of mixes - there is so much "grey area" > >>>> that there is no black or white. > >>>> > >>> There are grey areas, because problems which are theoretically interesting > >>> are also sometimes of practical use. However one fairly unambiguous test > >>> is "is someone paying money for the right to execute this piece of code?". > >>> If the answer is "yes", it must be practical code. If the answer is "no", it might > >>> still be practical, because not every activity that adds value involves economic > >>> exchange, but likely it's not. > >> Even if that test was appropriate (and I would classify it as "possibly > >> vaguely relevant", rather than "fairly unambiguous"), it is not > >> information you would normally have about someone. > >> > > You don't normally go up to someone in the street and quiz them about their career. > > > > However if you meet someone socially, then it's fairly normal to ask "what do you do > > for a living?". If they say "I'm a software developer", then you'd say "I'm also in the > > software business." Then that would lead on to which programs they work on. If they > > are a games programmer, for example, you'd almost always get a list of titles they > > have contributed to. If they develop software for a bank, you'd probably leave it, > > unless they really want to tell you all about the big systems integration project they > > are engaged in. But they wouldn't be developing code for the bank for free, and the > > bank wouldn't normally pay for code that didn't achieve commercial objectives. > > > You do understand there is a difference between what you say to a > friend, colleague or relative socially, and what you publish for the > world to see in an biography page? If we were talking in person, and I > felt I could trust you with confidential information, I could well tell > you about particular customers of mine. But neither I nor anyone else > can publishing details about who I worked with, what programs I worked > on, or for which customers, without explicit permission from myself, my > employer, and the relevant customer(s). Details of commercial > agreements are confidential by default, and something like the > connection between developers and customers usually remains confidential > because it is rarely in anyone's interest to know the details. > > I think this thread should probably end here. > Maybe it's different in your world. In my world, details of the current project are often a secret. But once it is completed, it's no longer a secret. Just the opposite, in fact. You want everybody to know about the software and its capabilities. But yes, we've gone rather far from C++.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-08-27 18:44 +0200 |
| Message-ID | <tedhl3$1d7v$1@gioia.aioe.org> |
| In reply to | #86097 |
On 8/26/2022 1:02 PM, David Brown wrote: > On 26/08/2022 11:48, Malcolm McLean wrote: [...] >> If Gustedt had done significant work on commercial software, I would have >> expected it to be listed. You can't prove 100% that he did such work >> but didn't >> think it was interesting enough to mention, but it's not likely. > > If he has done significant work on commercial software, I would expect > it to be extremely likely that it is /not/ mentioned. If he is working > as a researcher (at a university or in a research institute of some > kind), I expect his interests to be listed and perhaps involvement in > research-related software, especially if publicly funded. But work done > on commercial software is usually a matter between you and the company, > and no one else - it is not information that is publicised. /Sometimes/ > work on commercial software is publicised, perhaps for particular key > roles or because the person has particular interest in taking the > credit. But in the great majority of cases, work on software is pretty > anonymous. > > As so often happens, you are extrapolating your somewhat niche personal > experience in a way that is not at all justified on a wider scale. > Not really. I think you are confusing the contents of the software you might develop for commercial use, which is most often confidential within the company you work for, and your career information, which is often public if you are employed in a public institution, like a university.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-28 11:30 +0200 |
| Message-ID | <tefcj0$jffv$1@dont-email.me> |
| In reply to | #86120 |
On 27/08/2022 18:44, Manfred wrote: > On 8/26/2022 1:02 PM, David Brown wrote: >> On 26/08/2022 11:48, Malcolm McLean wrote: > [...] >>> If Gustedt had done significant work on commercial software, I would >>> have >>> expected it to be listed. You can't prove 100% that he did such work >>> but didn't >>> think it was interesting enough to mention, but it's not likely. >> >> If he has done significant work on commercial software, I would expect >> it to be extremely likely that it is /not/ mentioned. If he is >> working as a researcher (at a university or in a research institute of >> some kind), I expect his interests to be listed and perhaps >> involvement in research-related software, especially if publicly >> funded. But work done on commercial software is usually a matter >> between you and the company, and no one else - it is not information >> that is publicised. /Sometimes/ work on commercial software is >> publicised, perhaps for particular key roles or because the person has >> particular interest in taking the credit. But in the great majority >> of cases, work on software is pretty anonymous. >> >> As so often happens, you are extrapolating your somewhat niche >> personal experience in a way that is not at all justified on a wider >> scale. >> > > Not really. I think you are confusing the contents of the software you > might develop for commercial use, which is most often confidential > within the company you work for, and your career information, which is > often public if you are employed in a public institution, like a > university. People working at public institutions such as universities also often do work for commercial companies. Some aspects of that are often made public, such as which companies and universities are working together, while many details are generally kept private. So you would expect to see information that Google has been working with Monster University on harnessing the power of laughter. You would /not/ expect to see that Professor Plum wrote the pun generator library for the joke engine. And if neither contributing organisation is a public entity, you would not expect to see any information at all about collaborating companies, much less the contributions of individuals, unless both companies felt there was significant marketing or publicity gains to be had, and both companies agreed on it - then you'd see the information in press releases, not developers biographies. There are exceptions, of course, but that is common practice. The whole point is that the fact that Malcolm failed to find information about commercial software written by Jens Gustedt tells us absolutely /nothing/ about how much commercial software he has worked on.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-25 10:06 -0700 |
| Message-ID | <87mtbsw8vf.fsf@nosuchdomain.example.com> |
| In reply to | #86060 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> Computer science people would tend to think that it's important to have
> a boolean type, because a lot of logic works on values which are inherently
> true or false. Practical programmers would tend to say that it's not, because
> most hardware won't support it. You will of course find exceptions.
Many practical programmers would tend to say it's important to have a
boolean type because it makes it easier to write clear code. (Some
probably prefer to use zero and non-zero rather than explicit bool,
false, and true.)
Why would a "practical programmer" care whether there's direct hardware
support for bool? If the compiler handles it correctly, it just works.
In a very real sense, all hardware supports booleans, with more or less
work required by the compiler.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web